This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification proposes to define the track order for created tracks. There is no rationale for that and in some cases it does not make sense. What is the benefit of it. In typical DASH or MP4 processing, track order is meaningless. For example for DASH: there is no guarantee that an MPD is not rewritten somewhere in the network, so relying on the order of tracks is error-prone. Similarly, in the MP4 case, tracks may be added by tools without breaking the file playback.
We need a track order in HTML. E.g. retrieving videoTracks[3] should always retrieve the same video track from a media file. How do you suggest to do that?
Applications should rely on track ids, not on track order. You shouldn't use videoTracks[3].
Sure, but not all tracks have an id.
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.
(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. In any case, what is the alternative? Create the tracks in a random order? Would this benefit the application? This part of the spec is not a suggestion that the application should rely on track order. It is a response to the HTML spec statement "Tracks in AudioTrackList and VideoTrackList objects must be consistently ordered. 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." Applications can use the track.id attribute if it is set.
(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.
Proposed Pull Request: https://github.com/w3c/HTMLSourcingInbandTracks/pull/31
(In reply to Cyril Concolato from comment #7) > Proposed Pull Request: > https://github.com/w3c/HTMLSourcingInbandTracks/pull/31 PR accepted.