Re: [whatwg] How to expose caption tracks without TextTrackCues

On Sun, Oct 12, 2014 at 11:45 AM, Silvia Pfeiffer
<silviapfeiffer1@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

Received on Wednesday, 22 October 2014 15:02:00 UTC