Hi all, In the Inband Text Tracks Community Group we've recently had a discussion about a proposal by HbbTV. I'd like to bring it up here to get some opinions on how to resolve the issue.
(The discussion thread is at http://lists.w3.org/Archives/Public/public-inbandtracks/2014Sep/0008.html , but let me summarize it here, because it's a bit spread out.) The proposed use case is as follows: * there are MPEG-2 files that have an audio, a video and several caption tracks * the caption tracks are not in WebVTT format but in formats that existing Digital TV receivers are already capable of decoding and displaying (e.g. CEA708, DVB-T, DVB-S, TTML) * there is no intention to standardize a TextTrackCue format for those other formats (statements are: there are too many formats to deal with, a set-top-box won't need access to cues) The request was to expose such caption tracks as textTracks: interface HTMLMediaElement : HTMLElement { ... readonly attribute TextTrackList textTracks; ... } Then, the TextTrack interface would list them as a kind="captions", but without any cues, since they're not exposed. This then allows turning the caption tracks on/off via JavaScript. However, for JavaScript it is indistinguishable from a text track that has no captions. So the suggestion was to introduce a new kind="UARendered". My suggestion was to instead treat such tracks as burnt-in video tracks (by combination with the main video track): interface HTMLMediaElement : HTMLElement { ... readonly attribute VideoTrackList videoTracks; ... } Using the VideoTrack interface it would list them as a kind="captions" and would thus also be able to be activated by JavaScript. The downside would that if you have N video tracks and m caption tracks in the media file, you'd have to expose NxM videoTracks in the interface. So, given this, should we introduce a kind="UARendered" or expose such tracks a videoTracks or is there another solution that we're overlooking? Silvia.
