Re: Change proposal for issue 152

[rewriting history to make it clear who said what]

On Tue, 08 Mar 2011 02:20:41 +0100, Frank Olivier  
<Frank.Olivier@microsoft.com> 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.

> On Feb 22, 2011, at 2:45 AM, Philip Jägenstedt wrote:

>> 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.

That it makes sense is one thing, but do you want it to be the only  
solution? If only in-band audio tracks are possible, do you intend that  
the same be true of video tracks? The complexity is rather similar, after  
all. If we have no mechanism for syncing out-of-band video  tracks, we are  
effectively discouraging for example sign language tracks because it would  
require either wasting bandwidth (sending everyone the sign language  
track) or storage (having two versions of the resource, one with the sign  
language track and one without it).

On Tue, 08 Mar 2011 22:58:25 +0100, John Foliot <jfoliot@stanford.edu>  
wrote:

> 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...)

John, I take it you didn't actually agree with what Frank said, but with  
something else?

>> 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.

This requires specialized server software and cannot be deployed on dumb  
HTTP servers, which I would consider a problem. The extra bandwidth of one  
additional audio track may be tolerable, but for extra video tracks this  
will certainly not be the case.

>> 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.

>> 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.

Great, do you intend to update your CP to achieve this consistency?

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 9 March 2011 08:06:01 UTC