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

[Michael Niedermayer]

Hi

On Tue, Jan 23, 2007 at 10:06:27PM -0500, Rich Felker wrote:
> 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...

my "solution" simple is to ignore the VO state and prevent frames which
are in the far furture from passing trough the overlay filter too early
one simple way to do this is to block them before the filter chain another
is to duplicate the last frame in the overlay filter if the filter system
can handle that currently (it did work once at least from a user point of
view)

with that the time between the 2 frames in the VO is guranteed to be small
and so the 1 frame delay this causes with double buffering is guranteed
to be small

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070124/2e6b5f32/attachment.pgp>