On Monday, March 21, 2011 11:17 AM, Tab Atkins Jr. [mailto:[email protected]] wrote:
> >> Use Case: > >> > >> Many video streams contain in-band metadata for application signaling, > and other uses. By using this metadata, a web page can synchronize an > application with the delivered video, or provide other synchronized services. > >> > >> An example of this type of metadata is EISS ( > http://www.cablelabs.com/specifications/OC-SP-ETV-AM1.0-I06-110128.pdf > ) which is used to control applications that are synchronized with a > television > broadcast. > >> > >> In general, a media stream can be expected to carry several types of > metadata and the types of metadata may vary in time. > >> > >> Problem: > >> > >> For in-band metadata tracks, there is neither a standard way to represent > the type of metadata in the HTMLTrackElement interface nor is there a > standard way to represent multiple different types of metadata tracks. > >> > >> Proposal: > >> > >> For TimedTextTracks with kind=metadata the @label attribute should > contain a MIME type for the metadata and that a track only contain Cues > created from metadata of that MIME type. > >> > >> This implies that streams with multiple types of metadata require the > creation of multiple metadata track objects, one for each MIME type. > > > > > > I don't understand. Are you saying that right now all tracks that are > > of kind=metadata are made available through a single TextTrack? Cause > > I don't think that's the case. > > > > Or are you worried about text track files that contain more than one > > type of metadata? If the latter, then how is the browser to know how > > to separate out the individual cues from a single track into > > multipled? > > > > Can you clarify? > > I'm also somewhat confused. The OP mentions in-band metadata, but then > proposes adding something to out-of-band <track kind=metadata> > elements. I'm not proposing adding anything to out-of-band <track kind=metadata> elements. In-band metadata tracks are added to the DOM by the media player, and have the same @label attribute that out-of-band tracks do. I'm suggesting a use for that @label attribute that solves a problem I've encounter using metadata tracks. > I'm not familiar enough with in-band metadata tracks to know if it would be > useful to expose additional information about them, but for out-of-band > tracks I suspect that any information you may need is application-specific, > and thus can be served with a data-* attribute. I agree, there are a number of solutions for out-of-band metadata tracks, but my concern is specifically in-band metadata tracks. If an in-band kind=metadata track appears, what kind of information does it contain? Can you tell by looking at the DOM? Can you tell by looking at the cue's text? Eric
