RE: Proposal from HbbTV

>From: Silvia Pfeiffer [silviapfeiffer1@gmail.com]
>Sent: 12 October 2014 13:15
>To: Jon Piesing
>Cc: public-inbandtracks@w3.org; Nigel Megitt; Alexander Adolf
>Subject: RE: Proposal from HbbTV
>

>That would actually be another good reason to expose it as a video track right now, because that's >transparent to the js dev and won't confuse the situation later.


I'm sorry but I really don't understand that.

Consider our two scenarios;

Scenario A: UA rendered subtitles/captions are exposed as TextTrack objects regardless of whether there are Cue classes or not.
Now: HTML can discover the presence of subtitles/captions from the list of TextTracks. It can choose a subtitle/caption stream using the methods on the TextTrack class.
Possible Future: Same as now but additionally HTML that is interested in the Cues and their data can register for events and get told about them.

Scenario B: UA rendered subtitles/captions are exposed as additional VideoTrack objects when there are no Cue classes and as TextTrack objects when there are Cue classes
Now: HTML discovers the presence of subtitles/captions from the list of VideoTracks and can choose which to present using the methods on the VideoTrack class
Possible Future: HTML has to look both at the list of VideoTracks (on UAs where no Cues are available) and at the list of TextTracks (on UAs where Cues are available). HTML that forgets to look at the list of TextTracks (or hasn't been updated) will fail to notice the presence of subtitles/captions.

Scenario A looks a lot cleaner to me, is more likely to ensure that captions/subtitles are offered to users and is a lot less confusing to developers.

Jon



Best Regards,
Silvia.

On 12 Oct 2014 21:37, "Jon Piesing" <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>> wrote:
Sylvia,

I have one new reason why exposing DVB subtitles, teletext subtitles, (etc) as TextTracks may be better than creating synthetic VideoTracks representing video with burnt in subtitles.

Future scalability (or backwards compatibility if you prefer).

If someone had a good enough reason to define a DVBSubtitleCue class in the future. if the DVB subtitle tracks were exposed as TextTracks today, HTML written to work with today's spec could also work with that future spec without needing to do anything special.

I'm not sure that there would be enough interest to define a DVBSubtitleCue class but there could easily be enough interest to define a TTMLCue.

Jon
________________________________________
From: Silvia Pfeiffer [silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>]
Sent: 12 October 2014 12:06
To: Alexander Adolf
Cc: Nigel Megitt; W3C Inband Tracks Reflector; Jon Piesing
Subject: Re: Proposal from HbbTV

On Sun, Oct 12, 2014 at 5:39 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote:
> On Mon, Oct 6, 2014 at 9:22 PM, Alexander Adolf
> <alexander.adolf@condition-alpha.com<mailto:alexander.adolf@condition-alpha.com>> wrote:
>>
>> On 2014-09-30, at 12:48 , Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote:
>>
>>>> [...]
>>>> I mean 'in the text track cue list', if not in a different subclass of
>>>> TextTrack that offers some other data structure. I wouldn't assume that UA
>>>> rendering can only result in pixels being drawn in the video viewport: for
>>>> example there could be connections to other display or rendering devices.
>>>
>>> Since text tracks are part of the video element, text track data's
>>> rendering is restricted to the video viewport's dimensions.
>>
>> What about for instance rendering TTML - or any other text-based format - subtitles on a Braille "display"? Or by a text-to-speech system (often dubbed "screen reader")?
>
>
> These require no part of the browser window to be rendered, so are
> essentially also still within the "video viewport".
>
>
>>> If you want them rendered elsewhere, you need to extend the HTML
>>> specification for that. The only other way to do it is with JavaScript
>>> and for that you need to expose the content of the text track cues.
>>> [...]
>>
>> An accessibility-aware consumer electronics device would typically perform selection and rendering automatically based on the user's preferences. So at least for the CE use cases, the involvement of the UA and the document could be as minimal as being informed which tracks are selected and playing (or will be playing when the user hits "play").
>
>
> In this case, regarding the caption tracks as burnt-in tracks works fine.
>
>
>> Of course you are looking at it from a slightly different angle.
>
>
> The relevant angle here is the Web, since we're in the W3C. When you
> use a Web browser or a Web browser's rendering engine to render video,
> you have to ascertain that it still fits within the limitations of the
> Web platform and its technologies. That's all really.
>
>
>> Also - as you pointed out - some things might of course need to be proposed in other W3C groups to fully embrace the CE use cases.
>
> I'll start the discussion thread around the HTML specification to get
> some opinions from others.

I started the discussion here:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0145.html
.

If we don't get much of a reaction there, we'll try the HTML WG (which
is a bit busy with REC right now, so I asked on the WHATWG first).

Regards,
Silvia.