[whatwg] Proposal for @label attribute associated with kind=metadata TimedTextTracks

[Tab Atkins Jr.]

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.
>>
>> 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 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.

~TJ