RE: Change proposal for issue 152

Frank Olivier wrote:
>
> Thanks for the feedback; We’re certainly open to the idea of adjusting
> the API in the CP. I know we've been discussing this in other mail
> threads, but I also want to do appoint-by-point reply to your comments.
>
> "1. Only provides a solution for additional audio tracks, while ISSUE-
> 152 calls is about "additional tracks of a multitrack audio/video
> resource"."
> "2. Unlike the API for text tracks, doesn't provide a consistent API
> for additional audio/video tracks that are in-band and out-of-band."
> We agree that a common API set would be a good approach.

+1

>
> "3. Only allows one audio track to be enabled at a time, making it
> unsuitable for audio descriptions voice-over which should be played in
> sync with the original audio track. I'm not sure how common this is in
> practice, but the alternative is to make a complete new audio mix with
> both the original audio and the voice-over."
> We think the new audio mix (aka alternate track) approach makes most
> sense here; synchronizing various audio tracks seems to be overly
> complex/prone to quality-of-implementation issues, compared to
> creating/publishing an alternate track.

Agreed. It may be the case that the described audio would be created by a 
party other than the original content owner/producer (a common scenario in 
Higher Education), so adding an external audio source here is far superior 
an option than expecting the original media to be re-mastered (there may 
also be copyright considerations here...)


>
> "4. audioTrackCount/audioTrackLanguage is inconsistent with TextTrack[]
> tracks where language information is in TextTrack.language."
> "5. audioTrackCount is redundant with audioTrackLanguage.length"
> "6. Enables/disabled tracks using currentAudioTrack rather than
> TextTrack.mode"
> "7. If audio tracks are added or removed during playback, will
> currentAudioTrack unsigned long implicitly change with it or will the
> current track actually change?"
> Good feedback; making this interface consistent with text track would
> be a good approach.
>
> "8. Since only in-band tracks are handled, the solution requires muxing
> all audio tracks into a single resource, taking up bandwidth for all
> users, not just the ones who use the extra tracks."
> Not necessary, since the actual media data can be stored in segments
> (depending on the media format on the server end).  It is up to the UA
> to stitch them together under the hood. In practice, in the simple
> single file case, the additional bandwidth is not likely to be
> prohibitive.

Note that we hope to actively pursue a solution to this problem at the 
Face-to-Face (http://www.w3.org/WAI/PF/HTML/ftf_2011-03#agenda) - Philip we 
hope you can join us remotely for at least part of the session(s).

Cheers!

JF

Received on Tuesday, 8 March 2011 21:58:58 UTC