Re: [E-devel] DirectFB, Intel GDL, Overlays and more
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
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
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
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
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
