Re: [media] Moving forward on the Multitrack Media API (issue-152)

If there is no feedback on this, I will start preparing a Change
Proposal proposing solutions (7) and (1) as a solution to issue 152.

Cheers,
Silvia.


On Fri, Feb 4, 2011 at 3:39 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Dear fellow accessibility enthusiasts,
>
> Over the last few days I have put a lot of effort into analysing the
> discussion that we had about the multitrack media API.
>
> This work goes towards creating a solution for:
> * video descriptions that are provided as audio files,
> * sign language video,
> * dubbed audio tracks
> * and similar alternative a/v content that we want to deliver together
> with a main video resource.
>
> We actually have issue 152 open for this and the chairs have solicited
> a proposal by 21st February
> (http://lists.w3.org/Archives/Public/public-html/2011Jan/0198.html).
>
> So, I would like us to discuss the available means of solution a bit
> further and if at all possible come to an agreement on the most
> optimal solution to propose to add to the spec. Then we can send that
> in as a change proposal before the 21st February. It's a tight
> deadline, but we have discussed this before (thread starts at
> http://lists.w3.org/Archives/Public/public-html-a11y/2010Oct/0520.html).
>
> I have put the different approaches that were discussed together in a
> wiki page, see http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API
> .
>
> You will notice that this is not a simple decision to make and that
> basically all approaches have advantages and disadvantages. Microsoft
> (through Frank Olivier) have previously stated support for solution
> (2), while Opera (through Philip) have stated support for solution
> (6).
>
> I personally believe that solution (7) seems the most readable while
> at the same time not overly complicating the JavaScript API. It
> retains the use of the @kind, @label and @srclang attributes on the
> <track> element, while at the same time making full use of the
> capabilities of the audio and video elements. It would require
> additional visual indication on the "dependent" audio and video
> elements that they are sub-controlled by the main resource. For
> example, the @controls attribute must be ineffective on these
> dependent elements. Also I think we should introduce specific styling
> for them when they are by default inactive. They will be by default
> inactive unless the user has a setting to make such tracks by default
> active (a HoH user may have sign language on by default and a VI user
> may have audio descriptions on by default).
>
> In addition to solution (7), I also would like to see solution (1)
> supported. However, solution (1) goes hand in hand with a solution on
> HTTP adaptive streaming and the specification of a manifest file
> format is still a while off - being worked on in other circles. So, I
> think the two can go in parallel.
>
> Please don't hesitate to make changes to the wiki page where I have
> made mistakes or where you have more information to contribute.
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API
>
> Curious to hear your opinions.
>
> Best Regards,
> Silvia.
>

Received on Tuesday, 8 February 2011 02:16:48 UTC