- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Thu, 14 Nov 2013 03:19:27 +0100
- To: public-inbandtracks@w3.org
Le 13/11/2013 17:15, Brendan Long a écrit : > > > - what is the use case we are trying to address by exposing these > info via the track ID attribute? Is the only think we care is to > have something that unique locally to the application (in that > case it may not matter much if the PID changes along the broadcast > value chain as far as each track as a unique PID at the end) or > are we trying to convey some other type of information? > > > One case is the media fragments, where it would probably be useful if > the ids were controllable (like Matroska TrackUIDs and Ogg Skeleton > Names are), or at least stay the same after transcoding. I assume that > would make authoring easier. > > The other is finding metadata, where it probably doesn't matter if the > ids change, just that they are consistent within a single file. Right, if a track describes/complements/is dependent on another track, this is usually done using track id and track id references, we want to preserve that in the Track interfaces. The easiest way to preserve that information is not to change the id values and just reuse them. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Received on Thursday, 14 November 2013 02:20:08 UTC