[MPlayer-dev-eng] [PATCH] Fix for mpeg2 A/V sync bug.
Reimar.Doeffinger at gmx.de
Sun Jul 24 17:40:00 CEST 2011
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_
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
I do not have any NTSC DVDs though.
Is there anyone else who can reproduce the issue?
More information about the MPlayer-dev-eng