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

[Uoti Urpala]

On Mon, 2009-04-06 at 15:33 +0200, Dan Oscarsson wrote:
> On 2009-04-06 at 15:35 +0300 Uoti Urpala wrote:
> > On Mon, 2009-04-06 at 13:22 +0200, Dan Oscarsson wrote:
> > > My patches include:
> > 
> > Are these patches visible somewhere? Some comments below based on what
> > your descriptions tell.
> 
> No, I wanted to hear your comments before I post them.

Your descriptions alone did not have enough detail to evaluate the
patches.

> > >   - an option to vdpau: max-delay
> > >     which if set to 0 results in 2 output surfaces and working
> > >     like current code.
> > >     if set will drop frames if a frame would be delayed longer
> > >     then given value.
> > 
> > Drop which frame? Dropping the latest frame before seeing the following
> > ones is always undesirable as you can't know when or if those next ones
> > appear - playback may pause and then you'd be stuck showing the wrong
> > frame.
> 
> 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.

> frame in the queue to be displayed. So I know that at least one more
> will be displayed. If I do not drop the queue of frames to display will
> grow and you have to wait for it to drain easily getting audio out of
> sync.

You seem to misunderstand what I meant. The VO will display at least one
more frame it didn't before - but that's just an _old_ frame that should
actually have been displayed before. If you drop the latest frame that
arrived to the VO, without knowing anything about frames following that,
then you will be stuck showing the wrong frame if the dropped one was
actually the last frame before pause or other long delay.

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.

> > >                       the number of output surfaces will be adjusted to
> > >     match.
> > 
> > Adjusted how? How can you map times to numbers of surfaces? Are you
> > making assumptions about the video having a consistent FPS?
> 
> The max delay is in vsyncs, the number of output surfaces is set to the
> number needed to handle that max delay in shown a 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.

> > >   - a global option: match-vsync-speed
> > >     that will change speed of movie to vsync speed (if nearly the same).
> > >     this allows movies to be shown with less frame dropping.
> > 
> > Change based on what? Are you making assumptions about the video having
> > an FPS value? Or using some kind of more local logic (what?). And how do
> > you change the speed?
> 
> 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?

> I have tried to dynamically change speed but each change disrupts
> mplayer to much. Would probably be easier to do if mplayer was
> multi-threaded.

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

> > >   - a global option: card-time-correction
> > >     that gives correction that is needed to correct that graphics card
> > >     have a time that have a different speed then system time.
> > 
> > Do you really need this? Can such differences not be corrected for
> > automatically at runtime?
> 
> I tried, but the difference is very small so it is better to calculate
> it once for each card you have using a long time period to measure over.

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.

> > >   - an option to vdpau: time-corr
> > >     which measures card time and prints correction value at end of
> > >     movie. To be used with option: card-time-correction
> > 
> > What does this measure against? If there is no sound then the system
> > clock is what matters; but in the usual case where there is sound the
> > system clock has little significance and the important reference is the
> > audio playback speed.
> 
> I query using vdpau the card time and the system time at vo init, and
> then again at uninit. Then calculate the correction based on how much
> the card time and system time differ.

As described in the quote this is the wrong thing to measure for videos
with sound if what you care about is relation to the overall playback
rate. And if you care about conversions between system and card time
then as described above I think that's better handled by remeasuring the
absolute difference.