Re: Survey ready on Media Multitrack API proposal

On Thu, Mar 4, 2010 at 4:08 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 04 Mar 2010 11:45:43 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Thu, Mar 4, 2010 at 2:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> On Mar 3, 2010, at 12:40 PM, Silvia Pfeiffer wrote:
>>>
>>>> On Thu, Mar 4, 2010 at 3:33 AM, Eric Carlson <eric.carlson@apple.com>
>>>> wrote:
>>>>>
>>>>> On Mar 2, 2010, at 11:14 PM, Silvia Pfeiffer wrote:
>>>>>
>>>>>>>
>>>>>>> You also didn't answer my second question -  are track names
>>>>>>> typically
>>>>>>> unique? Do media container formats generally guarantee the presence
>>>>>>> of
>>>>>>> unique track names?
>>>>>>
>>>>>> There is no guarantee of their existence - same for the role
>>>>>> attribute. But where they exist, they are unique.
>>>>>>
>>>>>  Track IDs (which are numeric) in QuickTime and MPEG-4 files are
>>>>> guaranteed to be unique, track names are not required and are *not*
>>>>> guaranteed to be unique.
>>>>
>>>>
>>>> So maybe for MPEG the track ID is the one that should be mapped to the
>>>> this field here as text? Or alternatively it could be a combination of
>>>> track name and the track ID?
>>>
>>> It seems like you can always provide a numeric indexing API to the tracks
>>> regardless of the media format. How about we make that the primary way to
>>> query for a track, and leave the name as an informative field?
>>>
>>> Using a numeric ID as a string name would be particularly confusing with
>>> the
>>> proposed API, since there are both name and index getters. Let's say you
>>> have a track that is first in the MediaTracks list, and it has a numeric
>>> track ID of "2".
>>>
>>> You might expect that myVideoElement.tracks["2"] will get the track with
>>> ID
>>> 2. But it will instead get the third track in the tracks list. That's
>>> because index getters take priority over name getters, and
>>>  myVideoElement.tracks[2] means the same thing as
>>>  myVideoElement.tracks["2"] in JavaScript. For this reason, it is a bad
>>> idea
>>> to provide both index getters and name getters when the names may be
>>> numeric.
>>>
>>> I suggest that we drop the name getter, since the index getter is more
>>> fundamental. No matter what kind of query you want to do, you can alway
>>> loop
>>> over all the tracks using tracks.length and the tracks index getter.
>>
>> OK, I see the problem. I didn't consider that JavaScript converts sees
>> no difference in [2] and ["2"].
>>
>> I have no issue with removing the getter on namedItem. I don't think
>> it's important.
>> The other getter already does the index by number.
>
> I agree with removing it. The only reason it was there to begin with was
> because the HTMLCollection interface was copied. The remaining
> tracks.item(n) is not very useful as it is only a longer way of writing
> tracks[n]. Is it really necessary to keep it for these hypothetical
> non-ECMAScript languages that might implement the interface?


I would keep it as such, since it is consistent with other such interfaces.

Cheers,
Silvia.

Received on Thursday, 4 March 2010 05:53:24 UTC