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

[Uoti Urpala]

On Tue, 2009-04-07 at 11:26 +0200, Dan Oscarsson wrote:
> On 2009-04-06 at 17:51 +0300 Uoti Urpala wrote:
> > 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.

The user probably doesn't care that much exactly what frame MPlayer
pauses on - but the VO must show the frame that it is paused on,
whatever that is. If the VO shows something else that doesn't mean
MPlayer is "pausing on that frame" - MPlayer is still pausing on another
frame, with the VO showing the wrong thing.

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

Yes but we were talking about the case where your patch would be
relevant.

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

How are delays elsewhere supposed to matter for the VO in this context?

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

Sure but irrelevant as far as I see. You're not saying anything that
would be relevant to the subject...

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

Yes if you want to be able to do it simultaneously with decoding, but
again this seems mostly irrelevant to what was being talked about...


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

You snipped the quote showing what I was replying to, and are now
talking about something quite different from the "particular issue" my
comment referred to.

> > 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 overall speed is *NOT* based on system time in the usual case, as
I've already told you a couple of times.

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

Again, you're measuring the wrong thing for that use.