[Matroska-devel] MVC codec in Matroska container

Peter Wimmer (Lists) peter.wimmer.lists at 3dtv.at
Sat Dec 8 12:32:54 CET 2012


Hi,

I'm fine with any proposal where the subset SPS is easily available in the headers.

What do the Matroska experts think about the two proposals?

Peter



--------------------
3dtv.at
Peter Wimmer
Wankmüllerhofstr. 9
4020 Linz
Austria
 
office at 3dtv.at
http://www.3dtv.at  



-----Original Message-----
From: matroska-devel-bounces at lists.matroska.org [mailto:matroska-devel-bounces at lists.matroska.org] On Behalf Of Mike Chen
Sent: Saturday, December 8, 2012 9:37 AM
To: Matroska-devel at lists.matroska.org
Cc: Peter Wimmer
Subject: [Matroska-devel] MVC codec in Matroska container

-----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



More information about the Matroska-devel mailing list