Re: [Cellar] On the multiplicity of Info elements

[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.

>> 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?

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.

>>> 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.

Dave