[MPlayer-dev-eng] Fixes/enhancements to vdpau

[Dan Oscarsson]

On 2009-04-06 at 17:51 +0300 Uoti Urpala wrote:
> > 
> > I normally allow a delay of 1,3 vsyncs. Then there will be at least one
> 
> Why so much? If you created this especially for the case where the
> display FPS is as low as 24, then keeping such a constant desync for
> faster video sounds undesirable.

It is not a constant desync. It is a maximum allowed out of sync time.
As mplayer sends frame to be displayed ignoring when vsyncs occur and
how long it is between each, it may be a long or a short delay before a
frame is visible, and mplayer may also try to display more than one
frame within one vsync period. If frame display is sync:ed to vsyncs,
only one frame can be displayed per vsync. If you use a way that does
not sync to vsync, like the blitting engine in vdpau, frames will be
dropped by the graphics card outside our control.

mplayer tries to adjust audio-video sync by displaying frames quicker or
slower. This does not work that well if frames are only displayed one
per vsync without dropping frames that comes too quickly.
When playing a 24hz movie at 50hz or 60hz, you have about 2 vsyncs per
frame to display - in this case displaying frames quicker or slower
works quite well as there are 2 possibilities per frame time. When frame
display rate is greater than vsync rate you have to drop frames now and
then unless audio speed is changed.

> 
> Consider this extreme case: the user sets playback speed to 100 and then
> pauses after a while. Most frames need to be dropped, but you must end
> up showing the last frame the VO received before the pause.

Why is last frame the important one? If I pause a video running att 100
times normal speed it does not matter which frame it pauses on - I
cannot press pause quickly enough to pause at an exact frame.


> This sounds like an inferior overall approach which needs options and
> user configuration that could be avoided. If you know the vsync interval
> and the display times of previous frames, then if you query the timing
> of the next frame before committing to displaying the current one you
> should be able to implement a system that always keeps the delay under
> one vsync. Better driver support (either allowing the program to remove
> queued frames, or a mode that automatically removes them if it's clear
> they cannot be displayed before it's time for the _next_ queued frame
> already) would make this easier, but even without that it should be
> possible to implement a reasonably accurate system.

The normal case will display frames with a delay under one vsync. But to
handle cases where mplayer cannot keep the pace (for example due to long
audio or video decoding) you have to handle delays over one vsync. Also,
as mplayer do not sync displaying to vsyncs, if may want to display a
frame just after a vsync - it will then take nearly one whole vsync
before the frame is displayed.

To be able to do timing on frame displaying in the vo you need a
separate thread that handles that.


> > It is based on the fps value of the video. And currently I assume it is
> > constant - most movies are. The speed is changed by changing
> > playback_speed (i.e. the same as change speed with the speed option).
> 
> How does that interact with the user changing playback speed at runtime?

They are free to do that. I have added so when you press backspace to
return to normal speed, it returns to the vsync:ed speed instead of
exactly 1.0.


> 
> As far as I can see threading is not in any way relevant to this
> particular issue.

Multi-threading would allow an independent frame display thread that can
match frame displaying to vsyncs. This cannot be handled in main mplayer
thread as it only calls vo routines when it wants to send a frame to be
displayed.


> So why would you actually need to know the rate difference? You can
> remeasure the absolute difference so it won't diverge, and timing using
> the card timestamps should be over short enough timespans that rate
> differences are irrelevant.

The CPU clock and the card clock do not have the same pace. When I read
the time between two vsync:s I get the interval in card time. As mplayer
plays videos using system time and I adjust speed of a movie to match
the time between vsync:s (to reduce frame drops), to get best results I
have to convert the vsync interval from card time to system time.
To do that conversion I need to know the rate difference.

Yes, I can remeasure the difference and see the drift but then I would
need to adjust mplayer speed now and then to adjust for that. Each speed
modification may result in frame drops so it is better to change to
correct speed once - and to do that I need to know the rate difference.