[MPlayer-dev-eng] [PATCH] A/V sync improvement for TV streams

[Uoti Urpala]

On Mon, 2008-10-27 at 16:57 -0400, Laurent wrote:
> On 10/26/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > On Mon, 2008-10-20 at 19:23 -0400, Laurent wrote:
> > > On 10/17/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > > > If the condition is really only temporary then this shouldn't matter;
> > > > playing video for a short while based on wallclock time rather than
> > > > audio adjustments shouldn't make much difference. If the condition is
> > > > not temporary but playback is really proceeding faster than data is
> > > > received then this patch at most delays problems for a short period.
> > >
> > > In fact, when in this state, it happens that mplayer reads 100% of the
> > > available audio buffers from the demuxer quite permanently.
> > > As a result, the sync routines are never enabled, which causes a permant desync.
> >
> > If the status is permanent then this is not a good fix. A better simple
> > workaround would be to pause playback for a while if there isn't enough
> > data.
> >
> I would rather adjust the playspeed to compensate for the audio drift.

That could be better when you have a source like a TV card that returns
data at a precise rate, but it's also trickier to implement and probably
no better for network streams where varying lag can make accurate speed
estimates impossible. Something like it is needed though if desync in
the other direction is a problem (MPlayer falling increasingly far
behind the source).

> Though, this does not fix the sync issue.

Why do you say that? Any mechanism that prevents MPlayer from getting
"too far ahead" so that there is not enough data to fill the audio
buffers avoids the need to handle sync with partially filled buffers.

Which demuxer is used in your case btw? I think most of them block if
there isn't enough data instead of returning (temporary) EOF.

> > If you try to keep playing without enough audio you'll eventually get
> > audio buffer underruns. Exactly what effect those have depends on the
> > audio driver, but it's something that should be avoided.
> >
> 
> In my case, at start, MPlayer buffers around 1 second of audio.
> As the input/output audio drift is really small, it takes tens of
> hours to reach a buffer underrun (at least during my tests).

The amount buffered depends on the audio output driver used. If it's
much larger than needed to avoid underrun then it could be beneficial to
reduce the buffer size (if the output API supports that). The drift
speed depends on the difference between source and audio card playback
rates; I've heard of audio cards with quite significant differences from
nominal playback rates.

> However, during all those hours, MPlayer will loose sync, unless the
> EOF issue is fixed.

I agree it will lose sync, but I don't agree with the way you're trying
to avoid it. MPlayer shouldn't keep playing the file in a constant
degraded state with EOF set and audio buffers filled below the standard
amount. I also suspect that most other people would benefit
significantly less from your hack; typical audio output buffering at
least on Linux is much less than a second, and I also expect higher
drift rates to be common.