Re: Proposal from HbbTV

On Tue, Sep 30, 2014 at 1: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.

A browser has to expose all the tracks and all the combinations possible.
Exposing the combinations in the @videotracks video attribute is no
better or no worse than exposing a single video track and a single
text track.

In fact, we haven't talked anywhere yet about how such a list of
available combinations is created. This is an independent issue to
that of whether we treat caption tracks without exposed cues, but with
rendered cues as burnt-in captions.

For example, some text tracks in a @texttracks video attribute may not
apply to all video or audio tracks.
A "descriptions" text track, for example, may contain the video
descriptions for a particular video track, but not for other video
tracks.
A "captions" text track, for example, may contain the captions for a
particular audio track, but not for all audio tracks (e.g. when a
director's comment audio track is activated, it would need a different
captions track).

I'd want to have this discussion on the public-html or WHATWG mailing
list and not here, because it needs to be resolved for the HTML spec.

I actually think that explicitly listing a possible combination in the
@videotracks video attribute is actually easier to deal with than
trying to define what text tracks can go with with audio or video
tracks.

Regards,
Silvia.

Received on Tuesday, 30 September 2014 03:34:37 UTC