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

[Dan Oscarsson]

On 2009-04-09 at 05:12 +0300 Uoti Urpala wrote:

> Variation between movies on the same system is unlikely (at least as
> long as they use the same audio output samplerate). Variation between
> different audio systems is much more likely. Does correction based on
> system/graphics rate differences work noticeably better for you than no
> correction at all? There are some audio systems with noticeably inexact
> playback rates, so it's unlikely to be the same for all people.

By just adjusting speed so that it matched the fps of the graphic card
in card time, mplayer drifts so that about 1 frame per 10 minutes have
to be dropped. Adding system/graphics time correction I get about zero
frame drops.

What I really need is a way to have mplayer sync to video time (vsyncs)
instead of audio card time. To do this mplayer have to be able to change
speed of audio in very small increments. I have tried doing this by
doing a reinit_audio_chain but even a very small change makes mplayers
timing change to much to handle frame display correctly. Multiple
threads could make it work.

> 
> > we could sync both audio and video to a suitable clock. But that
> 
> What do you mean by this? Threading would not really help with any
> syncing; it'd only help you keep using the CPU for decoding near the
> time where you need to display a frame.

If decoding is done in separate thread than frame display/audio play
syncing, both audio and video decoding can be done in advance for more
than one vsync period giving the syncing thread more possibilities to
keep audio and video in sync as variations in decoding time is less
affecting syncing. As the frame vsyncs are very few compared to audio
sample rate, at lost frame can be much more noticible than a lost audio
sample (or slight variation on audio sample rate).

To make least amount of changes to mplayer I just adjust movie play rate
speed so that both audio and video is changed - in a try to get a speed
that matches the vsync rate. Currently I only do this by measuring
graphics vsync rate and expect audio to play in correct rate. For my two
systems it looks like it works. If I could find a way to measure time in
audio card, that could be added.

> 
> > requires much greater change in mplayer than by current small
> > modifications.
> 
> I'm considering implementing support for queuing video frames in
> advance. That would have uses even before any threading support.

Yes, but can it be done without threading?

And even with frames queued in advance, if audio rate do not match vsync
rate in the case where movies fps is near vsync rate, you will have to
drop frames now and then.