Re: Proposal from HbbTV

On Sun, Oct 12, 2014 at 11:45 PM, Jon Piesing <Jon.Piesing@tpvision.com> wrote:
>>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.

What is this "HTML" that discovers the presence of the list of TextTracks?

What it really is: the UA exposes the list of subtitles/captions in .textTracks.
The UA may expose these and all subtitles/captions that come from
video tracks and are available in .videoTracks in a menu for users to
chose.
If the UA doesn't do this, the JavaScript developer can.
Since the JavaScript developer is not aware of a difference between a
text track with no cues and a text track with automatically rendered
cues, he/she may remove tracks from .textTracks that have 0 cues.
Possible Future: with the UA now supporting a new TextTrackCue format
for a previously removed track, hopefully the JavaScript was coded
well enough to no longer ignore that track.


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

Again: you have to distinguish between the UA code and the JavaScript code.
The UA will expose .textTracks and .videoTracks with their kind values
just as well as each other - it's not "forgetting" either of them.

What it really is in your possible future: the UA will move from
supporting a pre-rendered "caption" track in a .videoTracks to
actually exposing it as a proper .textTrack with cues in the newly
defined and implemented TextTrackCue format. The JavaScript will just
see less "caption" tracks in .videoTracks and more in .textTracks.


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

Exactly the opposite, actually. UA developers will be confused about
how to fill TextTrack attributes for tracks that don't expose cues, so
the first one is both more confusing to UA developers as well as JS
developers.

Regards,
Silvia.

Received on Sunday, 12 October 2014 20:36:20 UTC