> > > Some basic detection should still be there, e.g. for
> choosing the fastest
> > > pixel format.
I ment that availabe format could be hardcoded instead of generic
probing as is implemented today in vo code.
> >
> > How can I determine which pixel format is the fastest?
>
> For video playback the fastest pixel format is the format coming
> from the video decoder. If the hardware doesn't support it, the
> pixelformat with the lowest software conversion effort should be
> used, e.g. planar YUV from decoder, but only packed YUV and RGB in
> hardware. In this case conversion from planar YUV to packed YUV
> should be done, not YUV to RGB.
You do not need to figure it yourself. Mplayer will do that for You.
Just report only hw supported colorspaces. In most cases
you mplayer will choose YV12.
>
> > > But the current implementation doesn't allow multiple applications
> > > to share the same exclusive context, while multiple
> exclusive contexts
> > > are allowed. Entering exclusive cooperative level creates
> a private layer
> > > context (config etc.) and switches to it.
> >
> > Actually, I get confused by the concept of cooperative
> levels and contexts.
>
> Layer contexts are part of the core. They are used to
> implement cooperative
> levels. Each context has its own display layer configuration,
> surface etc.
> Only one context is active per layer. Switching between these
> contexts changes
> the complete configuration, layer surface etc.
I think there is no need to deal with contexts (concurent acces to
same layer). It is much more easier to and new mplayer slave comand
and implement moving&resing inside mplayer vo (vo_directfb)
It takes just few lines of code ~ 20 lines I guess.
This way there will be no conflict. You just send the command
and mplayer wil do the rest.
JS
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
