Re: [Cellar] On the multiplicity of Info elements

[Michael Niedermayer <[e-mail]>]

On Mon, Jan 11, 2016 at 10:46:33AM +0100, Steve Lhomme wrote:
> 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.

i agree

the possibility of such "forensic" techniques should be considered
in the design of the spec though at places where it might be usefull
iam not sure CRCs are the only such place ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle