Re: [media] Moving forward with captions / subtitles

On Fri, Feb 19, 2010 at 6:00 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, 19 Feb 2010 13:43:19 +0800, Eric Carlson <eric.carlson@apple.com>
> wrote:
>
>>
>> On Feb 17, 2010, at 9:49 PM, philipj@opera.com wrote:
>>
>>> On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson <eric.carlson@apple.com>
>>>>
>>>>
>>>>  Some questions and thoughts, in no particular order:
>>>>
>>>> +  I assume that if I use our track API to examine the track tracks in a
>>>> trackgroup, the one chosen from among a group of alternates is enabled, and
>>>> the others are not?
>>>
>>> What does enabled mean here? Since the MediaTracks API doesn't reflects
>>> the concept of groups, the mapping is open for debate. I think we should
>>> either reflect groups in some way, or we should simply expose all tracks
>>> in all groups (enabled or not) and setting .enabled=true on a track
>>> should
>>> implicitly disable the others in the same group.
>>>
>>  We should definitely expose all tracks, whether or not they are in a
>> group. We could expose group, but what could a script do with it?
>
> It would be good if a script can tell if enabling a track will disable
> others, so that it doesn't walk through the list and try to enable all
> tracks and is then surprised by the results. There is a workaround for
> <trackgroup><track> (look at the DOM tree), but what about embedded tracks?
>
>>>> + Do we enable the first track in a group if none match?
>>>
>>> I don't think so, but we haven't discussed the track selection algorithm
>>> much at all. I suppose it should first find the the first track with the
>>> enabled="" attribute in each group and enable that. But do we also want
>>> an
>>> enabled attribute on the group itself that performs selection based on
>>> media type, language, role etc?
>>>
>> The whole point of <trackgroup> is to mark some number of tracks that are
>> alternates of one another, so the *user agent* can choose which one is most
>> appropriate to enable based on conditions on the user's machine (user
>> preferences, machine characteristics, etc). If we are just going to allow
>> the user to specify which one is enabled, why bother with the grouping at
>> all?
>
> It would be useful even without a track selection algorithm as it would
> allow the UA and scripts to create appropriate menus and the UA can
> guarantee that at most 1 track in the same group is enabled.
>
> Still, I agree that we should have a track selection algorithm that takes at
> least media into account like for <source> resource selection. I'll note
> that I'm less than optimistic about automatic language selection being
> useful, because UA language is too often set to something inappropriate.

I'm thinking out loud here.

Instead of doing a <trackgroup> element, we could also introduce an
extra attribute that groups tracks together in a group. Similar to how
radiobuttons are grouped together by name (e.g.
http://www.felgall.com/javatip2.htm). Then we lose the beauty of
avoiding replicating attribute values, but so be it. Everything in a
group inside a media resource would then also share the same value for
that, then the javascript could address a group by that
attribute/javascript API. Maybe...

Silvia.

Received on Friday, 19 February 2010 08:40:02 UTC