Re: Survey ready on Media Multitrack API proposal

On Thu, 11 Mar 2010 14:52:21 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Thu, Mar 11, 2010 at 3:27 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Thu, 11 Mar 2010 12:08:35 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Thu, Mar 11, 2010 at 2:50 PM, Philip Jägenstedt <philipj@opera.com>
>>> wrote:
>>>>
>>>> On Thu, 11 Mar 2010 08:03:33 +0800, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>
>>>>> + add a DOMString attribute @groupID to the MediaTrack to expose the
>>>>> trackgroup
>>>>
>>>> What should groupID be for <trackgroup><track>?
>>>
>>> This is for the JavaScript API, not the <trackgroup><track>
>>> specification. It goes into the MediaTrack element:
>>>
>>> interface MediaTrack {
>>> ...
>>>  readonly attribute DOMString groupId;
>>> ...
>>> }
>>>
>>>> Groups, like tracks, don't
>>>> necessarily have a name or id.
>>>
>>> Not when there are no groups. When there is a group, in MPEG, there is
>>> an ID (and in Ogg there will be, too). As for the externally linked
>>> markup, you are right and we may need to introduce a mandatory groupID
>>> attribute on the <trackgroup>. OTOH, we could use the @id attribute,
>>> if only we could require its use.
>>
>> I'm not a fan of this approach, it just adds boilerplate to achieve the
>> basic use cases of multi-language subtitles:
>>
>> <video>
>>  <trackgroup groupid="any-unique-string">
>>    <track ...>
>>    <track ...>
>>  </trackgroup>
>> </video>
>>
>>>> If we want to go this way, it would be better to not use <trackgroup>  
>>>> at
>>>> all
>>>> and put a group attribute on <track>. I don't like either solution,  
>>>> but
>>>> would be happy to continue discussing it in the HTML WG.
>>>
>>> We don't need to change the markup for <trackgroup><track> only
>>> because the JavaScript API looks like this. But this is certainly an
>>> opportunity to harmonize the two further.
>>
>> What about replacing MediaTracks with MediaTrackGroup as per my other  
>> email?
>> This way at least we don't have to make up unique IDs where none are  
>> really
>> necessary (this includes MPEG where the group is an int and doesn't  
>> really
>> carry any interesting information).
>
> I simply think it is over-engineering. I'd prefer not to introduce
> that much complexity for something this simple.
>
>
>> Unless we can agree on something I would prefer if we simply don't  
>> solve it
>> and submit it to the HTML WG as is to get more input.
>
> It may indeed be necessary. I certainly wouldn't want to hold this up
> because of the grouping, since I think grouping is a nice feature, but
> not a main one.

I agree, but think that the "nice feature" is the possibility of having  
parallel text tracks, while having mutually exclusive tracks is absolutely  
fundamental. If we can't handle grouping in a nice way we can discard it  
and require scripts to achieve parallel text tracks. But let's finish this  
in the HTML WG.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 11 March 2010 08:38:30 UTC