On Sun, Oct 12, 2014 at 11:45 AM, Silvia Pfeiffer <silviapfeiff...@gmail.com> wrote: > > 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?
VideoTrackList can have at most one video track selected at a time, so representing this as a VideoTrack would require some additional tweaking to the model. A separate text track kind seems better, but wouldn't it still be useful to distinguish between captions and subtitles even if the underlying data is unavailable? Philip
