[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c

[Uoti Urpala]

On Mon, 2007-03-12 at 23:19 +0100, Aurelien Jacobs wrote:
> On Mon, 12 Mar 2007 22:03:56 +0000
> M?ns Rullg?rd <mans at mansr.com> wrote:
> > I don't see any jerkiness playing those with ffplay from svn r8317 or
> > with TCVP using its matroska demuxer.
> 
> Try with ffplay r8333.
> r8317 was broken (pts was meaningless so ffplay generated the pts itself,
> which lead to properly ordered pts and smooth playback, but AV desync
> when both streams didn't start at the same pts).

I took a quick look at the logic libavformat uses to calculate dts based
on pts and it seems generally broken. ffplay uses the dts fields for
playback; with this dts-calculation code you cannot expect ffplay to
work even if the demuxer sets the pts fields correctly (unless it
directly sets dts too). MPlayer uses the pts fields and should work with
-correct-pts.

So I think the timing problems you saw (at least the obvious ones) were
not caused by the demuxer. ffplay failed because it uses the dts fields
and the pts-to-dts logic outside the demuxer is broken. MPlayer failed
because it only works with -demuxer lavf if you also use -correct-pts
but you were not using that. The reordering code should be removed from
the demuxer unless you have some other justification for it (but I'm
pretty sure it can't possibly be correct).