Re: Proposal from HbbTV

On 9/29/14, 9:27 AM, "Brendan Long" <B.Long@cablelabs.com> wrote:

>On 09/28/2014 04:11 PM, Silvia Pfeiffer wrote:
>>>> 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.
>>> This pushes the interface complexity somewhere else, but not somewhere
>>> helpful! I'd argue that the spec should get as close as possible to
>>>matching
>>> the media element model and using text tracks for this purpose is
>>>better
>>> than not doing so.
>> Why is it not helpful? From the JS and user's point of view, that's
>> exactly what such a track is: a video track with burnt in captions.
>> Since it's now exposed in the list of video tracks, it can be selected
>> and activated. That's all that's required for such a track. That's as
>> useful as it gets, isn't it?
>Wouldn't exposing captions as a video track + burned in captions create
>weird cases when you have multiple video tracks (multiple camera angles
>for example)? If the captions apply to all of the videos, then you'll
>have an explosion of video tracks instead of a simple list of video
>tracks and a simple list of captions to go with it.
>

The current HTML spec doesnıt support a cue-less text track very well so
treating it as a video track with burned-in text is an alternative. This
could result in a large number of these tracks for media resources with N
video tracks and M cue-less text tracks (N x M).

Another alternative is to enhance text track semantics to better
accommodate cue-less text tracks. One could define a new text track mode,
e.g. ³UARendered" defined as ³Indicates that the text track is active, the
user agent is actively displaying the data in the track but no cues are
active and no events are fired.²


The only legal modes for such a track would be ³disabled² or ³UARendered².

Received on Monday, 29 September 2014 15:54:09 UTC