[MPlayer-dev-eng] Re: [PATCH] VFCTRL_PERIODIC_UPDATE

[Rich Felker]

On Wed, Jan 24, 2007 at 01:38:34AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Jan 24, 2007 at 12:52:42AM +0200, Uoti Urpala wrote:
> > On Tue, 2007-01-23 at 21:57 +0100, Michael Niedermayer wrote:
> > > On Tue, Jan 23, 2007 at 05:04:20PM +0200, Uoti Urpala wrote:
> > > > On Tue, 2007-01-23 at 08:39 -0500, Jason Tackaberry wrote:
> > > > > Right, being vo-independent is a requirement.  
> > > > 
> > > > A requirement for what? If you were willing to require -nodouble then
> > > > requiring a particular vo (or one of a few alternatives) should be minor
> > > > in comparison...
> > > 
> > > i very strongly vote for a vo-independent solution (=one which works with
> > > all VOs)
> > 
> > Are you sure you understand what you're voting about? Almost everything
> > in this whole thread is about features to support updating the overlay
> > more often than once per frame; parts of your post sound like you might
> > have missed that. 
> 
> well there are 2 possibilities either frame insertion filters (like tfields)
> currently work with mplayer or they dont
> if they do then the overlay filter is not affected by the time between input
> frames, it can just add more frames if the overlay chages
> OTOH if such filters are broken, they should be fixed first

The problem is that the vo always needs to have the "next frame"
loaded into video memory ahead of time, so that it can be displayed
when the time comes. If suddenly a new "next frame" comes in between
the preloaded frame and the currently displayed frame, it's a mess to
handle. Also the filter chain has no way of knowing whether the frame
it submitted is still pending display or already displayed so it can't
know where to insert the new frame even if it could do so..

If you know a good solution I'd be happy to hear it. Stuff like this
is what soured my interest in "g2" video layer design...

Rich