Re: [Cellar] On the multiplicity of Info elements

[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

[...]

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