Subject: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska

From: guest271314 <[email-masked]>
Date: Sun, 27 Dec 2020 07:33:36 -0800

Evidently CodecPrivate element being required/mandatory for H264 in
Matroska container is not clear nor conspicuous enough in the
standard/specification.

Cure that by conspicuously and unambiguously including wording in the
standard/specification that " CodecPrivate element MUST be set for H264 in
Matroska".

References:

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474111881

> Yes, both require & expect it to be present as there's important data
stored there. One could go and assume certain defaults, and that might
actually work for certain files, but not in general. This isn't a bug, nor
a missing feature.

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474135850

> Whether or not certain header elements (not just CodecPrivate) must be
set depends on the video codec. VP8 & VP9 don't require one, for example,
whereas AVC/h.264 & HEVC/h.265 do.

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474137735

> We don't use RFC-style verbiage everywhere yet. The terms "CodecPrivate
contains…" pretty much states that the element is required for decoding.

Issue 1161944: CodecPrivate element is required for H264 in Matroska -
Chrome MediaRecorder does not set the element
https://bugs.chromium.org/p/chromium/issues/detail?id=1161944

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 27 Dec 2020 17:15:44 +0100

On 27/12/2020 16:33, guest271314 wrote:
> standard/specification that " CodecPrivate element MUST be set for 
> H264 in Matroska".

CodecPrivate in Matroska general specification is not mandatory, as this 
status depends on the coding format (mandatory for H.264, not mandatory 
for MPEG-2 etc).

>From 
https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_specs.md#v_mpeg4isoavc
"The Private Data contains a AVCDecoderConfigurationRecord structure, [...]"
This is not the IETF "MUST" but seems clear (affirmative sentence) that 
CodecPrivate is mandatory in the case of the H.264 mapping.

Do you mean that we should be even more clear in 2 places?
- in CodecPrivate definition, something like CodecPrivate is mandatory 
if specified as such ("MUST") in the corresponding codec mapping 
specification.
- in H.264 codec mapping definition, something like The CodecPrivate 
block MUST contain a AVCDecoderConfigurationRecord structure [...]

Jérôme

---

From: Moritz Bunkus <[email-masked]>
Date: Sun, 27 Dec 2020 17:35:03 +0100

Hey,

while it's true that _from the EBML PoV_ the CodecPrivate element isn't
mandatory, it still must be present for certain codecs in order for them to
be decodable. So yes, their request is that we say something like: "for
Codec == V_ABC/DEF/GHI the CodecPrivate element MUST be present. It MUST
contain data according to ReferenceToSomeOtherStandard."

Not only that the content MUST contain data following certain format, but
also that the element MUST be present.

Kind regards,
mosu

---

From: guest271314 <[email-masked]>
Date: Sun, 27 Dec 2020 08:38:23 -0800

---------- Forwarded message ---------
From: guest271314 <[email-masked]>
Date: Sun, Dec 27, 2020 at 8:36 AM
Subject: Re: [Cellar] Update specification language: CodecPrivate element
MUST be set for H264 in Matroska
To: Jerome Martinez <[email-masked]>

Alternatively, if your conclusion is that the specification/standard is
clear right now, can you kindly inform the Chrome authors of the same, and
their omission of the element is non-compliant with the
specification/standard at
https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c_ts1609079978
so that there will be no quarter for confusion as to Chrome MediaRecorder
implementation being non-conformant with the sections that you cited.

Either way Chrome authors need to be aware of this issue from the canonical
source.

---

From: guest271314 <[email-masked]>
Date: Sun, 27 Dec 2020 08:47:16 -0800

---------- Forwarded message ---------
From: guest271314 <[email-masked]>
Date: Sun, Dec 27, 2020 at 8:31 AM
Subject: Re: [Cellar] Update specification language: CodecPrivate element

> block MUST contain a AVCDecoderConfigurationRecord structure [...]

Yes. That is what the request for updating the standard/specification
states. Evidently that information (wording; language) was not clear enough
for Chrome authors when they implemented H264 encoding in Matroska
container for MediaRecorder.

Since your organization is the authority in this matter it would be helpful
to inform the Chrome authors of their omission of the CodecPrivate element
- otherwise nothing will change and users in the field will still not be
able to extract H264 tracks from the resulting Matroska file that Chrome
MediaRecorder implementation produces when mimeType is set to
'video/x-matroska;codecs=h264' or 'video/x-matroska;codecs=avc1'.

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 27 Dec 2020 20:21:33 +0100

On 27/12/2020 17:38, guest271314 wrote:
>
> Alternatively, if your conclusion is that the specification/standard 
> is clear right now, can you kindly inform the Chrome authors of the 
> same, and their omission of the element is non-compliant with the 
> specification/standard [...]

I am pretty sure that this is clear for them as the files can not be 
decoded correctly, just that what Google uses is more VP8/VP9/AV1/Opus, 
and these coding formats don't need CodecPrivate.
And from 
https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c2, it 
looks like they don't wait for a change in the spec.
Anyway, better to be clear, I'll send a PR about that.

Jérôme

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 27 Dec 2020 23:27:49 +0100

> Matroska container is not clear nor conspicuous enough in the 

Proposal of changes: 
https://github.com/ietf-wg-cellar/matroska-specification/pull/446