Hi Christoph,
I am not an expert in this area so don't take anything I say
too seriously.
On Sun, Sep 16, 2001 at 04:01:36PM +0200, Christoph Egger wrote:
>
> Hi!
>
> As I am also posting to the GGI list, I'll try to briefly introduce
> libvideo.
>
> libvideo is an GGI extension intended to display videos.
>
> It uses libovl for true hw-accelleration, libbuf and libblt to emulate
> videos, if libovl fails. libbuf is also used to read/write video data to
> display it. Further, libbuf is also used for special effects like
> alpha-blending.
>
> libvideo takes also care about caching of video data in advance to
> guarantee smoothly displayed videos.
> libvideo's targets takes care about decoding and decompression, in case
> libovl can't do it.
My understanding about the HW to do this kind of thing is that in a system
using a HW mpeg decoder and one of the special video featured graphics
chips. The decoder will deliver a stream of video data to a port.
Set up of the decoder includes giving it the information (address)
of the port. Setting up the port includes giving the port HW the
address of the FB for the video (and any other characteristics
that will control the process.) The port is probably a FIFO
which can have data written to it at a single address. (Plus
HW to then DMA this to the FB.)
I don't know if any of the decoders would know how to fill an FB
directly if given the FB info. I guess I should do a survey of
chips.
So I guess the two types of transfers of video data which could/should
be supported include
xfer to a frame buffer where the 'provider' knows about the FB size/structure.
xfer to a fixed port address where the 'provider knows how to do this.
Currently I don't know of any others (But I can imagine using a
software fifo as well, I will assume that the port is a HW fifo).
>
> To load/save videos from/to disk you should use libgpf instead. libgpf is
> intended to provide data-stream manipulation and redirection from
> somewhere to somewhere from any format to any other format.
>
> This allows to do realtime video-streaming from the internet/DVD,
> for example.
>
>
> Today I have worked out the API and a whole framework. It is completely
> untested and it doesn't compile yet, but it should show the ideas behind
> it.
>
> If you want to have a look at it, it is available in CVS (highlevel
> module).
>
I'm still looking. I will ask a few questions about specific routines
later as I may be misunderstanding the intent. For now I have the following
comments. Basically I am not quite sure if the API you are putting forward
covers this entirely or not.
DirectFB has the concept of starting and stopping a stream
from a video provider. I don't think that this is the level
of API that you are doing in libvideo.
At the level of the video provider this makes sense.
stop, start, pause, blank, fade, ? perhaps more.
At the level of the API for the video layer I see things
more as. Create a video layer. position the layer. scale the layer
have a mechanism to attach/detach a provider to the layer.
control feature/mixer settings alpha blend and etc.
One of the libraries needs to provide software fallbacks for
conversions (perhaps libbuf). The list Brian found at Apple was
longer than I expected. The most common conversions appear to be
from/to ARGB or RGB
to/from 4:2:2 (Most likely)
to/from 4:2:0 (sometimes)
to/from 4:1:1 (less often)
All the others would occur infrequently. Although
to/from YUV might also be needed.
Some hardware provides some of these conversions.
For our purposes the architecture to support many conversions is needed.
Both HW and SW fallbacks should be supported.
For current needs (and testing) 4:2:2 would be a good start.
If you architecture guys can provide the general interface for
conversions (probably there, I just don't know how to use it...)
then the specific conversions should not be a big deal for someone
else to code the software fallbacks.
I need to look a little deeper into libvideo. I have just put some
thoughts here off the top of my head.
>
> Any ideas and comments are welcome.
>
>
> Have fun,
>
> Christoph Egger
> E-Mail: [EMAIL PROTECTED]
>
Regards,
Curtis
--
Curtis Veit email: [EMAIL PROTECTED]
Lineo Inc. Where Open Meets Smart
390 South 400 West phone: 801.426.5001
Lindon, Utah, USA 84042 fax: 801.852.8071
