Re: [Cellar] Matroska Elements to support frame side data

[Jerome Martinez <[e-mail]>]

On 05/11/2018 10:29, Moritz Bunkus wrote:
> Hey,
>
>> In other thoughts on this suggestion, I think it could make it difficult
>> to easily understand if a file has a particular type of side data. For
>> instance if only a few Clusters somewhere in the Segment contain a
>> certain type of side data, it would require parsing every Cluster to know
>> what types of side data are available. This uncertainly wouldn’t be the
>> same issue if the side data was itself a Track.
> It's not entirely necessary to use a full track for side data. We can simply
> signal the presence of side data in the track headers and refer to it from
> the side data in the block groups. This would also mean we only have to
> store the string identifying the side data type once (in the track headers)
> instead of in each block.


It would permit more efficient storage, but IMO it should be optional 
only, because if we do real time transcoding to MKV we don't have always 
all sidecar info. I have in mind some A/V content with ancillary data 
coming only after few minutes, without any change in A/V part.


>
> (I'll use "BlockMetadata" as the basis for all element names
> here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine
> with me, too.)

I prefer also "BlockMetadata" due to here is located the element.


>
> For example:
>
> Tracks
> +- TrackEntry
>   +- TrackBlockMetadata (Master)
>    +- TrackBlockMetadataType (String, required)
>    +- TrackBlockMetadataID (Unsigned Integer, required)

Please add:
  +- TrackBlockMetadataPrivate (Binary, optional)

Would have the same usage as CodecPrivate but for metadata.


>
> …
>
> Cluster
> +- BlockGroup
>   +- BlockMetadata (Master)
>    +- BlockMetadataID (Unsigned Integer, required, refers to existing
>       TrackBlockMetadataID in track headers)

Here I suggest to keep something like current PR "BlockMetadataName" and 
the restriction that  that exactly one of (BlockMetadataID ,
BlockMetadataName) must exist.

This would be even more complex but IMO more versatile.


> [...]