Re: [Cellar] On the multiplicity of Info elements

[Steve Lhomme <[e-mail]>]

2016-01-03 16:53 GMT+01:00 Dave Rice <[e-mail]>:
>
>> On Jan 2, 2016, at 3:47 AM, Steve Lhomme <[e-mail]> wrote:
>>
>> 2015-12-30 10:18 GMT+01:00 Moritz Bunkus <[e-mail]>:
>>> Hey,
>>>
>>> I only remember the discussion around Tracks being multiple, not
>>> particularly for the other ones. Our intent way back when was to allow
>>> muxers to write multiple instances of _the same information_ in
>>> different places in order to make the file more resilient against
>>> damage or incomplete downloads with protocols like BitTorrent.
>>
>> Yes, that's the idea for the Track Info as it's vital to the usability
>> of the file, as well as the Segment Info. I'm not sure it's used in
>> practice though.
>> Since the goal of CELLAR is archiving solutions it may still make sense.
>
> Perhaps to declare that an Element may be repeated but must be repeated identically should be a new EBML Element Attributes, so there can be a distinction between the repeatability Segment/Info and the repeatability of SimpleBlock.

That might be good. After all not elements make sense as repeated
ones. For example in Matroska you don't want a Cluster (timestamped
data) to be repeated.

>>> The same reasoning could be applied to Info. Both elements are
>>> absolutely crucial to playback; the other level 1 elements safe for the
>>> clusters simply aren’t.
>
> But what should happen when the read finds differences in repeated-but-should-be-identical elements?

Good question. Maybe repeated elements should have a CRC ? If a CRC is
wrong (or not found) the parser could look for a copy.

> For a scenario of two differing Info Elements, VLC and FFmpeg use different Info Elements. Which use is correct? Since the use of repeated-identical elements is resilience a deviation between the two could be expected, so we should suggest how the reader should respond.

It was designed for recovery tools. It may not be good to change
players for such cases. It would make them more complex. (unless an
elegant/easy solution is found).

>>>> SeekHead, Info, Cluster, Tracks, and Tags are multiple.
>>>
>>> SeekHead and Cluster must be multiple. SeekHead in order to allow moving
>>> a SeekHead to the end of the file while still referencing it from the
>>> start (so that normal players will still find it quickly). Cluster for
>>> obvious reasons.
>>>
>>>> And Cues, Attachments, and Chapters are non-multiple.
>>>
>>> I have no idea why Tags is multiple and these three aren't.
>>>
>>> To me the following would make sense:
>>>
>>> - Info, Tracks – multiple but only if each instance contains the same
>>>  information
>>>
>>> - SeekHead, Cluster – multiple without restrictions
>>>
>>> - Attachments, Chapters, Cues, Tags – single
>
> I can understand Attachments and Tags being multiple as it could allow attachments or tags to be added to a file without having to re-write too many bytes.

Yes. But then there should be a way for the player to know about these
beforehand. Good players scan Matroska files beforehand anyway (unless
it's live streaming).

-- 
Steve Lhomme
Matroska association Chairman