[MPlayer-dev-eng] A/V sync filter

Tony Houghton h at realh.co.uk
Tue Feb 8 15:54:56 CET 2005


In <20050207192239.GM21208 at brightrain.aerifal.cx>, D Richard Felker III wrote:

> On Mon, Feb 07, 2005 at 11:30:08AM +0100, Diego Biurrun wrote:
> > Tony Houghton writes:
> > > I have a problem with loss of A/V sync since I started using the dfbmga
> > > driver. The picture starts to increasingly lag behind sound, and
> > > changing the audio delay with the +/- keys has no effect for some
> > > reason. I think it's caused by using vsync, but vsync is vital for
> > > watching interlaced TV, and seems to make the picture smoother for
> > > non-interlaced videos too.  Enabling framedrop drops far too many
> > > frames. -ao sdl makes a big improvement in the time it takes before the
> > > gap becomes noticeable but doesn't cure it altogether.
> > 
> > Have you already experimented with the -mc and -autosync options?
> 
> They won't help. The problem is that video out drivers are not
> supposed to be synchronous like this in MPlayer's design, but they
> have to be for playing interlaced video on an interlaced device. It
> _might_ work ok with -framedrop and -autosync together (better than
> -framedrop without -autosync) but I'm not sure. The real solution is a
> decent player design.

The docs say:

| Linux sound card drivers have compatibility problems. This is because
| MPlayer relies on an in-built feature of properly coded sound drivers
| that enable them to maintain correct audio/video sync. Regrettably, some
| driver authors don't take the care to code this feature since it is not
| needed for playing MP3s or sound effects.
| 
| [Snip]
| 
| Using MPlayer with a properly written audio driver will never result in
| A/V desyncs related to the audio, except only with very badly created
| files (check the man page for workarounds). 

Is that a bit over-simplistic and ignoring the case of using vsync? I
presume the feature mentioned is something to do with querying the
card's latency and that even if it is supported, MPlayer's problem is
that it usually uses it by adjusting the video frame rate, which it
can't do with vsync?

> Anyway the fundamental cause for the drift is that the audio and video
> clocks aren't quite in sync to real time. You might be able to fix the
> problem just by forcing MPlayer to do some resampling based on
> empirical data (overriding fps/samplerate) or by getting a better
> sound card with an accurate clock.

My sound card is a very cheap one, based on a CrystalMedia chip. Apart
from this problem it works very well. I've got onboard sound too, which I
haven't been using because it's too quiet, but I suppose it's worth a
try with the volnorm filter or something.

-- 
TH * http://www.realh.co.uk




More information about the MPlayer-dev-eng mailing list