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:03:23 +1100
Message-ID: <2c0e02831003022303i13f3e088k7dd091b797a08628@mail.gmail.com>
To: "Michael(tm) Smith" <mike@w3.org>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
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

> 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,

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:04:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:33 UTC