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

[Ivan Kalvachev]

On 7/24/11, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 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.

I'm also in favor of removing the ugly hack in mplayer.c .
I think I tried to track down its introduction, at least in maillist
and the case it "fixes" is double framerate of interlaced h264 .ts
content. As the mail hinted, it is our demuxer that produces complete
packets for single field (half frame), thus leading to double
framerate.

I may try to find name of the cited sample file (it is in our
collection) if you can't find it on your own.

Other than that, I've put some raw printf's in the correction code and
I haven't yet found a file "in the wild" that triggers it. I did
suspect it to cause A/V delay with immediatemode=0 on v4l2 capture,
but didn't got any prove.


>> 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?

It must be soft-telecine.
Most Film->PAL is done by stretching the audio as the ratio is smaller (24->25).