[whatwg] Proposal for @label attribute associated with kind=metadata TimedTextTracks
Tab Atkins Jr.
jackalmage at gmail.com
Mon Mar 21 10:17:27 PDT 2011
On Fri, Mar 18, 2011 at 8:22 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Sat, Mar 19, 2011 at 6:29 AM, Eric Winkelman
> <E.Winkelman at cablelabs.com> 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.
>> 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.
>> 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
> 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>
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.
More information about the whatwg