Re: Proposal from HbbTV

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.

Cheers,

  --alexander

Received on Wednesday, 24 September 2014 20:56:30 UTC