Re: Proposal from HbbTV

On Thu, Sep 25, 2014 at 6:56 AM, 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’ />

This should probably of kind="captions" if it's for hard-of-hearing users.

>   <track kind=’captions’ srclang=’en’
>    src=’http://mycdn.de/subtitles_hearing_impaired.ttml’ />
> </video>

Yes, that works, but is not strictly relevant to the discussion here,
because we are only talking about IN-BAND tracks on this mailing list
(i.e. tracks that are multiplexed into a audio and video stream).

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

Yes, that's ow it works.

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


TTML are text files and when UAs support the format in <track>, they
should expose TextTrackCue objects for the parsed cues (possibly in
the form of TTMLCue objects).

Exposing cues to JavaScript enables a Web developer to create all
sorts of interesting presentations around it, such as interactive
transcripts rendered next to the video.

The question should not be: should the cues be exposed. The question
should be: why would you *not* expose the cues? After all, in your
markup, they are already readable in the TTML file and the Web
developer could retrieve them via XHR, so they're not hidden anyway.

Regards,
Silvia.

Received on Sunday, 28 September 2014 20:53:03 UTC