[MPlayer-dev-eng] Libvo2 draft

[David Holm]

Ivan Kalvatchev wrote:

>--- David Holm <dholm at telia.com> wrote:
>
>>>
>>>
>>>>>subpicture - this function will place subtitles.
>>>>>
>>>[snip]
>>>
>>>>I think this is also unnecessary, it's better this
>>>>is handled by the 
>>>>libvo2 core depending on the VO2CTRL_OVERLAY
>>>>control. We want to get 
>>>>away from device developers having to do stuff
>>>>themselves the core might 
>>>>as well do. If really needed I prefer implementing
>>>>something like 
>>>>VO2CTRL_OVERLAY_CALLBACK and passing it a callback
>>>>function as parameter.
>>>>
>>>No no, this will work with X, but it will be
>>>
>>useless
>>
>>>with vo2_gl, as it (will) draw(s) it as texture.
>>>Libvo2 core will draw subtitles ONLY if there is NO
>>>
>>hw
>>
>>>support.
>>>
>>ok, but say this is an X interface, then this
>>interface will be called 
>>with NULL values or what?
>>then I see the point of having it, especially since
>>IMGFMT_SUBPIC is 
>>going to be implemented...
>>
>Maybe i have been a bit unclear, but Yes if you want
>to remove subtitles then you call subpicture with NULL
>as first argument and it will not draw subtitles. In
>case of overlay or texturing this could make bitmap
>loop simpler.
>
The idea is that the libvo2 core will handle overlays unless they are hw 
accelerated, this function could be implemented for hw_acc (ie my dxr3 
has a subpic channel). But I don't think we should leave it to the 
device developers to use this function unless specifically specified by 
a control(...)
I'm suggesting superimposing = libvo2 core draws it over the frame, 
callback(or function call) for those who want to implement it in the 
device itself and pure subpicture format (libvo2 converts it to 
subpictures) for hw cards

>
> 
>
>>>
>>>I thouth on it before proposing it in this form.
>>>
>>Here
>>
>>>are the resons:
>>>1. Not all atributes are available on all devices,
>>>there must be some kind of query and for them. This
>>>will prevent us from double apply e.g. BRIGHTNES -
>>>
>>1st
>>
>>>in DivX4Linux and 2'd in the overlay:)
>>>
>>I still don't see how this applies to putting them
>>all in one control, 
>>my idea is this
>>case VO2CTRL_SET_BRIGHTNESS:
>>    if( supported )
>>        set it, return VO2_TRUE;
>>    if( not supported )
>>        return VO2_NA;
>>if VO2_NA is returned DivX4Linux handles
>>brightness...
>>
>>>2. There are more atributes that these, like
>>>
>>keycolor
>>
>>>- have you seen bsplayer ability to display move as
>>>desktop. You can watch movie and to see some icons
>>>
>>and
>>
>>>windows at the same time. To do this you will need
>>>
>>to
>>
>>>make some tricks with keycolor.
>>>Anyway it realy will be easyer to have them
>>>
>>expanded,
>>
>>>but GET/SET_ATTRIBUTES should exists at all cost.
>>>[snip]
>>>
>>Please elaborate on what you mean by putting it all
>>in one control 
>>instead of having one for each "function".
>>
>
>I take the idea from the Xv atribute interface, with
>the hope that vo2_xv will need 3 lines to do it. It
>will provide way to use many atributes without need to
>add them all to the libvo2.h, it will be flexable
>(runtime). The bad is that it will be control() in the
>control(). The good is that users could set atributes
>without need to recompile mplayer (not very useful):
>
The coders add stuff to libvo2.h, and I'm guessing it will be pretty 
huge after a while anyway. I still can't see anything positive with 
placing them all in one function... but,. well, I supposed we could have 
something like this (don't know what these values are called ;)
And what do you mean by recompiling? control() works in realtime, if you 
change a value by a control() it takes effect immediately (depending on 
implementation)
union { float brightness, hue, saturation };
VO2CTRL_SET_ATTRIBUTES:
           ...

>
>
>>//David Holm
>>
>
>Best Regards
>  Ivan Kalvachev
>p.s.
>I will be in the chat room (IRCnet#mplayerdev) for a
>few hours if you like to meet there
>
I haven't got any working ircnet servers... if I find one I'll be there...

//David Holm