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

Aurelien Jacobs aurel
Mon Mar 12 17:09:02 CET 2007

On Mon, 12 Mar 2007 17:16:18 +0200
Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Mon, 2007-03-12 at 15:40 +0100, Aurelien Jacobs wrote:
> > On Mon, 12 Mar 2007 15:23:13 +0200
> > Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > > > > What's the reason for doing this kind of reordering?
> > > > 
> > > > Because without it, the affected videos are playing all jerky.
> > > 
> > > Playing all jerky in what player using what options?
> > 
> > ffplay, mplayer... no special option.
> ffplay seems to use the dts field. MPlayer uses the pts field but
> requires -correct-pts to handle non-monotonous timestamps from demuxer
> properly (so MPlayer is basically broken with -demuxer lavf if
> -correct-pts is not used). None of those cases really tests completely
> whether the pts values are correct (MPlayer without -correct-pts is
> broken, with -correct-pts it accepts some reorderings too and I think
> the ffmpeg dts calculations will do the same).
> > > Do you have a sample which shows this behavior?
> > 
> > http://samples.mplayerhq.hu/Matroska/V_MPEG_ISO/
> MPlayer -correct-pts (internal demuxer) plays those without problems
> even though -correct-pts disables the reordering that demux_mkv does for
> old timing code. Though as said above this does not necessarily mean
> that the pts values would be completely right.
> MPlayer -correct-pts -demuxer lavf (using latest lavf with your
> reordering code) shows some jumps in the A-V value which are likely
> caused by timestamp problems; I haven't checked whether those are
> problems caused by your reordering code or something else.

I will try to play with -correct-pts this evening.

> Older ffplay without the reordering code doesn't seem obviously jerky,

Right. That's because the pts was totaly wrong before, and acted as
if they where all 0. So the pts was generated by ffplay itsef (and so,
they was in ascending order). This created an A/V sync problem with
soraya.mkv (because first video packet should have a pts != 0).
I fixed this in r8333. Let's test this version and you will see
what's jerky.


More information about the ffmpeg-cvslog mailing list