Re: [E-devel] DirectFB, Intel GDL, Overlays and more

2008-03-04 Thread The Rasterman
On Sun, 24 Feb 2008 22:41:59 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:

i can't answer with respect to directfb, but the hardware you have is probably
similar to what i've seen before. you get multiple display layers/planes
(multiple framebuffers). one layer is YUV video data - thats your video layer.
you are expected to just decode all video data into here and the hardware will
convert to RGB and scale. it's really only mostly useful for 1 video at a time,
and is intended to be fullscreen (you can twist it to do more, but only for
limited uses). you may get a second YUV video layer for picture-in-picture, but
then you get an overlay layer thats RGBG of some sort. maybe 32bit ARGB or
16bit RGB656 + an alpha mask or rgb555 with 1 bit for alpha (on/off) or maybe
even color-keyed. this layer is probably where you want to render stuff into
with evas most likely. now the question comes - how much help does the hardware
supply in rendering to this layer? in my experience it generally is very
minimal or even non-existent. you need to check what drawing operations are
supported and what their limitations are.

i might be tempted to do an engine just for GDL to draw in the overlay layer
with evas (and leave video to something else). DFB is your other choice there.

 Hi guys,
 
 I'll have to work with an Intel consumer electronics soon (CE2110,
 [1]) so I started to investigate its capabilities and found that it
 provides video overlays optimized for media playbacks, so you can
 provide nice OSD (on screen display) without wasting much CPU, also
 this board have some hardware decoders for h264 and mpeg2 and I guess
 these do output to these overlays.
 
 They provide video drivers with their own library called GDL -
 Graphics Device Library [2], with backend/engines for SDL and
 DirectFB. This GDL seems to be pretty decent in hardware support, with
 2D including primitives like line, rectangle and blits (alpha, scaled
 too [3]). This library itself is a tiny convenience library to issue
 ioctl() to their kernel driver.
 
 I could not find CE2110 SDK, but there is one for the 854 chipset [4]
 that contains sample programs with the GDL, just download it,
 uncompress 8xxpsp-GDL-1.1-135.i386.rpm and then see
 ./usr/local/gdl-8xx/samples/
 
 Now to Evas part: we have an outdated DirectFB which AFAIK nobody is
 using or willing to maintain and we (more specifically Cedric) have
 SDL almost integrated.
I know SDL is really bare bones, so overhead of it should be
 minimum, however due it being bare bones I fear it not exposing
 primitives we could benefit. I couldn't find any source code or patch
 for SDL, so I'm not sure what they optimized.
I don't know DirectFB more than reading their website some years
 ago, but looking at their code and the patch provided by Intel, looks
 like they do optimize some things. They have a README.txt with:
 
  3. Current supported GDL accelerated features of DirectFB
 1) Overlay surface source color key is supported..
 2) Below drawing functions are accelerated via GDL for all
 video system surfaces:
 draw lines;
 draw rectangles, fill rectangles, fill triangle with single color;
 strecth blt with alpha blending and alpha scaler.
 
 
 So I'm not sure on how to proceed. Would it be better to get DirectFB
 in shape, use SDL or write Evas GDL engine? Maybe my requirements can
 help somehow:
   - basic usage will be a digital tv set top box, so it's full high
 definition video with eventually some nice OSD on top of it.
   - it would be great to have semi-transparent OSD.
   - CPU is ARM/Xscale at 1Ghz, so fancy on-cpu graphics may not be
 possible (ie: emotion).
   - future will require me to run more things than just my
 application, maybe having Firefox and some other programs. This may be
 a good point for DirectFB? (I don't know if they compiled with the
 multi-app support, but given they provide a patch, it may be possible
 to recompile with this support).
 
 If you have any knowledge of this topic, please help. I'm still a bit
 confused about this overlay thing, maybe it's very helpful, as if you
 can have a ARGB overlay with my GUI so I port Evas to it, run it as
 ARGB surface and  play the video on the background from another place.
 But maybe it's not like that and it's just a way to get hardware to
 output to some region directly (like h264/mpeg2 decoders writing to
 it) and I'd have to draw my surface on top of it using colorkey or
 retrieving the pixels (possible slow) to do alpha blend, making things
 more difficult.
 
 What's the state of DirectFB? Was it running fine one day (ie:
 directfb part is okay, it just lag behind Evas api changes)?
 
 
 
 [1] http://www.intel.com/design/celect/2110/index.htm
 [2] http://www.intel.com/design/celect/2110/tools.htm
 [3] gdl_int32 gdl_blt(gdl_context_t* context, gdl_uint32
 src_surface_id, gdl_rectangle_t* src_rect, gdl_uint32 dest_surface_id,
 gdl_rectangle_t* dest_rect, 

Re: [E-devel] DirectFB, Intel GDL, Overlays and more

2008-02-25 Thread Cedric BAIL
On Mon, Feb 25, 2008 at 2:41 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
  I'll have to work with an Intel consumer electronics soon (CE2110,
  [1]) so I started to investigate its capabilities and found that it
  provides video overlays optimized for media playbacks, so you can
  provide nice OSD (on screen display) without wasting much CPU, also
  this board have some hardware decoders for h264 and mpeg2 and I guess
  these do output to these overlays.

That's a nice board :)

  They provide video drivers with their own library called GDL -
  Graphics Device Library [2], with backend/engines for SDL and
  DirectFB. This GDL seems to be pretty decent in hardware support, with
  2D including primitives like line, rectangle and blits (alpha, scaled
  too [3]). This library itself is a tiny convenience library to issue
  ioctl() to their kernel driver.

  Now to Evas part: we have an outdated DirectFB which AFAIK nobody is
  using or willing to maintain and we (more specifically Cedric) have
  SDL almost integrated.
I know SDL is really bare bones, so overhead of it should be
  minimum, however due it being bare bones I fear it not exposing
  primitives we could benefit. I couldn't find any source code or patch
  for SDL, so I'm not sure what they optimized.

In SDL the only usable primitive is a SDL_FillRect when color as not
alpha, nothing else. Mostly because they don't update alpha correctly
in their blit function.

I don't know DirectFB more than reading their website some years
  ago, but looking at their code and the patch provided by Intel, looks
  like they do optimize some things. They have a README.txt with:
  
   3. Current supported GDL accelerated features of DirectFB
  1) Overlay surface source color key is supported..
  2) Below drawing functions are accelerated via GDL for all
  video system surfaces:
  draw lines;
  draw rectangles, fill rectangles, fill triangle with single color;
  strecth blt with alpha blending and alpha scaler.

DirectFB API provide a usefull api for blenging, stretching and
filling. So definitivelly, if you want something accelerated, it's a
good solution. Another interesting point is that this API is also
provided by other hardware manufacturer for their set top box.

Now some draw back, the implementation I saw from manufacturer where
slow and based on outdated version of directfb. They didn't follow the
directfb api completely for video as they wanted not to directly
expose the decoded video to the underlying application (something
related to media content protection). This could prevent us from doing
nice effect like emotion give us the possibility.

  So I'm not sure on how to proceed. Would it be better to get DirectFB
  in shape, use SDL or write Evas GDL engine? Maybe my requirements can
  help somehow:
   - basic usage will be a digital tv set top box, so it's full high
  definition video with eventually some nice OSD on top of it.
   - it would be great to have semi-transparent OSD.
   - CPU is ARM/Xscale at 1Ghz, so fancy on-cpu graphics may not be
  possible (ie: emotion).
   - future will require me to run more things than just my
  application, maybe having Firefox and some other programs. This may be
  a good point for DirectFB? (I don't know if they compiled with the
  multi-app support, but given they provide a patch, it may be possible
  to recompile with this support).

I have mostly the same question right now, but not for the intel
hardware. I would add that I am sure that my hardware provide a way to
decode multiple video at a time, and merge them using the 2D graphic
engine with support for alpha channel. Meaning I am sure that if I do
every thing from scratch, I should be able to do the thing emotion
give us the possibility to do. But currently by using SDL or DirectFB,
it's not possible.

With what I read from the intel spec, you have multiple video plan, so
you can do what I am doing now. Just play video on the dedicated plan
you have, setup the SDL backend with a 32bpp surface on another layer
on top of the video layer and use SDL transparency for OSD effect. It
will work well in software, I am doing this on my little MIPS at
250Mhz. But no fancy effect or anything on your video. The evas sdl
backend work great in that case.

  If you have any knowledge of this topic, please help. I'm still a bit
  confused about this overlay thing, maybe it's very helpful, as if you
  can have a ARGB overlay with my GUI so I port Evas to it, run it as
  ARGB surface and  play the video on the background from another place.
  But maybe it's not like that and it's just a way to get hardware to
  output to some region directly (like h264/mpeg2 decoders writing to
  it) and I'd have to draw my surface on top of it using colorkey or
  retrieving the pixels (possible slow) to do alpha blend, making things
  more difficult.

  What's the state of DirectFB? Was it running fine one day (ie:
  directfb part is okay, 

Re: [E-devel] DirectFB, Intel GDL, Overlays and more

2008-02-25 Thread [EMAIL PROTECTED]

Gustavo wrote:

 Now to Evas part: we have an outdated DirectFB which AFAIK nobody
 is using or willing to maintain and we (more specifically Cedric)
 have SDL almost integrated.

The directfb engine was initially written a long time ago
and was never kept up with as much as other engines, it could use
a re-write. I believe Freevo was using it, but not sure if that's
still the case - Jason Tackaberry did some work to bring it slightly
more up to date a bit back.

   I know SDL is really bare bones, so overhead of it should be
 minimum, however due it being bare bones I fear it not exposing
 primitives we could benefit. I couldn't find any source code or
 patch for SDL, so I'm not sure what they optimized.

SDL as in the software-sdl engine? I think cedric tried to use
more native sdl apis for optimizing some things, but as I recall he had
some issues with compositing via sdl functions due to something about
their handling of alpha (maybe due to evas use of pre-mul data?).

   I don't know DirectFB more than reading their website some years
 ago, but looking at their code and the patch provided by Intel,
 .
 .
 
 So I'm not sure on how to proceed. Would it be better to get
 DirectFB in shape, use SDL or write Evas GDL engine? Maybe my
 requirements can help somehow:
 ...
 ...

'Fixing' the directfb engine would be good regardless, but
wether to use that vs. the sdl engine vs. write a new gdl one...??

Note though that this issue of 'overlays' has come up before
in regards to using evas with opengl in games.. and wether or not
you do go ahead and write a gdl engine, you may still face some of
the common issues that were relevant to using evas in those kinds
of lud 'overlays'.

Basically, if your 'overlay' can be given as a display target
buffer 'surface', then you'd want to draw to such native surface
buffers, and that means two things:
1. An engine that can render to such a native surface buffer (rather
   than using the software argb buffer engine).
2. Implement evas image 'native surfaces' for the kinds of buffer
   surfaces you use in (1) above.

Then you'd also need some support from ecore (and enhancements
to the whole sub-canvas part).

But for this to work best you'd definitely want to have your
native surface buffer engine do as much as possible via accelerated
methods (and make sure the drivers for those are good) - if you're
going to have the rendering mostly via software, then for (2) you might
as well just use a software buffer engine instead (you shouldn't need
to get pixels out of the display target unless you're doing some very
specialized gfx effects).

 What's the state of DirectFB? Was it running fine one day (ie:
 directfb part is okay, it just lag behind Evas api changes)?

It was ok not too long ago, just behind on some things then..
check with Jason from freevo.. maybe he can be of some help there.

   jose.

_
Click for free info on business schools, $150K/ year potential.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l7gMtXxsPP8YHDFA1HhQEbGNPFkaYE5rax2fYZWbJMI7LPC/



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] DirectFB, Intel GDL, Overlays and more

2008-02-24 Thread Gustavo Sverzut Barbieri
Hi guys,

I'll have to work with an Intel consumer electronics soon (CE2110,
[1]) so I started to investigate its capabilities and found that it
provides video overlays optimized for media playbacks, so you can
provide nice OSD (on screen display) without wasting much CPU, also
this board have some hardware decoders for h264 and mpeg2 and I guess
these do output to these overlays.

They provide video drivers with their own library called GDL -
Graphics Device Library [2], with backend/engines for SDL and
DirectFB. This GDL seems to be pretty decent in hardware support, with
2D including primitives like line, rectangle and blits (alpha, scaled
too [3]). This library itself is a tiny convenience library to issue
ioctl() to their kernel driver.

I could not find CE2110 SDK, but there is one for the 854 chipset [4]
that contains sample programs with the GDL, just download it,
uncompress 8xxpsp-GDL-1.1-135.i386.rpm and then see
./usr/local/gdl-8xx/samples/

Now to Evas part: we have an outdated DirectFB which AFAIK nobody is
using or willing to maintain and we (more specifically Cedric) have
SDL almost integrated.
   I know SDL is really bare bones, so overhead of it should be
minimum, however due it being bare bones I fear it not exposing
primitives we could benefit. I couldn't find any source code or patch
for SDL, so I'm not sure what they optimized.
   I don't know DirectFB more than reading their website some years
ago, but looking at their code and the patch provided by Intel, looks
like they do optimize some things. They have a README.txt with:

 3. Current supported GDL accelerated features of DirectFB
1) Overlay surface source color key is supported..
2) Below drawing functions are accelerated via GDL for all
video system surfaces:
draw lines;
draw rectangles, fill rectangles, fill triangle with single color;
strecth blt with alpha blending and alpha scaler.


So I'm not sure on how to proceed. Would it be better to get DirectFB
in shape, use SDL or write Evas GDL engine? Maybe my requirements can
help somehow:
  - basic usage will be a digital tv set top box, so it's full high
definition video with eventually some nice OSD on top of it.
  - it would be great to have semi-transparent OSD.
  - CPU is ARM/Xscale at 1Ghz, so fancy on-cpu graphics may not be
possible (ie: emotion).
  - future will require me to run more things than just my
application, maybe having Firefox and some other programs. This may be
a good point for DirectFB? (I don't know if they compiled with the
multi-app support, but given they provide a patch, it may be possible
to recompile with this support).

If you have any knowledge of this topic, please help. I'm still a bit
confused about this overlay thing, maybe it's very helpful, as if you
can have a ARGB overlay with my GUI so I port Evas to it, run it as
ARGB surface and  play the video on the background from another place.
But maybe it's not like that and it's just a way to get hardware to
output to some region directly (like h264/mpeg2 decoders writing to
it) and I'd have to draw my surface on top of it using colorkey or
retrieving the pixels (possible slow) to do alpha blend, making things
more difficult.

What's the state of DirectFB? Was it running fine one day (ie:
directfb part is okay, it just lag behind Evas api changes)?



[1] http://www.intel.com/design/celect/2110/index.htm
[2] http://www.intel.com/design/celect/2110/tools.htm
[3] gdl_int32 gdl_blt(gdl_context_t* context, gdl_uint32
src_surface_id, gdl_rectangle_t* src_rect, gdl_uint32 dest_surface_id,
gdl_rectangle_t* dest_rect, gdl_uint32 num_clip_rects,
gdl_rectangle_t* clip_rect_list, gdl_uint32 chroma_range_low,
gdl_uint32 chroma_range_high, gdl_uint32 global_alpha_scalar,
gdl_uint32 flags)
[4] http://www.intel.com/design/celect/swd/linux854.htm

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi - Embedded and Mobile Software Development
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] DirectFB, Intel GDL, Overlays and more

2008-02-24 Thread Lars Munch
On Sun, Feb 24, 2008 at 10:41:59PM -0300, Gustavo Sverzut Barbieri wrote:
 If you have any knowledge of this topic, please help. I'm still a bit
 confused about this overlay thing, maybe it's very helpful, as if you
 can have a ARGB overlay with my GUI so I port Evas to it, run it as
 ARGB surface and  play the video on the background from another place.
 But maybe it's not like that and it's just a way to get hardware to
 output to some region directly (like h264/mpeg2 decoders writing to
 it) and I'd have to draw my surface on top of it using colorkey or
 retrieving the pixels (possible slow) to do alpha blend, making things
 more difficult.

On the device I'm working on (PXA270 based) I have 2 overlays, one
overlay is an yuv with direct feed from my camera, the other overlay is
a RGB 5:5:5 which I'm using for my OSD.

Right now I'm rendering my OSD in an evas_buffer and convert/copy the
buffer into the overlay when an update is needed. This works pretty well
if you don't have to many updates and no edje animations etc on the OSD.

-- Lars Munch

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel