Re: [Cellar] On the multiplicity of Info elements

2015-12-30 10:18 GMT+01:00 Moritz Bunkus <moritz@bunkus.org>:
> 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.

> 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.
>
>> 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
>
> Kind regards,
> mosu
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman