On Sun, Oct 26, 2014 at 8:28 AM, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
>
> On Thu, Oct 23, 2014 at 2:01 AM, Philip Jägenstedt <phil...@opera.com> wrote:
> > 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.
>
> 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.

Philip

Reply via email to