The decoding may be done using the GPU or a CPU. I had in mind using the GPU to do it. That is how it is normally done - and why the result is usually rendered to a hardware layer (because that is the common destination for decoded video).
From your reply earlier (about non-familiarity with C etc) I would say you could either go with another platform or commission an appropriate VideoProvider. Although it is straightforward to implement VideoProviders for DirectFB on suitable platforms, it is not a trivial task. So DirectFB on this platform may not be a useful option. :-( ================================== Chris Bore Training Director BORES Signal Processing ch...@bores.com www.bores.com +44 (0)1483 740138 ________________________________ From: David Henderson <dhender...@digital-pipe.com> To: Chris Bore <chris_b...@yahoo.co.uk> Cc: directfb-users@directfb.org; Georgios Tsalikis <aliver...@tsalikis.net> Sent: Wed, 22 December, 2010 13:39:13 Subject: Re: [directfb-users] DirectFB Questions Chris Bore wrote: The issue of video decoding is to some extent a niche within DirectFB. > >For video decoding, DirectFB uses VideoProviders (and ImageProviders for still >images). These are interfaces that read data from a source, decode it, and >render it (usually to a hardware layer). The VideoProvider is a black box to >DirectFB - and for any given new platform, or new media format, you have to >write one. From the DirectFB viewpoint this is straightforward: all you have >to >do is implement the required VideoProvider interface to your own code - and >the >VideoProvider interface is quite simple. From the hardware viewpoint of course >you must implement the actual video decoding, and you may use the hardware >acceleration or not according to your own choice. > >So you have to invest in writing the implementation of the VideoProvider (or >wrapping an existing decoder in the required DirectFB interface), but then you >benefit from the main features of DirectFB (provided those are supported on >your >platform..). > >Chris > ================================== >Chris Bore >Training Director >BORES Signal Processing >ch...@bores.com >www.bores.com >+44 (0)1483 740138 > > > > > ________________________________ From: David Henderson <dhender...@digital-pipe.com> >To: Georgios Tsalikis <aliver...@tsalikis.net> >Cc: directfb-users@directfb.org >Sent: Tue, 21 December, 2010 22:05:34 >Subject: Re: [directfb-users] DirectFB Questions > >Georgios Tsalikis wrote: >> >> >> On 12/21/2010 07:24 PM, David Henderson wrote: >>> Hi everyone, >>> >>> I'm working on a lightweight project that might end up using DirectFB, but >>> I >>>have a couple of questions that need answering by the pro's here first. :) >>>Also, >>>I'm in the process of learning some aspects so forgive any illogical or >>>newbie >>>questions. >> I am not a pro but i am interested in using DFB in a custom distro, too. (i >>guess that's what you have in mind. >>> >>> 1) I can see DirectFB is used to replace X11. In doing so, are the drivers >>> for >>>graphics cards still needed or are they avoided by writing directly to the >>>frame >>>buffer? If drivers are still required, is there a database somewhere that >>>has >>>them for download? >> Devs avoid, so far, to claim that DFB is a replacement for X, but i agree >> with >>you. Graphics drivers are needed for writing to the FB in an accelerated way. >>Here is a database for the little range of drivers for desktop systems: >> http://www.directfb.org/index.php?path=Support/Graphics >>> 2) The project's hardware will be working with an Intel motherboard using >>>Intel's GMA X4500HD video chipset. It's supposed to have all kinds of >>>goodies >>>for hardware decoding of videos. Are there any compile options, patches, or >>>additional software that can work with DirectFB to utilize all that this >>>chipset >>>has to offer? >> AFAIK no... >>> 3) I see that DirectFB has the option of adding OpenGL which is supposed to >>>offload graphics processing to the GPU correct? What about vdpau or is that >>>just >>>for mplayer (or other media playing programs)? >> DirectFBGL is practically a concept project that works with Matrox cards, >> only. >>It needs Mesa embedded drivers of a branch that doesn't exist anymore. >>> >>> 4) What are my options for a Window Manager with DirectFB? I looked over >>> the >>>website, but I can't really tell. Apparently SaWMaN is one, but the >>>associated >>>pictures don't show any "windows", title bars, etc. Is it possible to use >>>XDirectFB with an existing embedded WM? Following the XDirectFB link on the >>>website shows a picture of a Gnome Desktop. Is this Gnome running on >>>DirectFB or >>>am I mistaken? Also, why do some of the Windows in that graphic look like >>>they're using two different WM's? >> As far as i understand, SawMan is intented for embedded systems. Yes, that >>picture shows Gnome running over XDirectFB. The different window style is >>because some windows are in X driven WM while others are using DirectFB's >>simple >>WM with the LiTE toolkit engine. >>> >>> 5) Do I need to enable anything in the Kernel to make DirectFB work? >> A Linux Fusion patch is a way of letting DirectFB applications talk to each >>other, or allow multiple DFB apps work simultaneously under something that >>could >>be defined as a single desktop. >> >>> Looks like that's all for now. Thanks for any help you guys can provide. >>> >>> Dave >> >> Wait for news about DirectFB 2.0. I sense it will solve lots of problems for >>people like us. >> >> George >> >> _______________________________________________ > >Thanks for the reply George. The requirements I have for the OS are to use as >much hardware as possible to free the CPU for other tasks and to be able to >play >media via OpenGL, vdpau, and/or other accelerators. Seems that DirectFB can't >currently satisfy either of those tasks. Does anyone know of any plans to make >a >driver for Intel's GMA X4500HD video chipset? Looking at the website for >version >2 of DFB seems to show that it's still in the design stage which means I'd >have >to wait for a while before moving forward with the project. I might have to go >with TinyX instead. Can anyone else add anything that would make it worth >using >DirectFB instead of TinyX? > >Thanks, >Dave >_______________________________________________ > Doesn't that mean that the decoding is still being performed by the CPU and not GPU? Dave
_______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
