[Matroska-devel] MVC codec in Matroska container

Mike Chen mike at makemkv.com
Sat Dec 8 09:36:49 CET 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a reply to
http://lists.matroska.org/pipermail/matroska-devel/2012-November/004311.html
as I'm not subscribed to the list and can't reply in thread. Please
keep me in CC.

Adding a new EBML element for MVC is a bad idea for at least two reasons:
1. A codec-specific structure is added at container level
2. It does not solve future problems with upcoming AVC extensions (SVC
video, multi-group MVC)

We've discussed the issue with Peter in private email and that's the
solution I've proposed and he's OK with:

As the information is codec-specific, let's extend the
CodecPrivate data. No new EBLM elements are necessary, only data in
CodecPrivate is extended.

Currently the meaning of CodecPrivate field for AVC tracks is
"AVCDecoderConfigurationRecord data". To maintain backward and forward
compatibility, the meaning of this field will be redefined as:
"All data necessary for decoding, as a set of atom boxes in arbitrary
order, with an exception that first atom MUST be 'avcC' without size
and ID (just plain AVCDecoderConfigurationRecord data)".

So, in MVC case, there will be a single mvcC atom following the
AVCDecoderConfigurationRecord as in example below.

This way we'll achieve all goals-

1. Backward compatibility - existing players would ignore everything
after initial AVCDecoderConfigurationRecord

2. Forward compatibility - any new atoms may be added in future (SVC
configuration, MVC group information, etc) at CodecPrivate level, in
sync with AVC specification.

3. Acceptable level of ugliness - there is a well known formula to
calculate the size of AVCDecoderConfigurationRecord, so parser code
would skip the record and then check that the rest is a list of atoms.
Should be quite safe and not very hard to implement.



I've prepared a test file that can be downloaded at
www.makemkv.com/mvcctest.mkv

CodecPrivate dump from that file:

+ CodecPrivate, length 381 (h.264 profile: High @L4.1) hexdump
01 64 00 29 ff e1 00 16 67 64 00 29 ac 2d 90 07 // <-
AVCDecoderConfigurationRecord (avcC token without len & id)
80 22 7e 5c 04 40 00 00 fa 40 00 2e e0 25 01 00
58 68 ee b0 cc e3 49 1c 2c 50 4b 8c c6 72 8c 86
06 8c 08 70 41 f9 46 43 03 46 04 38 20 fd 08 8e
12 20 31 c1 07 e2 0d 14 24 40 63 82 0f c4 1a 28
48 80 c7 04 1f 8d 25 34 ba b5 24 b2 4d 3e 68 40
5c f3 45 62 f1 51 9f 19 ff fd 1a 9a 5d 78 af 8c
fc 29 fc 31 ff ff ff c3 30
00 00 01 00 // <- mvCC box len. Old decoders will ignore everything
below this point
6d 76 63 43 // 'mvcC'
01 80 00 29 ff 02 00 16 67 64 00 29 ac 2d 90 07 // <-
MVCDecoderConfigurationRecord
80 22 7e 5c 04 40 00 00 fa 40 00 2e e0 25 00 27
6f 80 00 29 4b 0b 64 01 e0 08 9f 97 01 10 00 00
3e 90 00 0b b8 09 55 2a aa ca 61 52 c2 a8 00 00
1f 48 00 05 dc 04 a0 02 00 58 68 ee b0 cc e3 49
1c 2c 50 4b 8c c6 72 8c 86 06 8c 08 70 41 f9 46
43 03 46 04 38 20 fd 08 8e 12 20 31 c1 07 e2 0d
14 24 40 63 82 0f c4 1a 28 48 80 c7 04 1f 8d 25
34 ba b5 24 b2 4d 3e 68 40 5c f3 45 62 f1 51 9f
19 ff fd 1a 9a 5d 78 af 8c fc 29 fc 31 ff ff ff
c3 30 00 58 68 4a e3 0c ce 34 91 c2 c5 04 b8 cc
67 28 c8 60 68 c0 87 04 1f 94 64 30 34 60 43 82
0f d0 88 e1 22 03 1c 10 7e 20 d1 42 44 06 38 20
fc 41 a2 84 88 0c 70 41 f8 d2 53 4b ab 52 4b 24
d3 e6 84 05 cf 34 56 2f 15 19 f1 9f ff d1 a9 a5
d7 8a f8 cf c2 9f c3 1f ff ff fc 33


- -- 
Thanks,
Mike.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDC/CEACgkQcKEZN6rQR7EPBgCfYV7FhuWL0r606Q89lvEJ9iRB
ZS4AnjWltE74H4WZYCfYdpWb0ewL2fJy
=LXiJ
-----END PGP SIGNATURE-----


More information about the Matroska-devel mailing list