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

[D Richard Felker III]

On Sat, Sep 25, 2004 at 11:29:05AM +0900, Attila Kinali wrote:
> 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 ?

you're mixing things up. the vf layer has absolutely NO idea of the
sequence of frames when doing slices, and in fact it NEVER sees
timestamps, not even without slices. that's why g1 sucks so bad.

> > 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).

but the number of pixels is so few that it's faster just to read a few
from video memory than to have to backup large cache-polluting
complete slices.

> > > 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).

exactly the same problem as with slices. you simply DON'T KNOW what
you want to draw on the osd at frame drawing time.

rich