[MPlayer-cvslog] CVS: main/libmpdemux demux_mkv.c, 1.28, 1.29 matroska.h, 1.15, 1.16

[D Richard Felker III]

On Sun, Nov 28, 2004 at 10:35:31AM +0100, Moritz Bunkus wrote:
> Hey,
> 
> > could you explain this a bit? is mkv as broken as it sounds...or did
> > they actually do the pts/dts thing right like nut does?
> 
> Matroska stores frames in coding order (IPBB...), but the timecodes are
> display timecodes. So for 25 FPS video you'll get 0ms, 120ms, 40ms,
> 80ms...
> 
> (This does not apply to the "AVI compatibility mode" with the CodecID
> V_MS/VFW/FOURCC. Here the frames are stored as they are in an AVI,
> e.g. packed bitstream with dummy frames, and timecodes are assigned as
> if there weren't any B frames present. The reason that I've committed
> this code only now is that so far no player except VLC (and that
> includes playback on Windows) was coping with dts very well.)
> 
> MPlayer's libmpdemux/video.c calculates the duration of each frame
> (because the demuxers don't set that as you know). There are generally
> two ways video.c does that: 1. frameno * fps for fixed FPS formats and
> 2. current_pts - previous_pts for formats with variable or unknown FPS. 
> Matroska falls into the second category, but this obviously fails for 0
> -> 120ms and 120 -> 40ms.
> 
> Another option _might_ have been adding a "duration" field to
> demux_packet_t. But as MPlayer uses the current video pts in some other
> obscure way that I really don't get I opted for reordering the
> timecodes.

ok, thanks. so in summary you had to do this horrible hack because
mplayer is broken, not because mkv is broken. i would prefer you add
the duration field to demuxer packets, actually... reporting incorrect
timestamps is a very ugly hack.

rich