[MPlayer-dev-eng] A better explanation of the A/V sync problem

[Balatoni Denes]

Hi!

There was a similar problem with rm files with video starting ahead of audio - 
with -mc 5 it slowed videoplayback down (essentially stopped it),
and audio could catch up.
I don't know whether that worked for rtp?
Anyhow imho dropping packets somwhere in the a-v sync 
block is a good idea. (or -framedrop drops the whole videopacket?
than that's good)

bye
Denes

> The obvious solution to this problem is to notice when the presentation
> times on the two incoming streams start differing by more than a
> threshold.  When this happens, start discarding incoming packets from the
> stream that is running behind, until its presentation times catch up to the
> other stream.  This is what I've now done in my RTP demuxer code.  In the
> 'pausing' example described above, when the code notices that video has
> jumped way ahead of audio, it will read and discard all following audio
> packets until audio catches up again.  I.e., if incoming data for one
> stream gets dropped (by the OS) during the pause, then a corresponding
> amount of data for the other stream will also get dropped (by MPlayer's RTP
> demuxer) to compensate.
>
> Within a day or so I will be submitting a patch to my RTP code that
> includes this fix (plus a lot more goodies, such as MPEG-4
> support).  However, I think that in the longer term, it might be better if
> the general MPlayer A/V sync code did this instead.
>
> 	Ross.