Re: Proposal from HbbTV

> Motte to the point though: a text track with 0 reported cues is indistinguishable from a text track where all cues failed parsing. This it's not obvious whether that will be a usable track or not. It's therefore not really a text track, but something special that the platform hasn't considered yet.

Is that exactly correct? Let's look at the mode of the text track and it's readiness state:

According to http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-mode:


"Disabled

Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues."

And at http://dev.w3.org/html5/spec-preview/media-elements.html#text-track :

"The text tracks<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track> of a media element<http://dev.w3.org/html5/spec-preview/media-elements.html#media-element> are ready if all the text tracks<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track> whose mode<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-mode> was not in the disabled<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-disabled> state when the element's resource selection algorithm<http://dev.w3.org/html5/spec-preview/media-elements.html#concept-media-load-algorithm> last started now have a text track readiness state<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-readiness-state> of loaded<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-loaded> or failed to load<http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-failed-to-load>."

And at http://dev.w3.org/html5/spec-preview/media-elements.html#text-track-failed-to-load :

"Failed to load

Indicates that the text track was enabled, but when the user agent attempted to obtain it, this failed in some way (e.g. URL<http://dev.w3.org/html5/spec-preview/urls.html#url> could not be resolved<http://dev.w3.org/html5/spec-preview/urls.html#resolve-a-url>, network error, unknown text track format). Some or all of the cues are likely missing and will not be obtained."

Taken together these suggest to me that it's legitimate to create a text track and set it deliberately to mode="disabled" without loading cues, or to set it to, say, "showing" and proceed as though it is "ready" even though its readiness state is "failed to load", specifically in this case because the text track format is unknown. That at least provides a mechanism to control a media object that can dereference the text track object into something concrete in the media that it can present, which is what's needed here.


> It's likely better exposed add a video track with burnt-in captions. I'd recommend that's how it would be shown in the track list. When activated, both the default video track and the captions track would then be rendered.

This pushes the interface complexity somewhere else, but not somewhere helpful! I'd argue that the spec should get as close as possible to matching the media element model and using text tracks for this purpose is better than not doing so.


By the way, I agree that exposing data provides interesting opportunities for developers, where possible. At least creating the text tracks provides the location for where such data might go, in case an implementation wants to put it somewhere; hiding the tracks away behind a 'burnt in video' would effectively block that.

Nigel


From: Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>
Date: Wednesday, 24 September 2014 23:23
To: Alexander Adolf <alexander.adolf@condition-alpha.com<mailto:alexander.adolf@condition-alpha.com>>
Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>, Jon Piesing <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>>, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Subject: Re: Proposal from HbbTV


On 25 Sep 2014 06:56, "Alexander Adolf" <alexander.adolf@condition-alpha.com<mailto:alexander.adolf@condition-alpha.com>> wrote:
>
> Dear Silvia,
>
> On 2014-09-24, at 22:32 , Jon Piesing <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>> wrote:
>
> >> If a text track never exposes any cues, we shouldn't expose its existence to browsers. That's like saying: hey, I have some data, but I won't give it to you. Or if we apply that logic to an audio or video stream: it's like announcing that a video stream exists, but not rendering it. Such tracks are not relevant to this specification.
> >
> > What about text tracks that are rendered by the (native) media player and where HTML would like to be able to enable/disable them in the same way as video & audio?
> > [...]
>
> Our (though unstated) assumption is that a browser in a TV set (which is what we are targeting) will be able to render subtitles and captions tracks. Hence, the following would display the video with some flavour subtitles:
>
> <video>
>   <source src=’http://mycdn.de/video.mp4’ type=’video/mp4’>
>   <track kind=’subtitles’ srclang=’de’ label=’German for the English’
>    src=’http://mycdn.de/subtitles_de.ttml’ />
>   <track kind=’subtitles’ srclang=’de’ label=’German for the hard of hearing’
>    src=’http://mycdn.de/subtitles_de2.ttml’ />
>   <track kind=’captions’ srclang=’en’
>    src=’http://mycdn.de/subtitles_hearing_impaired.ttml’ />
> </video>
>
> At the JS level, selecting the track would have the side effect of the platform rendering it; just like for video and audio. In the above example, the script's choice of text track would likely be based on the user's impairment type and language preferences.
>
> In such an environment, we thought that selecting/unselecting a text track would be sufficient, and couldn't think of anything interesting that could be done with a cue.

Developers will always find interesting things to do with data. Exposing it is always useful. For example, they might tender a interactive transcript alongside the video or do a translation or analyse the text and tender related content alongside it (think of Google ads, but also other content). So, there's always a use in exposing content.

Motte to the point though: a text track with 0 reported cues is indistinguishable from a text track where all cues failed parsing. This it's not obvious whether that will be a usable track or not. It's therefore not really a text track, but something special that the platform hasn't considered yet.

It's likely better exposed add a video track with burnt-in captions. I'd recommend that's how it would be shown in the track list. When activated, both the default video track and the captions track would then be rendered.

Silvia.