Re: [media] handling multitrack audio / video

On Fri, Dec 3, 2010 at 12:11 AM, Geoff Freed <geoff_freed@wgbh.org> wrote:
>
> Hi, Silvia:
>
> It depends on the transmission.  #2 is the case in broadcast:  there’s a
> stream of video + program audio, then on a separate audio channel there’s a
> stream of ducked, full-mix audio.  The viewer is then responsible for
> locating and activating the full-mix audio (usually buried in several layers
> of inaccessible on-screen menus).  #3 is the case on the Web (most of the
> time):  the author provides separate links to undescribed video (video track
> + program-audio track) and open-described video (video track + full-mix
> audio track), allowing the user to choose which to view.  In some cases, an
> author will simply provide a single, open-described video.
>
> Re #1:  you probably know this, but the QuickTime Player and other Apple
> devices will handle additional embedded audio tracks which can be toggled on
> and off via menus, and the JW Player will accept additional audio tracks and
> provide on/off control as well.   And SMIL players can stream additional
> audio tracks, obviously.  But not many authors take advantage of this stuff
> today.

That's exactly why I was asking, since you are in the business of
creating these things right now and would have the most experience.

For #3 there is not much to do actually - just having a means to
switch between resources would be sufficient. That means could be a
button underneath the video or a second tab with the video and lets
the user change between the main video and it's auditory-only
counterpart. I wonder if we even need special accessibility features
for this.

#1 and #2 are the cause of this discussion here. The intention is to
create a markup for #2 and expose both types of tracks - #1 and #2 -
through the same JavaScript API. Since #1 doesn't need extra markup,
it's actually the easier one to come up with a solution for. If you
would have said that #1 is the most common way of publishing audio
descriptions, I would have suggested to just introduce a JS API for
now and not worry about the markup, which is the hardest part to get
right.

Cheers,
Silvia.

Received on Thursday, 2 December 2010 14:32:51 UTC