Re: Proposal from HbbTV

On Thu, Sep 25, 2014 at 10:20 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>> 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 of a media element are ready if all the text tracks whose
> mode was not in the disabled state when the element's resource selection
> algorithm last started now have a text track readiness state of loaded or
> 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 could not be resolved,
> 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.

Thanks for walking through this. You are explaining my point very
well, but you need to keep reading. The HTML spec says:

"Whenever a text track's text track readiness state changes to either
loaded or failed to load, the user agent must remove it from any list
of pending text tracks that it is in."

Thus, a track that has 'failed to load' is one that is ignored by the
browser and cannot display any cues.

But that's not even what is going to happen for an in-band track where
the UA renders all the cues, but doesn't expose them as TextTrackCue
objects. Here's what happens there: the track will be 'disabled'.
Then, when it is selected, the UA will go into 'loaded' state once it
has parsed all the data and loaded into internal memory. It won't
reach 'failed to load' because the data was able to be obtained and
loaded with no fatal errors. However, since it doesn't expose cues,
the @cue TextTrackCueList in the TextTrack object of the video element
will have 0 cues. Thus, if the JavaScript developer checks on how many
cues are being rendered and at what times, they will see "0" and have
to assume that the browser has failed to parse any cues. The only
reasonable conclusion for the JS developer is to assume that the
loading of all cues failed and thus the track is not usable.



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

Why is it not helpful? From the JS and user's point of view, that's
exactly what such a track is: a video track with burnt in captions.
Since it's now exposed in the list of video tracks, it can be selected
and activated. That's all that's required for such a track. That's as
useful as it gets, isn't it?


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

What do you mean by "where such data might go"? If the UA renders the
data, it can only render it within the video viewport, so for all
intents and purposes, it is video data.

Regards,
Silvia.

Received on Sunday, 28 September 2014 21:10:48 UTC