Re: [Cellar] On the multiplicity of Info elements

["Sebastian G. <bastik>" <[e-mail]>]

04.01.2016, 08:11 Steve Lhomme:
> 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.

I like the CRC idea for repeated elements, but it still does not define
how players should behave if they encounter two elements, even with
valid CRCs, not matching each other.

There would have to be a recommendation. "Use always the first
occurrence of an element." or "If an element occurs repeated and its
values differ, the last occurrence is the one that should be used."

Obviously tools that create such files are violating the specifications
since it should not be allowed to create repeated elements with
differing values. On the other hand should it be hard to break playback.
I prefer uniform behavior among players.

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

For differences due to transmission errors a CRC for repeated elements
seems a good solution.

Players have to do something with repeated elements. I don't know what
they do, but there should be a recommended way they should handle such
cases. If a player breaks, that is OK, as long as the file was violating
the specs. A player should behave in an expected way.

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

I agree with having a mechanism for players to know about them beforehand.

--
Sebastian