[MPlayer-dev-eng] problems with mplayer and tv

[Dan Oscarsson]

As it looks you do not want to use my fixes to mplayer I will here
describe the problems and how I solved them.

When I got a lcd tv capable in using 24hz (23,976) display rate there
was a possibility to get really good viewing of movies. But not with
mplayer. My tests/analysis showed:
 - I have NVIDIA hardware that syncs video frames to vsync
 - The problems occur when mplayer plays movie at a frame rate
   that is faster than vsync rate.
 - with vo sdl: audio gets out of sync
 - with vo xv: tearing
 - with vo vdpau: audio get out of sync

The problems in vo happens because:
 - in sdl, mplayer waits in flip_page for vsync
 - in vdpau, mplayer waits in draw image for vsync
 - in xv, mplayer overwrites a shared buffer

Reading att forums on the web I see that others have the same problem.

My analysis of how mplayer works shows that for audio, mplayer resamples
audio to adopt to play speed (though I have not checked this very much),
and for video mplayer assumes that frames are displayed when given to vo
through flip_page.

As I see it, if frames are sync:ed to vsync, mplayer must drop frames if
play speed is greater then vsync speed. Or mplayer must resample the
frames to a matching rate.

My fixes to the problems:
 - sdl: I am not using it and have not fixed it.
 - xv: fixed so that xv drops frames instead of over writing
   buffers. No tearing but you might notice when a frame is lost.
 - vdpau (where I have put most of my time):
     - no waiting for vsync
     - drop frame when video is to much out of sync with audio
     - automatically adjust play speed to match vsync speed.

The results of my fixes:
 - xv: audio/video in sync, no tearing, frames dropped when mplayer
   gets to far ahead.
 - vdpau: audio/video in sync, no tearing, practically no frames
   dropped (often 1-2 are dropped during start due to startup jitter
   in mplayer processing).