Re: Survey ready on Media Multitrack API proposal

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.

Cheers,
Silvia.

Received on Thursday, 11 March 2010 06:53:17 UTC