[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