Re: Change proposal for issue 152

On Tue, 22 Feb 2011 01:45:17 +0100, Frank Olivier  
<Frank.Olivier@microsoft.com> wrote:

> This is a change proposal for Issue 152, introducing a JavaScript API  
> for HTML5 media elements that allows Web authors to provide alternate  
> modes of presentation for a media presentation and allow selection  
> between them by the end user.
>
> It is a minimal extension to the existing API in that it does not  
> provide detailed access to the media tracks themselves, but merely  
> provides a means of indicating their presence and a means of selecting  
> between the presentation modes.

Before I go into criticism mode, it's great that you're working on this!

These issues are under active discussion, mostly in the "Tech Discussions  
on the Multitrack Media" thread, and it would be great to have Microsoft's  
feedback in that thread. Since the requirements and possible solutions are  
still so much in flux, I think it's rather premature to go through the  
decision process right now.

I see these problems with this CP:

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.

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.

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?

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.

I'd also like to question the assertion that "This mechanism does not  
preclude a richer API being defined in the future". If we add the  
suggested API, we cannot later add another API that does the same thing,  
since the interactions between the APIs would become a mess unless the  
underlying model is the same. In this case it is clear that is not, in  
that this API assumes that the number of audio tracks is static and that  
only one can be active at a time, which isn't the case in an API like  
TextTrack.

I hope that the process will not be rushed on this, allowing time for  
experimentation with both the spec and implementations.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 22 February 2011 10:46:22 UTC