[Bug 26921] [InbandTracks] DASH trackId

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

--- Comment #2 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(In reply to Bob Lund from comment #1)
> (In reply to Cyril Concolato from comment #0)
> > "Content of the 'id' attribute in the AdaptationSet or ContentComponent
> > element. Empty string if 'id' attribute is not present."
> > 
> > The AdaptationSet@id is not unique within an MPD, but within a Period. The
> > Period@id is unique within an MPD, even after MPD updates. Similarly, the
> > ContentComponent@id is unique only within the AdaptationSet. Additionally,
> > it is not clear how representations are exposed.
> 
> HTML audio, video and text tracks should correspond to DASH AdaptationSet or
> ContentComponent. Different Representations within an AdaptionSet aren't
> different HTML tracks.
Why not? In GPAC we expose all representations in our UI, for instance to
select a representation when Adaptive Bitrate Switching is off. 

> The DASH spec also requires (section 5.3.3.1) that all Representations in an
> AdaptationSet have the same values for attributes that are used to set HTML
> track @kind, @language and @label.
Not exactly. We define how the @kind, @language and @label are generated from
the MPD. We could decide to add the bandwidth value in the label in that case,
or in a separate attribute.

> > I'd suggest using the triplets (Period@id, AdaptationSet@id,
> > Representation@id (or ContentComponent@id) to generate an id for the track.
> > It may be useful to use the MPD fragment identifiers for that but I'm not
> > sure we can address representations or sub-representations properly.
> 
> Seems like (Period@id, AdaptationSet@id [, ContentComponent@id]).
In a first or minimal approach, yes. I agree.

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

Received on Wednesday, 8 October 2014 19:26:33 UTC