W3C WBS Home

Results of Questionnaire Consensus check on Media Multitrack API proposal

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: cooper@w3.org, mike@w3.org, janina@rednote.net,

This questionnaire was open from 2010-03-02 to 2010-03-06.

7 answers have been received.

Jump to results for question:

  1. Media Multitrack API proposal

1. Media Multitrack API proposal

The media subgroup of the HTML Accessibility Task Force, as part of their work to help improve accessibility support for the HTML5 media elements, has developed a first draft for a JavaScript API for multitrack media resources.

The Media Multitrack API proposal introduces a JavaScript API for extracting basic information about the tracks contained inside a media (audio or video) resource—which may include:

The proposal also encourages browser vendors to expose visual and accessible controls for activating and deactivating tracks in multitrack media resources.

The media subgroup believes that this proposal is sufficiently developed to propose it to the HTML WG as a first step towards addressing the following:

The proposal is written as a change request and, if applied to the HTML5 specification, will encourage trial implementations in Web browsers.

Do you support presenting the proposal as a change request to the HTML working group?

Summary

ChoiceAll responders
Results
Submit this proposal to the HTML WG as a decision of the task force. 4
Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. 2
Do not submit this proposal to the HTML WG for the following reasons.

(1 response didn't contain an answer to this question)

Details

Responder Media Multitrack API proposalComments
Maciej Stachowiak
Philip Jägenstedt Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. 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?)
* Type cannot be a mime type as the tracks of media files are not described with MIME types internally. For example, what is the MIME type of a MP3 stream in a RIFF WAVE container? Should the MIME type actually be the type of the container, with the tracks type in the codecs parameter?
* Drop media as it belongs in the HTML markup, this information is not available from tracks in the media resource.

Also, what about track groups? If the suggestion for referencing external tracks is going to be <trackgroup><track>, shouldn't the groups of internal tracks be exposed in some way too?
Silvia Pfeiffer Submit this proposal to the HTML WG as a decision of the task force. This proposal is exposing the tracks of a media resource in a generic way similar to what the MPEG container exposes. It will allow making use of accessibility and other tracks of media resources.
Shelley Powers Submit this proposal to the HTML WG as a decision of the task force.
Geoff Freed Submit this proposal to the HTML WG as a decision of the task force.
Markku Hakkinen Submit this proposal to the HTML WG as a decision of the task force.
Eric Carlson Submit this proposal, with the following changes, to the HTML WG as a decision of the task force. + 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.
+ Add a "src" attribute so it is possible to identify where external tracks come from.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Richard Schwerdtfeger <schwer@us.ibm.com>
  2. Judy Brewer <jbrewer@w3.org>
  3. Liam Quin <liam@w3.org>
  4. Wendy Chisholm <wendc@microsoft.com>
  5. Jim Allan <jimallan@tsbvi.edu>
  6. Charles McCathie Nevile <chaals@yandex-team.ru>
  7. Philippe Le Hégaret <plh@w3.org>
  8. Cynthia Shelly <cyns@microsoft.com>
  9. Sean Hayes <sean.hayes@microsoft.com>
  10. Ian Hickson <ian@hixie.ch>
  11. Paul Cotton <Paul.Cotton@microsoft.com>
  12. Shane McCarron <shane@aptest.com>
  13. Janina Sajka <janina@rednote.net>
  14. Michael Cooper <cooper@w3.org>
  15. Steve Faulkner <faulkner.steve@gmail.com>
  16. David MacDonald <David100@sympatico.ca>
  17. Sam Ruby <rubys@intertwingly.net>
  18. Michael[tm] Smith <mike@w3.org>
  19. Kelly Ford <kelly.ford@microsoft.com>
  20. Stefan Schnabel <stefan.schnabel@sap.com>
  21. Matthew Turvey <mcturvey@gmail.com>
  22. John Foliot <john.foliot@deque.com>
  23. Kenny Johar <kensingh@microsoft.com>
  24. Sally Cain <sally.cain@rnib.org.uk>
  25. David Bolter <dbolter@mozilla.com>
  26. Jeanne F Spellman <jeanne@w3.org>
  27. Jean-Pierre EVAIN <evain@ebu.ch>
  28. Frank Olivier <frank.olivier@microsoft.com>
  29. Jatinder Mann <jmann@microsoft.com>
  30. Ian Pouncey <w3c@ipouncey.co.uk>
  31. Léonie Watson <lwatson@paciellogroup.com>
  32. Masatomo Kobayashi <mstm@jp.ibm.com>
  33. Bob Lund <b.lund@cablelabs.com>
  34. Mark Watson <watsonm@netflix.com>
  35. Adrian Roselli <roselli@algonquinstudios.com>
  36. Jason Kiss <jason@accessibleculture.org>
  37. Billy Gregory <bgregory@paciellogroup.com>
  38. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  39. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  40. Brian Kardell <hitchjs@gmail.com>
  41. Joseph Karr O'Connor <josephoconnor@mac.com>
  42. Joanmarie Diggs <jdiggs@igalia.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.127 2015-02-04 08:52:34 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)