Re: [media] a first draft JavaScript API for multitrack media

Hi all, and in particular media subgroup,

Today we had a phone discussion about the JavaScript API spec and we
realised that we haven't actually specified the list of roles that the
@roles attribute should accept.

So, I wanted to start a discussion on this with the goal of eventually
reaching a list that we can all agree on to cover the known use cases.

Let me start by stating that in today's call everyone agreed that we
need to come up with a determined list of values for the roles, so if
you disagree with that, you should speak up now.

So, let me start proposing a list of track roles:

Video track roles:
* "main"
* "alternate" (e.g. different camera angle; happy to stick with Apple
terminology ;-)
* "sign" (for sign language)

Audio track roles:
* "main"
* "alternate" (probably linked to an alternate video track)
* "dub"
* "audesc" (audio description)
* "music"
* "sfx" (sound effects)

Text track roles:
* "caption"
* "subtitle"
* "textaudesc" (textual audio descriptions; to be used as braille or
through TTS)
* "karaoke"
* "chapters"
* "ticker text"
* "lyrics"

We could most certainly also think about abbreviating them, e.g. "CC",
"SUB", "AD", so I wonder what everyone's preferences are here.

So, shoot away with your own preferred track types! What conventions
are you used to from MPEG?

Cheers,
Silvia.



On Tue, Feb 9, 2010 at 9:55 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Everybody,
>
> In a separate thread (which apparently was rather productive), we
> started drafting an extension to the HTML5 media element with a
> JavaScript API to access the track structure of the media resource.
>
> The discussion relates to bugs 5758 and 8659 and resulted in a
> first draft specification at:
> http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
>
> What do people think about this API? Are there any ideas for improvement?
>
> I am asking these questions because I would like us to take a step
> forward in media accessibility. I would like us to decide that these
> specifications are sensible and a good first draft to start basing
> implementations on. It is, btw, expected that these implementations
> will give us feedback about the usability of this API, identify any
> further gaps, and lead to further improvements. Right now, though, is
> probably a good time to take a deep breath and ask everyone's input
> before moving forward.
>
> Best Regards,
> Silvia.
>

Received on Wednesday, 17 February 2010 03:45:24 UTC