RE: Tech Discussions on the Multitrack Media (issue-152)

David & Eric.

There seem to be two possible interpretations of 
     <track kind="descriptions" srclang="en" label="English Audio Description">
          <source src="audesc.ogg" type="audio/ogg">
          <source src="audesc.mp3" type="audio/mpeg">
One is that the audesc media is a complete replacement for the audio in the <source> element with the main soundtrack and descriptions pre-mixed, the second that the audesc is only the descriptions, and is intended to be mixed with the <source> audio at the client. Similar comments apply to the sign language option; and might even, if the captions option were of type video, apply to kind captions too where it is a replacement video with the captions burned in, or a smaller video with burned in captions to be placed PiP.

Do you intend that the 'kind' attribute be able to distinguish between these cases, or would it be better if there were a separate '@combinator={replace|add}' attribute that allows the author to mark these cases?


-----Original Message-----
From: [] On Behalf Of David Singer
Sent: 01 March 2011 22:52
To: Silvia Pfeiffer
Cc: public-html
Subject: Re: Tech Discussions on the Multitrack Media (issue-152)

Hi Silvia, friends

Eric and I have been discussing this, and we've added an 8th option to the Wiki, for your consideration.

at <>

On Feb 9, 2011, at 15:56 , Silvia Pfeiffer wrote:

> Everyone,
> Your input on this is requested.
> Issue-152 is asking for change proposals for a solution for media
> resources that have more than just one audio and one video track
> associated with them. The spec addresses this need for text tracks
> such as captions and subtitles only [1]. But we haven't solved this
> problem for additional audio and video tracks such as audio
> descriptions, sign language video, and dubbed audio tracks.
> In the accessibility task force we have discussed different options
> over the last months. However, the number of people that provide
> technical input on issues related to media in the TF is fairly
> limited, so we have decided to use the available time until a change
> proposal for issue-152 is due (21st February [2]) to open the
> discussion to the larger HTML working group with the hope of hearing
> more opinions.
> Past accessibility task force discussions [3][4] have exposed a number
> of possible markup/API solutions.
> The different approaches are listed at
> . This
> may be an incomplete list, but it's a start. If you have any better
> ideas, do speak up.
> Which approach do people favor and why?
> Cheers,
> Silvia.
> [1]
> [2]
> [3]
> [4]

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 2 March 2011 13:37:56 UTC