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

[Uoti Urpala]

On Wed, 2009-04-08 at 08:48 +0200, Dan Oscarsson wrote:
> On 2009-04-07 at 16:11 +0300 Uoti Urpala wrote:

> > > 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.
> 
> Maybe not, but mplayer manages timing by calling getTimer which follows
> system time.

The timing involves use of system time, but that's not very relevant
when the system clock still doesn't determine the overall rate.

>  Though mplayer syncs video to audio and I suspect audio
> runs on audio cards clock which may not follow real time.

Exactly.

> > Again, you're measuring the wrong thing for that use.
> 
> That may be - but it works for all movies I have viewed.

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.

> To better handle the cases where a weak CPU is not enough to decode some
> frames/audio in time or to handle temporary system changes that make
> some frame decoding take to much time, and to really be able to sync
> audio with video, I would want mplayer to be redesigned to have separate
> threads that do audio and video decoding queueing both audio and frames,
> and an other thread handling the playing of audio and displaying if
> frames. That way variations in decoding time could be handled better and

In practice this isn't really needed for audio, but would sometimes be
beneficial for video.

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

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