[MPlayer-dev-eng] a-v sync fixes/cleanup backported from g2
Arpi
arpi at thot.banki.hu
Thu Aug 7 21:55:18 CEST 2003
Hi,
> On Thu, Aug 07, 2003 at 09:35:18AM -0700, Mark Guptill wrote:
> > On Tuesday 05 August 2003 03:32 pm, Arpi wrote:
> > > Please tets it, before commit. I think it's ok, but should be tested
> > > on very slow system (with and without -framedrop, i wanna know if A-V
> > > starts drifting away from 0 then).
> >
> > i tested your patch with a mpeg2 video without framedrop A-V sync was reported
> > to be in sync but the video was actually slower than the audio. with
> > framedrop A-V sync was in sync. logs are attached.
>
> I haven't tested this patch, but this might very well be the case if
> it makes behavior more like -autosync. With -autosync enabled, mplayer
> always reported A-V: 0.000. Actually this was kinda nice, since
> mplayer didn't massively overshoot in correcting it and make A-V:
> -5.xxx, but it's annoying from a user perspective...
Hmm, I didn't know that -autosync was already so.
Anywat that is the expected behaviour, as A-V sync value reports
the streams sync, not the audible delay. We should do teh same as in
g2, so either display 2 values (streams and audible sync) or fake it,
ie. add timer underflow and inaccuracy values to the displayed A-V delay.
At least it have an advantage: we can split the YourSystemIsTooSLow
message to multiple parts, depending on it's really too slow sys
(timer underrun), buggy soundcard (inaccurate timing), or broken file
(streams desync).
A'rpi / Astral & ESP-team
--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
More information about the MPlayer-dev-eng
mailing list