[MPlayer-dev-eng] [PATCH] patch 1: vdpau

Uoti Urpala uoti.urpala at pp1.inet.fi
Mon May 4 16:19:45 CEST 2009


On Mon, 2009-05-04 at 08:22 +0200, Dan Oscarsson wrote:
> On 2009-04-27 at 22:30 +0300 Uoti Urpala wrote:
> > 
> > The patch looks rather large. Does it give significant benefit over
> > implementing a framedrop mode to skip the flip_page() call if it's
> > already late (which would be simple to implement, and also work with -vo
> > gl which can be affected by a similar issue)?
> 
> After thinking about this some what more, I think while my patches just
> fix vdpau and xv, they are much simpler to add then reworking mplayer to
> work for all vos.

That's false. You must be assuming some different kind of
implementation. What I talked about above was basically adding a test
before calling flip_page: "Would this flip_page() call be late by at
least amount x? If so then skip it.". This would certainly be a lot
simpler than your patches. xv could additionally need a XSync() call in
a suitable place, since I've seen behavior where lots of video updates
accumulate in the X command queue (so from MPlayer's point of view the
flips have happened, but in fact they've only been queued).

>  You need more information from vo level to handle it
> higher up and some of them will not be able to provide that.

To implement a mechanism that is aware of individual vsyncs yes, but
that's not necessary to avoid the basic desync due to update rate
limitation issue.

> Also, to implement queueing several frames in advance, you will need to
> implement part of that inside the vo layer (for example with hardware
> decoding in vdpau). For vdpau the queue will probably have to be inside
> vo.

Yes. Is this in some way relevant to what else you said?


> > Anyway I intend to take a closer look at VDPAU myself and probably
> > implement some improvements that require larger MPlayer changes, such as
> > allow queuing multiple frames ahead and support advanced deinterlacing
> > without introducing incorrect delay.
> 
> Good, but will that take one year before we get something? I have seen
> many have the problem I have, and more will come as more gets a modern
> tv. Are we going to have mplayer work badly on a new tv for a long time?

The work itself will not take that long. I'm not yet sure when I'll do
it.




More information about the MPlayer-dev-eng mailing list