[MPlayer-dev-eng] [PATCH] Fix for mpeg2 A/V sync bug.

[Reimar Döffinger]

On Mon, Jul 11, 2011 at 09:17:44PM -0400, Steaphan Greene wrote:
> On 06/26/2011 02:49 PM, Reimar Döffinger wrote:
> > On Fri, Jun 24, 2011 at 09:30:57AM -0400, Steaphan Greene wrote:
> >> The attached patch fixes the bug with vob files (and, presumably other
> >> mpeg2 content) caused by the A/V sync code added with r32055/32056.  I
> >> believe this solution should cause no other harm.
> >>
> >> Basically, it now just removes the last_pts data when one of these pts
> >> changes occurs in the mpeg2 stream.  That way, the A/V resync code in
> >> question ignores this frame, and no longer breaks anything.
> > 
> > But this is not code for non-uniform time-stamps really but it is
> > reordering.
> > And my suspicion is that your change only makes it so that non-B-frames
> > which MPlayer can detect break the other correction code you pointed out before.
> > If so you could just avoid the obfuscation and put the whole other code
> > under "if codec != MPEG-2" for exactly the same effect.
> 
> I've attached an updated version of my band-aid for this bug based on
> current svn (r33877).  I believe this is still correct, as, if I am
> understanding you correctly, this case is due to an out-of-order frame,
> which means that the time stored in last_pts really was not correct, as
> it did not actually store the pts of the truly-previous frame.
> 
> ...I hope that explanation made sense to more people than just me.

The B-frames are the out-of-order frames, which are the ones you _aren't_
touching.
However the other frames are delayed whereas B-frames are not.
There are files without B-frames, in which case the change would remove
last_pts for _all_ frames.

> I have updated the comment to reflect this.  Of course, I could still be
> wrong about exactly what's happening here.  I am only confident from my
> traces that this fixes the problem I found, and only this problem, and
> causes no other harm.

I think you mentioned a case for which the time-stamp correction code
is necessary? I think that code is rather bad anyway: I never leads
to good timing, it can only convert completely wrong timing into
ok-timing as far as I understand and it should probably be restrained.

> Without this patch, the current version of mplayer in SVN is not able to
> properly play most of my DVDs.  So, unless a better solution is obvious,
> I'd request this patch be applied.

I tested about 10 different DVDs and not a single one has the slightest
issue.
I do not have any NTSC DVDs though.
Is there anyone else who can reproduce the issue?