- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Fri, 8 Nov 2013 21:12:37 +0000
- To: Brendan Long <B.Long@cablelabs.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
On 11/8/13 1:38 PM, "Brendan Long" <B.Long@cablelabs.com> wrote: >> >- To identify the type of the track data, I don't think we should rely >> >on the label. >> >> [2] uses the label for two different purposes. For 'track description' >> metadata text tracks, the label identifies the MIME of the media >>resource >> and that this metadata track holds the other track metadata. The MIME is >> needed for JS to know how to parse the metadata Cues. For other tracks, >> the label contains the stream ID of the the in-band stream that the >>track >> represents. Someone has suggested that track.id could be used for this >> purpose. > >I don't think we should use the label this way, since it's meant to be >displayed to users, and showing users technical information like codecs >and PIDs isn't user-friendly. Agree, but we need alternate solutions. > It seems like "id" is already fine for exposing the PID / TrackUID / >whatever, Track.id would seem to work for containing that track's in-band ID >but we may need a new attribute to expose the MIME type. Yes, perhaps an attribute on the htmlMediaElement > Is this not what the metadata dispatch type attribute is for? No. The inBandTrackMetadataDispatchType contains an encoding of the metadata describing what's in a metadata text track. It contains no MIME info and it only applies to in-band metadata text tracks. As noted in an earlier response to Cyril, replacing the inBandDispatchType attribute with a 'metadata' attribute, that exists on all video, audio and text tracks, removes the need for a text track containing the media resource metadata.
Received on Friday, 8 November 2013 21:13:06 UTC