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

Hi Silvia,

Great survey of the list of options. 

<chair hat off>

Just to kick off discussion, let me give my offhand opinions. I personally like the following options:

(6) Synchronize separate media elements through attributes
(7) Overload <track> to link a/v element from other place on page

These seem to be the most flexible, because synchronized video can go anywhere, and it seems like these approaches could be useful for non-accessibility purposes too.

My least favorites are:

(1) No markup in HTML - leave to a manifest file

  - It seems much better to have the auxiliary resources exposed in the markup.

(4) Introduce a <par>-like element
(5) Nest media elements

  - These have all the implementation complexity of #6 and #7, but the requirement to nest elements or make them siblings in a <par> parent limits markup flexibility. It makes these options unsuitable for many synchronization use cases.

#2 and #3 seem reasonable, but not as flexible as 6 and 7.

I should also add that, for many mobile devices, it may not be practical to play back more than one media resource at a time. We shouldn't limit the markup based on this, but it might be useful for content authors to be able to discover this on the fly so they can consider alternative measures.

Regards,
Maciej


On Feb 9, 2011, at 3:56 PM, 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
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API . 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] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-track-element
> [2] http://lists.w3.org/Archives/Public/public-html/2011Jan/0198.html
> [3] http://lists.w3.org/Archives/Public/public-html-a11y/2010Oct/0520.html
> [4] http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0057.html
>

Received on Thursday, 10 February 2011 04:47:06 UTC