[Matroska-devel] MVC codec in Matroska container

Moritz Bunkus moritz at bunkus.org
Fri Dec 14 11:02:49 CET 2012


Hey,

I've thought some more about this issue:

> bit(6) reserved = ‘111111’b;
> unsigned int(2) chroma_format;
> bit(5) reserved = ‘11111’b;
> unsigned int(3) bit_depth_luma_minus8;
> bit(5) reserved = ‘11111’b;
> unsigned int(3) bit_depth_chroma_minus8;

being located at the end of the avcC in MP4 and therefore it MIGHT be
located at the end of the avcC in Matroska files, too. In order to
parse our proposed extension reliably I suggest we don't just start
with the length of our first extension atom. Instead we insert a
well-known four-byte identifier exactly once at the end of the avcC
after which we continue with our previous proposal.

I'm not well versed with the usual syntax used in such standards, but
something like this:

CodecPrivate := avcC chromaInf? [separator [length type content]+]?

Meaning:

- avcC: same as current CodecPrivate
- chromaInf?: optional chroma information (3 bytes like shown at the
  top of this email)

If extensions exist:

- separator: four-byte string 'CPex' ("CodecPrivate extension")
- length: four-byte big-endian length identifier of "content" field
- type: four-byte string identifier for the type, e.g. 'avcC' or 'mvcC'
- content: the avcC or mvcC as discussed in previous emails

Meaning... the only difference to the previous proposal would be the
'CPex' identifier. The advantage is that no guesswork is required. A
parser looking for the extensions could simply look for this string at
the end of the avcC.

The other way is also safe: a parser not expecting the 'CPex'
extension but the chromaInf would see three bytes 0x43 50 65, in
binary: 01000011 01010000 01100101. Those do not match the reserved
'1' bites from the chromaInf field at all, meaning the parser would
have to consider them invalid.

Kind regards,
mosu


More information about the Matroska-devel mailing list