Re: [Cellar] On the multiplicity of Info elements

[Steve Lhomme <[e-mail]>]

2016-01-05 17:49 GMT+01:00 Michael Niedermayer <[e-mail]>:
> On Tue, Jan 05, 2016 at 09:20:00AM +0100, Steve Lhomme wrote:
>> 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.
>
> i dont disagree but i think "no way" is not correct
> its possible that external means like errors from reading data could
> be used to detect which repeated versions are bad, also parsing errors
> could indicate what is bad and then if there are 3 or more copies
> simple majority "voting" on a byte per byte base could be used
> to construct a "good" version, this too could be done when all copies
> fail CRC checks. No idea if that would be usefull in any actual real
> world usecase, but a player or repair tool trying to be exceptionally
> resillient to damages could do things like that

True, some "forensic" could be applied to recover the damaged data
when all CRC fails. I don't think the specs should specify such
recovery techniques, nor a general reader should care too much about
that. The first level of CRC (find one that matches) should be good
enough for that level.

> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.



-- 
Steve Lhomme
Matroska association Chairman