[MPlayer-dev-eng] [PATCH] automatically insert vf_expand for displaying OSD

[Attila Kinali]

On Mon, Sep 20, 2004 at 09:41:39PM -0400, D Richard Felker III wrote:
> > > not possible, it's hopelessly slow. with subtitle code in the vo
> > > driver, it can blend directly into video memory. because the vf layer
> > > sucks (actually it's very very hard to design a vf layer where this
> > > would work) that can't be done with vf, so there'd be a ton of extra
> > > copying for subtitles, and movies would be unplayable on my box!
> > 
> > I somewhat dont like this answer :)
> > I thought that vf modules could selectively buffer strides or not.
> 
> you mean slices. 

err.. yeah, slices.

> but the problem is you can't know which ones to
> buffer until osd drawing time, which is _after_ slice time. 

Hmm.. Dont we know when displaying a frame how long it will be shown ?
Can't we then tell the osd drawer which time interval it should handle
the next and thus enable it to intercept the slices it needs when we
draw them afterwards ? Or am i mixing up a few things ?

> also this
> is still slower than the current method, which just does a little bit
> of reading from video memory (bad, slow!) and hopes that the osd text
> is small enough not to require much reading.

Why would it be slower ? If we just catch those few slices we need,
memcpy them, overwrite them with our osd and memcpy the slice back over
the buffer before we run the decoding of the next frame, then this
shouldnt be so slow. At least all operations are handled within "fast"
RAM (compared to the readout of video mem).

> > Do you have any other ideas how this could be done in a more or less
> > fast way ?
> unfortunately no.

Ok, then here is a second aproach in case the above doesn't work: 
How about callback system in the vo layer. Ie tell the vo where we 
have to take care of osd (ie x/y/w/h of the regions where osd is drawn)
and then let the vo module perform its usual memcpy for the regions not
affected. Those which are affected are passed trough a function of the
osd renderer and changed on the fly before write into the video mem
(note that video mem here is rather generic and can also be RAM for
modules like x11 that do another memcpy/processing step).
I currently dont have a clear idea on how to do the callback, but at
least this would solve the problem of every vo module having a draw_osd
and shouldnt be too complicated. Speed should be about the same as the
aproach above.


			Attila Kinali