[MPlayer-dev-eng] problems with mplayer and tv
Dan Oscarsson
Dan.Oscarsson at tietoenator.com
Thu Apr 30 08:52:45 CEST 2009
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).
More information about the MPlayer-dev-eng
mailing list