W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

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

From: Bob Lund <B.Lund@CableLabs.com>
Date: Wed, 22 Oct 2014 15:33:44 +0000
To: Philip Jägenstedt <philipj@opera.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Message-ID: <D06D2996.47EBC%b.lund@cablelabs.com>
Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>

On 10/22/14, 9:01 AM, "Philip Jägenstedt" <philipj@opera.com> wrote:

>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
>> , 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?

This issue was clarified here [1]. TextTrack.mode would be set
³uarendered². TextTrack.kind would still reflect ³captions² or ³subtitles².


Received on Wednesday, 22 October 2014 15:35:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC