Re: [Cellar] On the multiplicity of Info elements

[Steve Lhomme <[e-mail]>]

2016-01-04 19:59 GMT+01:00 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.

Also what about repeated elements that are not master elements. You'd
have no way of telling which is the best version. So repeated should
probably be master elements. Maybe CRC should be mandatory too (not
sure if real life files already follow this rule). That's the only way
a parser would be able to tell which version is correct, as far as I
can see.

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

Not necessarily. Bogus data could be on the first one. The goal is not
to write a version of the element and then an updated version in the
file. It has to be the same data. If you want to clear the first
version, you should use the Void EBML element. When the file is
originally written, repeated values should be exactly the same. That
means elements that have a file offset relative to a child element
would not be equal. Luckily in Matroska offset positions are always
relative to the Segment, so a Level-0 element.

http://www.matroska.org/technical/specs/notes.html#Position_References

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

IMO what makes sense from a player point of view is to read an
element. If there's a CRC, it's broken and the semantic says the
element can be repeated, then it should look for a valid version.
Otherwise it shouldn't have to wonder which element to use if it
encounters another one. IMO repeated elements only make sense if
there's a CRC (whichever form it may take).

Another rule for repeatable elements: the element MUST be unique at
that level (not multiple).

>>>>>> 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
>
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman