Subject: Re: [Cellar] review of codec_specs.md for defining use of encodings in Matroska

From: Steve Lhomme <[email-masked]>
Date: Sun, 16 Oct 2016 16:05:00 +0200

2016-09-26 3:00 GMT+02:00 Tessa Fallon <[email-masked]>:
> Re: multiple documents, I am not 100% sure and defer to those with more
> experience at the IETF to indicate if there is precedent; if it is not part
> of the core spec, then it/they could be published as informational drafts.
> However, before that I would ask for group consensus to ensure that this
> fragmentation is absolutely necessary, and that the implications are fully
> outlined and understood.
>
> Also, I'd ask for it to be made clear why, if the items in question are not
> part of the core spec, they merit publication under the CELLAR charter, as
> we'd be adding two more documents to our already substantial list of
> documents to be published.

Why ? Because it needs to be (a) normative document(s) that are
necessary for interoperability. But it doesn't have any impact on how
Matroska data are handled. It's just a description of the payload.
These data are opaque to the Matroska level of parsing data. Also as
stated before the content may be updated more often than the Matroska
specifications. In the future new codecs will be defined with their
own RFC to describe the payload. Or they might be part of different
specifications. So there's no need to have some settled in the
Matroska specifications and some outside. IMO they all belong outside.

> Best
>
> Tessa
>
>
> On Sep 25, 2016 17:37, "Dave Rice" <[email-masked]> wrote:
>>
>>
>> > On Sep 25, 2016, at 3:07 PM, Jerome Martinez <[email-masked]>
>> > wrote:
>> >
>> > Le 25/09/2016 à 00:05, Dave Rice a écrit :
>> >> [...]
>> >>
>> >> The terms ‘private data’ and the `CodecPrivate Element` seems to be
>> >> referenced in the same way. Are these the same things? If so, they should be
>> >> made consistent.
>> >
>> > They are same thing, as described: "CodecPrivate element: Private data
>> > only known to the codec." but right, maybe we need to add more information
>> > about it.
>>
>> If CodecPrivate is referenced by nearly every definition of an encoding in
>> Matroska, perhaps we should split the ‘Description’ into ‘CodecPrivate
>> Usage’ and ‘Description’.
>>
>> >> The phrase "The private data is void.” is used several times in the
>> >> document. Does this mean that the `CodecPrivate Element` is stored but as an
>> >> `Empty Element`? Could the `CodecPrivate Element` just not be present if not
>> >> needed?
>> >
>> > Not present if not needed is the implemented way. Maybe rephrasing the
>> > sentence would make it more explicit (e.g. "no CodecPrivate Element"
>> > instead, for stream format not needing configuration bytes).
>> >
>> >> [...]
>> >>
>> >> Other questions:
>> >> Should the Matroska specification provide enough info for a user to
>> >> independently define support for an encoding in Matroska? Or should codec
>> >> support somehow be ‘registered’ via Matroska and/or CELLAR?
>> >
>> > First, the list of supported formats and their respective definition
>> > should be in a separate document (updated more often than the core spec).
>>
>> +1
>>
>> For the chairs, if we are splitting an intention of one document
>> (Matroska) into several documents (Matroska, Matroska Encoding Registry,
>> Matroska Metadata Registry) do we need to update the charter?
>>
>> > And yes, each new format should be registered, because there is an
>> > unique codec name namespace. Maybe defining "X_" prefix as private (but mime
>> > RFC now discourages use of "x-", so maybe not a good idea).
>>
>> +1
>>
>> > Now, the question is where to define CodecPrivate. e.g. for FFV1 we
>> > already defined it in the FFV1 spec but we can not update AVC specs for
>> > that.
>> >
>> >> [...]
>> >>
>> >> For a Matroska validation that finds something like V_MPEG4/ISO/AVC in
>> >> Matroska. Should it be considered as unsupported (most MKV files!)?
>> >
>> > Matroska-centric validation tools should not validate raw streams, that
>> > includes CodecPrivate part. This is the role of a more general validation
>> > tool (a tool described as "validation of Matroska files" would not validate
>> > the CodecPrivate part, a tool described as "validation of Matroska files +
>> > FFV1 and FLAC" would use the description of how FFV1 and FLAC are
>> > registered)
>>
>> There are still some tests permitted by only the Matroska specification.
>> For instance with a revision we could make it clear which Codec ID MUST or
>> MUST NOT have an associated `CodecPrivate Element`.
>>
>> Dave Rice
>> _______________________________________________
>> Cellar mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cellar
>
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman