[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 #19 from Bob Lund <b.lund@cablelabs.com> 2011-09-26 23:13:56 UTC ---
(In reply to comment #18)
> (In reply to comment #13)
> > CableTVCorp (O) creates an electronic program guide with a page depicted as a
> > grid of videos V1...V4 provided by 3rd party content providers P1...P4.
> >
> > V1...V4, in turn, contain or refer to timed track metadata content (e.g., video
> > descriptions, etc), which UA (upon decoding V1...V4) expose to O's JS client
> > code via TextTrackCue.getCueAsSource().
> >
> > O does not (generally cannot) a priori
> > know the timed track metadata content type
> 
> Yes it can. P1...P4 would just tell O what they are. I don't understand the
> problem here. This is a well-established pattern on the Web. An aggregator site
> gets information from third parties and those parties tell the aggregator
> exactly what they are providing, so that the aggregator can make use of it.
> Sometimes the aggregator explicitly specifies the format (e.g. Google Maps'
> transit directions feature has a specified format that transit companies can
> use), sometimes it's the other way around (e.g. Yahoo! Finance pulls
> information in from a number of different sources each of which might use its
> own format). Either way, though, the aggregator knows what the format of the
> data is.

This could work if markup is used to reference out-of-band <track> where kind =
metadata. This may also work if there is only one metadata track per program P.
However, if the user agent is sourcing in-band metadata tracks, which is the
case when cable content is re-purposed to the web, and a program P carries
multiple metadata tracks, e.g. content advisories + SCTE-35 ad insertion
messages, then even if aggregator O knows the type in the metadata tracks there
is no way for script on O's page to know which exposed in-band track is which.
Also, in the case of linear content where the referenced media resource is an
unending stream with changing metadata tracks then there is also the same
problem since the page from O might not be updated when there is a track
change.

-- 
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 Monday, 26 September 2011 23:14:02 UTC