[Matroska-users] mkvtoolnix 3.4.0 released

Moritz Bunkus moritz at bunkus.org
Wed May 19 16:59:36 CEST 2010


here's Xavier's analysis of the problem in question. He's convinced that
it's not actually a bug in mkvmerge bug in mplayer/ffmpeg and that you
should file a bug report there. That earlier mkvmerge versions coped
better with that file is not exactly an excuse 'cause that lax checking
caused other bugs in the timestamp code.

Anyway. Here's Xavier's full message that you can also quote in any bug
report files against the other projects for which you can link to the
files on my web server if you want to:



Here is my analysis of the problem. I extracted both the elementary
stream in the AVI container and in the VOB container.

ffmpeg -i 3.4.0-sync-bug.avi -vcodec copy 3.4.0.avi.m2v
ffmpeg -i 3.4.0-sync-bug.vob -vcodec copy 3.4.0.vob.m2v

Then I looked for the first difference in the streams:
xxd < 3.4.0.avi.m2v > 3.4.0.avi.txt
xxd < 3.4.0.vob.m2v > 3.4.0.vob.txt

The first difference is at offset 0x0005240. I then analyzed both
streams with Elecard and looked at the difference in the packets at the
corresponding offset. Frame #22 starts at 0x000523c.

This frame belongs to a GOP with the following temporal reference fields:
       Type    temporal_reference
15     I   I    2   2
16     B   B    0   0
17     B   B    1   1
18     P   P    5   5
19     B   B    3   3
20     B   B    4   4
21     P   P    8   8
22     B   B    6   7
23     B   P    7   11
24     B   B    11  9

The previous table shows that there is a discontinuity in the
temporal_reference counter.

Section 6.3.9 of ISO-13818-3 states the following:

  temporal_reference -- The temporal_reference is a 10-bit unsigned
  integer associated with each coded picture.

  The following specification applies when low_delay is equal to zero.
  When a frame is coded as two field pictures, the temporal_reference
  associated with each coded picture shall be the same. The
  temporal_reference of each coded frame *shall increment by one modulo
  1024* when examined in display order at the output of the decoding
  process, except when a group of pictures header occurs. After a group
  of pictures header, the temporal_reference of the first frame in
  display order shall be set to zero.

Because the video comes from a DVD (which mandates that low_delay = 0)
then I can state without any doubt that the video in the AVI container
is not compliant with the standard. Furthermore if the statement that
the video was produced with mplayer is true, then it means that there is
a bug either in mplayer or in ffmpeg.

While deviations to the standard like the broken_link bit not set when
appropriate can be tolerated, this particular issue should not be worked
around in mkvmerge. Each tool has its set of responsibilities. Encoders
like mplayer/ffmpeg should always generate a bitstream that is
compliant.  Sync tools like tsMuxer deal with with discontinuities due
to packet loss. Finally muxers like mkvmerge encapsulate unmodified
streams into a container along with metadata extracted by scanning the
streams (indexes for example).

So I think you should consider this report as "not a bug" and suggest
the user to fill in a bug in mplayer or ffmpeg.




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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.matroska.org/pipermail/matroska-users/attachments/20100519/aae00c2a/attachment-0002.pgp>

More information about the Matroska-users mailing list