[MPlayer-dev-eng] Reverted patch of time-based PTS locking

Reimar Döffinger Reimar.Doeffinger at gmx.de
Thu Aug 16 19:29:30 CEST 2012


On Thu, Aug 16, 2012 at 11:22:02AM +0200, Pásztor Szilárd wrote:
> Reimar Döffinger:
> > Hm, I couldn't really think of a solution that is 100% sure to work
> > in any case imaginable.
> > Though something a bit less like that might be ok, but I'm not convinced
> > it's going to be easy still.
> 
> Ok here is the concept.
> H264 elementary streams, as I found out, contain no PTS info (sorry I'm not
> that expert on video codecs, so I didn't know that). But containers have PTS
> in the wrong order, so it's better to correct that in place, right after
> demuxing.

I don't know what gave you that idea. The container does have PTS, but
H264-ES has timestamps just as much as MPEG-2

> In video_read_frame() where demuxing is separated by codecs, PTS correction
> in the H264 part cannot affect any other streams. I already have a working
> patch for it, just need to make it a bit more reliable.

The problem with NTSC exists as much for H.264 as for MPEG-2.
Simply transcoding the DVD would result in a H.264 file that your
original patch would have broken.

> > I admit I'm not able to see the difference.
> > Though I don't understand why it should get _worse_ with -mc 1,
> > with -mc 100 yes, but with -mc 1 it should ignore those A-V sync
> > jumps.
> 
> It only ignores jumps at -mc 0. All other values mean jerk, even if not much.

Actually with the default it should be at most 10% of the frame time, so
around 4 ms.
I wonder if something that takes c_total into account wouldn't detect
and eliminate this "jerking back and forth with not real overall effect"
better.


More information about the MPlayer-dev-eng mailing list