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

Re: Survey ready on Media Multitrack API proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 3 Mar 2010 18:07:14 +1100
Message-ID: <2c0e02831003022307r64f0d96eo72251f5b225bd6c7@mail.gmail.com>
To: "Michael(tm) Smith" <mike@w3.org>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Ups, sorry - that was Maciej's reply and not yours and he has already
removed it.
Anyway - those were good questions and worthy of a reply.

Cheers,
Silvia.


On Wed, Mar 3, 2010 at 6:03 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi Michael,
>
> I saw your questions on the proposal, so thought I should reply immediately.
>
>> 1) Is it a common use case to want to get a track by name? Is it common for tracks in a media file to even have unique names?
>> I am not sure namedItem() is justified.
>
> A name is the best possible way to address individual tracks. That
> name may well be a number in some media file formats, but the most
> general case is to provide a string.
>
>
>> 2) Isn't it more likely that you'd want to get all the tracks of a given role? I think getTracksByRole() might be a more useful
>> API addition.
>
> It may indeed turn out that this most basic API needs some extensions.
> For now, we just want to be able to expose the most important
> information about the tracks of a media resource to the browser.
> getTracksByRole() can be simulated with this given API, so it is
> strictly not necessary. It would however be a valuable simplification
> for JavaScript. I'd suggest we get the basic implementation first
> before we ask browser vendors to make more complicated convenience
> functions.
>
>
>> 3) This API offers a very general ability to introspect the available tracks. It seems more power than is strictly needed just for
>> captioning purposes. Do we have use cases for the more general uses for this API?
>
> We are indeed looking at far more than captions here, which is why
> this is not called a caption API, but a multitrack media API. It
> allows also access to tracks such as sign language video tracks or
> audio description audio tracks or in fact other audio, video or text
> tracks that may be available inside a multitrack media resource. A
> simplification of this API by specialising it only for captions would
> not make sense since firstly the API could not be made much simpler
> and secondly we need the full access to all available tracks anyway,
> so should solve the problem properly.
>
>
> Best Regards,
> Silvia.
>
>
> 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
>>
>>
>>
>>
>
Received on Wednesday, 3 March 2010 07:08:08 GMT

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