Re: Proposal from HbbTV

On 25 Sep 2014 06:56, "Alexander Adolf" <alexander.adolf@condition-alpha.com>
wrote:
>
> Dear Silvia,
>
> On 2014-09-24, at 22:32 , Jon Piesing <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.