[Bug 26716] [InbandTracks] Track order

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26716

--- Comment #6 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(In reply to Bob Lund from comment #5)
> (In reply to Cyril Concolato from comment #4)
> > I was considering only container formats and so far MP4, MPEG-2 TS, WebM and
> > Ogg, all have an id for tracks. DASH AdaptationSets indeed may not always
> > have an id, but I don't think you want to rely on videoTracks[3] to be the
> > third AdaptationSet in the MPD because the MPD may have been filtered in the
> > network, or rewritten by an XML processor and there is no guarantee that the
> > order has been preserved.
> 
> What does "no guarantee that the order has been preserved" mean? The order
> is whatever is present in the MPD when the UA parses it. It is irrelevant
> what the MPD state was before the UA gets it. 
What I meant was that if a content producer creates both MPDs and JS to expose
the tracks from those MPDs, it shouldn't hard code in the JS that
videoTracks[3] is the 3rd Video AdaptationSet containing video in the original
MPD as the MPD might be changed by network entities (Note: such change by
network entities is discussed in many forums even if it is debatable). However,
you're right, when the MPD reaches the UA, the order will probably match.

> In any case, what is the
> alternative? Create the tracks in a random order? Would this benefit the
> application?
The alternative is not to say anything about the order. I don't see the added
value of saying that videoTracks[3] is the third AdaptationSet in the MPD that
contains video. 

> 
> This part of the spec is not a suggestion that the application should rely
> on track order. 
We should probably make it clearer and suggest that application use either
track ids or track characteristics (type, kind ...) to use tracks.

> It is a response to the HTML spec statement "Tracks in
> AudioTrackList and VideoTrackList objects must be consistently ordered.
I had not noticed that statement before. I'm not sure what "consistently" means
here. Consistently across what? I can understand that when addtrack or
removetrack events on those lists are triggered, you don't want the complete
order to change: a track has been inserted or one has been removed. So in the
mappings, that is only relevant to when there are multiple Periods in a MPD and
when you want maintain the track order. This is not trivial. We should probably
add a section to the spec defining how the mapping behaves in case of period
change.

> If the media resource is in a format that defines an order, then that order
> must be used; otherwise, the order must be the relative order in which the
> tracks are declared in the media resource. The order used is called the
> natural order of the list."
The notion of "natural order" seems to be used only to disambiguate which track
you get using getTrackById when two tracks have the same id. In our case, this
shouldn't be useful, except maybe when MPDs are invalid and have 2
AdaptationSets with the same id. So indeed, defining the order is useful. We
should document the rationale for that. I'll submit a patch.

> 
> Applications can use the track.id attribute if it is set.
We should encourage to use track.id and other track characteristics.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 26 September 2014 08:36:41 UTC