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

[Dan Oscarsson]

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. You need more information from vo level to handle it
higher up and some of them will not be able to provide that.
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.

The main problem with mplayer that my patches fix for vdpau and xv, is
that mplayer cannot handle well the case when movie frames comes faster
then display vsyncs (and frames are synced to vsync). If frames comes
faster then vsyncs you must drop frames, if you want to keep audio in
sync. Even if you do not have a display that can run at 24hz, you can
see the problem by changing speed so that fps for the movies gets larger
then display refresh rate. 

> 
> 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?