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

[Uoti Urpala]

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.
Older ffplay without the reordering code doesn't seem obviously jerky,
but without status display I'm not sure whether it might just be slow
enough not to be able to show frames too quickly.

> > This code will sort the pts of consecutive B frame packets in ascending
> > order. There is more than one possible display order for a sequence
> > (longer than 1) of B frames but the code will give the same sorted pts
> > sequence for all of them, which cannot be correct for more than one of
> > the cases.
> 
> Unless the matroska muxer has already reordered the frames in ascending
> pts order (without reordering the pts themselves) ?

I think the decoder would fail if you fed the frames to it in a
different order. At least if you simply sort them in timestamp order
then B frames will use reference frames that have not yet been decoded.