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

On Thu, Oct 23, 2014 at 2: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
>> 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.

The "captions" video track is one that has video and captions rendered
together, so you only need the one video track active. If you want to
turn off captions, you merely activate a different video track which
is one without captions.

There is no change to the model necessary - in fact, it fits perfectly
to what the spec is currently describing without any change.


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

As stated, the proposal was to introduce kind="UARendered" and that
would introduce a change to the spec.

Regards,
Silvia.

Received on Sunday, 26 October 2014 07:29:14 UTC