[Matroska-devel] MVC codec in Matroska container

Steve Lhomme slhomme at matroska.org
Sat Dec 8 15:25:20 CET 2012


I think it's risky to keep the same codec with different versions of
the CodecPrivate. On the other hand, files with newer versions will
just fail to play in old players that can't handle it in the first
place. Are these players supposed to be able to decode the MVC stream
without the added extra feature ? If this is the case, the risk of
having incompatible files that would actually play is too high in my
opinion. Only an extra element seem to be good in this case.

Does the current AVC codec private include size boundaries ? If so it
could be extended. Otherwise we either have to go with a new element
of a new codec ID (which will also break backward compatibility).

On Sat, Dec 8, 2012 at 9:36 AM, Mike Chen <mike at makemkv.com> wrote:
> -----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-----
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman


More information about the Matroska-devel mailing list