Re: Proposal from HbbTV

+1 to specifying the combinations-that-make-sense between different track
types including video, audio and text.

I don't have a proposal for the best structure for this, but it seems that
one could make a case for keying it on either video or audio tracks:
captions and subtitles tend to be related to audio tracks whereas other
kinds of metadata text tracks are likely to be related to video tracks.




On 30/09/2014 04:33, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>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 10:18:11 UTC