[Bug 13359] A way is needed to identify the type of data in a track element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

--- Comment #22 from Bob Lund <b.lund@cablelabs.com> 2011-11-03 21:55:37 UTC ---
(In reply to comment #21)
> So the use case here is that there are in-band streams, e.g. TV, that have
> application-specific metadata, e.g. ad targeting keywords, game data, and the
> like, which are to be handled by specific modules on the client side as they
> arrive, basically "dispatching" each track to a separate blob of code that does
> not know ahead of time whether it will be needed or not.
> 
> We can't use "label" because some formats already provide a human-readable
> string even for metadata tracks (for debugging?).
> 
> Is there any particular reason there needs to be multiple metadata tracks for
> this, instead of the media stream having a single metadata stream that uses a
> convention of putting the "dispatch" type code in the first line of the cue, or
> something along those lines? (That would also avoid the problem of having to
> keep track of when these new tracks come along and enabling them.)

In the case of out-of-band tracks, multiple metadata text tracks would likely
be used. So, having this model for in-band tracks seems to make sense. Another
consideration is that an application might not be interested in all metadata
tracks. Having the in-band tracks mapped to separate metadata text tracks
allows this. Last, if the UA can determine the dispatch code then that's almost
the same as identifying the type of metadata.

Some containers newer than MPEG-2 TS provide a MIME type for each track. This
would be a natural fit with identifying the metadata track with a type.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 3 November 2011 21:55:50 UTC