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

[Moritz Bunkus]

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.

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20041128/cdf770b2/attachment.pgp>