Re: [media] Moving forward with captions / subtitles

On Sat, 20 Feb 2010 23:10:21 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Sat, Feb 20, 2010 at 7:45 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Fri, 19 Feb 2010 16:39:09 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> 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...
>>
>> I'm not thrilled about having to come up with a name for each group. The
>> multi-language subtitle case becomes quite ugly:
>>
>> <video>
>>  <track group="bla" ...>
>>  <track group="bla" ...>
>> </video>
>>
>> Where "bla" is any string and means nothing.
>
> Yeah, but they will have role="caption" and languages. And with "blah"
> being "Captions", it can be used in the menu as the title for the
> group.

I agree with this part, we should have an attribute that gives the title  
for menu items which override something the browser may derive from role  
or language. title="" or name="" perhaps? I think we should have this on  
both <trackgroup> and <track>.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 22 February 2010 04:14:13 UTC