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

On Tue, Oct 28, 2014 at 2:41 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sun, Oct 26, 2014 at 8:28 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> 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.
>
> Ah, right! Unless I'm misunderstanding again, your suggestion is to
> expose extra video tracks with kind captions or subtitles, requiring
> no spec change at all. That sounds good to me.


Yes, that was my suggestion for dealing with UA rendered tracks.

Cheers,
Silvia.

Received on Tuesday, 28 October 2014 01:43:51 UTC