[MPlayer-dev-eng] A proposal for the OSD

[D Richard Felker III]

On Thu, Mar 13, 2003 at 11:35:50AM +0100, Alban Bedel wrote:
> 
> Hi,
> 
> As we all know the osd stuff need some work as the current system is
> reaching it's limits. I alredy thought a bit about that before. My main
> idea is to try to make use of hardware (ie vo) capabilities and have
> something flexible. Here is what i come up with, it turn out that in
> fact it shouldn't need a big amount of new code as most of the stuff is
> alredy here. 
> First a little ascii diag (if that pass the mail and can help you to
> understand me ;)
> 
>         VD  -----> VF ---> VO
>                    î
>                    |
>         OSD ---->  OF
>          |
>          +-----+
>          |     |
>         OBJ1  OBJ2
> 
> 
> At the beginnig a format is set for the osd (this should later depend on
> the subtitles decoder capabilities, etc). The format will uselly be RGB
> or YUV be we should also be able to later support ascii and encoded spu.
> After that objects are added to the osd following the user settings (an
> object may be the timer or a subtitle decoder, etc). Some may fail if they
> don't support the output format.
> Then a filter chain is build like for the vf's. This chain contain
> just plain normal video filter so all existing filter can be used. The
> last filter of this chain will convert query_format/get_image/put_image
> calls in query_osd_format/get_osd_image/put_osd_image calls in the video
> chain.
> If the vo have some special osd capability it will simply respond to these
> calls. But if the vo doesn't support these calls vf_vo will have to
> sometimes restrict the dr.
> When dr to the vo is possible (for example when the decoder use a TEMP
> buffer) vf_vo can just give the same image as osd_image. When dr is not
> possible (for example when the image have the preserve flag) vf_vo will get
> a TEMP buffer from the vo (this should be possible with all vo's ?),
> copy the image to it and then give that as osd image.
> Ok as most of the time the osd isn't shown at all it would be nice to know
> before decoding if the osd need to display something or not. This way we
> can restrict the dr only if that's relly needed.
> 
> Ok, blah, blah but no patch ;) Anyway i'd like to know what do you guys think
> of that. Do you see any major flaw, or have any comments ? 

It sounds like OSD would still be slow, and in fact slower than the
current method with vo_mga and other similar vo's. The nicest would be
if we could have a function that copies the image and alpha-merges the
OSD all in one step. Especially if we could support he G200's nonsense
U/V packing in "YV12" mode...

Rich