W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: Survey ready on Media Multitrack API proposal

From: Philip Jägenstedt <philipj@opera.com>
Date: Fri, 05 Mar 2010 11:30:20 +0800
To: "Eric Carlson" <eric.carlson@apple.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Michael(tm) Smith" <mike@w3.org>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u82r0uxyatwj1d@philip-pc>
On Fri, 05 Mar 2010 05:24:00 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Fri, Mar 5, 2010 at 2:25 AM, Eric Carlson <eric.carlson@apple.com>  
> wrote:
>>
>> On Mar 2, 2010, at 10:35 PM, Michael(tm) Smith wrote:
>>
>> A survey is ready on the "Media Multitrack API" draft change
>> proposal.
>>
>>  http://www.w3.org/2002/09/wbs/44061/multitrack-api/
>>
>>
>>   I support submitting this to the WG with the following minor changes:
>>   + Fix typo, METADATA_LOADED should be HAVE_METADATA.
>>   + As discussed in email, remove the namedItem method.
>>   + Fix typo that says all attributes are ready-only (enabled is
>> read-write).
>>   + Remove "media" attribute.
>
> That's a good summary and extension of the existing list of changes. I
> agree with these.

I agree.

>>   + Add a "src" attribute so it is possible to identify where external
>> tracks come from.
>
> Should the JavaScript API for internal tracks then return the original
> resource @src value? I think that can make sense.
> [Note: It could also be a Media Fragment URI that points to the track,
> such as video.ogv?track="subtitle" but these are only just in the
> process of being standardised. ;-) ]

The same as currentSrc would do, but if we use MF it should certainly be  
the fragment variant (#track=...)

> There's only one open issue FAIKT:
> What shall we do about the grouping. Do we want to add a @group
> attribute (readonly DOMString) to the MediaTrack which can then take
> on the same value for all the tracks that belong to the same group
> (e.g. "1")? Or shall we just not worry about this for the moment since
> it is not very common in MPEG files and doesn't exist (yet) in Ogg
> files? We can always add a solution to this later.

If we decide to slap it on later then the only option will be to put it in  
an property on MediaTrack, which means that each group will actually have  
to have a name. I think that groups, like tracks should be indexed by  
number and have an optional name. Otherwise, what is the group property  
for the tracks in this example?

<trackgroup> <!-- no name -->
   <track>
   <track>
</trackgroup>

The safest solution is something like this:

interface HTMLMediaElement : HTMLElement {
   ...
   readonly attribute MediaTrackGroups trackgroups;
   ...
};

interface MediaTrackGroups {
   readonly attribute unsigned long length;
   caller getter MediaTrackGroup item(in unsigned long index);
};

interface MediaTrackGroup {
   readonly attribute DOMString name;
   readonly attribute unsigned long length;
   caller getter MediaTrack item(in unsigned long index);
};

interface MediaTrack {
   readonly attribute DOMString name;
   readonly attribute DOMString role;
   readonly attribute DOMString type;
   readonly attribute DOMString src;
   readonly attribute DOMString language;
            attribute boolean enabled;
};

In other words, MediaTracks becomes MediaTrackGroup and MediaTrackGroups  
is what is exposed on HTMLMediaElement. I don't think this is brilliant  
 from a script author's point of view, but don't have any better ideas at  
this point.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 5 March 2010 03:31:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:03 GMT