W3C home > Mailing lists > Public > public-html@w3.org > February 2011

Re: Change proposal for issue 152

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 23 Feb 2011 15:16:29 +1100
Message-ID: <AANLkTinqgMgYZ1SqUP12MHTvr_98TXE2UVpn9GcnVmx6@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Philip Jägenstedt <philipj@opera.com>, public-html@w3.org
If there is a large-ish number of change proposals and a lot of
discussion, signifying that we've not reached the end of a design
process, is there still a possibility to move it to a Last Call issue?
I am doubtful that given the tight deadline on pre-LC issue we will
actually come to an agreement on this. This is not like there is a
mistake in the spec which has to be fixed, but it is a new feature
that needs to be developed with adequate discussion.

Regards,
Silvia.


On Wed, Feb 23, 2011 at 3:09 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> Separate from this proposal, we've had a suggestion to defer this issue to be a Last Call issue instead of pre-LC, which would allow significant extra time. However, until that is decided, we strongly recommend providing counter-proposals or making revisions to this one if does not seem sufficient.
>
> Regards,
> Maciej
>
> On Feb 22, 2011, at 2:45 AM, Philip Jägenstedt wrote:
>
>> 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 Wednesday, 23 February 2011 04:17:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:22 GMT