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: Wed, 03 Mar 2010 21:26:52 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Michael(tm) Smith" <mike@w3.org>, "Eric Carlson" <eric.carlson@apple.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u8zua2ziatwj1d@philip-pc.oslo.opera.com>
On Wed, 03 Mar 2010 21:11:32 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> Replies inline.
>
>
> On Wed, Mar 3, 2010 at 11:58 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Wed, 03 Mar 2010 18:45:28 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Wed, Mar 3, 2010 at 5:35 PM, Michael(tm) Smith <mike@w3.org> wrote:
>>>>
>>>> A survey is ready on the "Media Multitrack API" draft change
>>>> proposal.
>>>>
>>>>  http://www.w3.org/2002/09/wbs/44061/multitrack-api/
>>>>
>>>> The survey asks you to evaluate the proposal, which is for a
>>>> JavaScript API for extracting basic information about tracks
>>>> contained inside a media (audio or video) resource, and indicate
>>>> whether you support submitting it to the HTML WG as a decision
>>>> from the a11y TF; it also provides you with an opportunity to
>>>> suggest changes to the proposal, and, if you indicate that you
>>>> don't support submitting the proposal to the group, asks that you
>>>> provide a comment giving your reasons.
>>>>
>>>> Only members of the HTML Accessibility Task Force can complete
>>>> this survey. It is only a straw poll of the members of this task
>>>> force. However, note that the results are publicly visible:
>>>>
>>>>  http://www.w3.org/2002/09/wbs/44061/multitrack-api/results
>>>>
>>>> --
>>>> Michael(tm) Smith
>>>> http://people.w3.org/mike
>>>
>>>
>>> Hmm, it seems there is more discussion to be had about this proposal.
>>>
>>> I'd like to address Philip's concerns, so we can move forward.
>>>
>>>> The MediaTrack interface:
>>>> * Drop role unless it is actually exposed in exactly that way in  
>>>> existing
>>>> media formats, or describe how it can be derived from the
>>>> information in existing media formats. Describe what value it should  
>>>> have
>>>> when the information is not available (null or the empty
>>>> string?)
>>>
>>> There will be a need to map from existing media formats to this role,
>>> indeed. IIUC (and Eric or David can correct me), both QuickTime and
>>> MPEG-4 expose certain information that relates to the roles that we
>>> are describing. However, it is a text field and values have not been
>>> pre-defined, so conventions will need to be used to map to our defined
>>> roles.
>>
>> I'll leave it to Eric to comment on the details, but it sounds like role
>> should just be a free-form string, just that UAs won't attach any  
>> behavior
>> to unrecognized roles.
>
> It believe it already is a free-form string, but with some default
> roles defined - those roles that made sense. We had a discussion about
> this at the subgroup teleconf, btw, and agreed that it makes sense to
> pre-define a set of roles so as to make the obvious roles
> interoperable. Do you disagree with that proposal?

What I'm saying is that whatever is in the media resource gets exposed as  
is in the API, i.e. the UA makes no attempt to map things to any of the  
predefined values. But this only works if all interesting container  
formats already have something like role and the identifiers used are the  
same as the ones we want in HTML5.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 3 March 2010 13:27:36 GMT

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