Re: [Cellar] Adding private elements to Matroska

[Jerome Martinez <[e-mail]>]

On 13/04/2018 21:27, Michael Bradshaw wrote:
> I concur with Martin. For this particular case, I don't think new 
> elements should be introduced just for RAWcooked. RAWcooked, could 
> instead add an attachment or tag that contains its needed metadata.

Current implementation of RAWcooked uses an attachment, this method has 
some advantages, e.g. can survive over a remux if attachment are copied, 
but also some drawbacks, e.g. all is in a single place (maxOccurs for 
"Attachments" element is 1) which may be a problem in some corner cases 
(redundancy, need to keep in memory or elsewhere all RAWcooked data 
before being able to store the file at the end of the encoding...).
As Tags element has no maxOccurs, I could use it for storing data 
corresponding to e.g. the previous cluster (Tags is at Segment level 
only), with a TagName having a "magic value" specific to my project (as 
I do with attachments right now) and TagBinary containing the 
corresponding data, but it is usable only at the Segment level, so not 
generic way to define private content in other Matroska elements.


> In general, I'm opposed to private elements in Matroska.

Even if the outcome for RAWcooked is to avoid to create Matroska 
elements, other projects may decide that this is the only solution for 
them, and if we (as people working on Matroska spec) don't define a way 
to store private elements, people may do as DivX did (if I remember 
well, DivX first decided to create some new Matroska elements, then 
Matroska people put them in spec in order to avoid so get collision), 
which is maybe not the way we want it.

Most modern formats have private elements (MPEG-TS has 
registration_format_identifier in descriptors for knowing what is used 
for table_id>=0x80,  AVC/HEVC uses "user_data_unregistered" in user_data 
followed by uuid_iso_iec_11578 for uniqueness, MP4/MOV uses "uuid" atom 
also followed by an UUID...), even AV1 is planning 
METADATA_TYPE_PRIVATE_DATA metadata type for storing private data, I 
guess it is not for nothing ;-), so I think that planning nothing for 
people wanting to store unspecified content is a good method, if we plan 
that Matroska is even more used that currently, so any company would be 
interested in storing private content as they do for years when they use 
a format.


> (...)