W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] MediaController feedback

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 5 Jun 2012 00:12:58 +0000 (UTC)
To: Jer Noble <jer.noble@apple.com>
Message-ID: <Pine.LNX.4.64.1206042312210.378@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>
On Wed, 2 Nov 2011, Jer Noble wrote:
> 
> I'm currently working on implementing MediaController in WebKit 
> <https://bugs.webkit.org/show_bug.cgi?id=71341>, and have a couple 
> pieces of feedback from an implementor's POV:
> 
> * MediaController Playback State and Ready State
> 
> The spec defines both a "most recently reported readiness state"[1] and 
> a "most recently reported playback state"[2] which, when changed, 
> trigger a variety of event.  Because these previous values of these 
> states must be compared each time they are recomputed[3], we must store 
> these values in our MediaController implementation, which is no huge 
> burdon.
> 
> However, when I was writing testcases for my implementation, I noticed 
> that there was no way to query the current value of either the playback 
> state or the ready state, as neither was present in the IDL for 
> MediaController.  This makes writing test cases much more difficult, as 
> they now much rely on waiting for edge-triggered events.
> 
> In addition, there is a use case for having playbackState and readyState 
> in the MediaController IDL.
> 
> When adding a MediaController to an HTMLMediaElement, the spec does not 
> require the media controller to "report the controller state".  (It does 
> require that the MediaController "bring the media element up to speed" 
> with the new controller.)  In this case, the media controller should 
> also be requried to "report the controller state", as adding a blocking 
> media element to a controller should probably cause the playbackState to 
> revert to WAITING.  But if the current playbackState is already WAITING, 
> no "waiting" event will be emitted, and the client waiting on such an 
> event will wait forever.

I've updated to report the controller state.

Actually exposing the controller state is not as trivial as it may first 
appear, in particular if we want to maintain the synchronous illusion 
(i.e. only change the state as the events fire, not before). But I've done 
that too.


> * MediaController.play()
> 
> The MediaController play() function does not actually cause its slaved 
> media elements to play.  If all the slaved media elements are paused, 
> the MediaController is a blocked media controller, and none will play 
> until at least one element has play() called on it directly.  And even 
> in that case, only the playing elements will begin playing.
> 
> In addition, the "user interface" section of the spec says the 
> following:
> 
> > When a media element has a current media controller, and all the 
> > slaved media elements of that MediaController are paused, the user 
> > agent should unpause all the slaved media elements when the user 
> > invokes a user agent interface control for beginning playback.
> 
> So now, an individual media control must be able to access all other 
> HTMLMediaElements associated with a given MediaController, because there 
> is no facility in MediaController to actually unpause all the slaved 
> media elements.  In a previous paragraph in that same section:
> 
> > When a media element has a current media controller, the user agent's 
> > user interface for pausing and unpausing playback, for seeking, for 
> > changing the rate of playback, for fast-forwarding or rewinding, and 
> > for muting or changing the volume of audio of the entire group must be 
> > implemented in terms of the MediaController API exposed on that 
> > current media controller.
> 
> Except, in the case of unpausing, this extra requirement of unpausing 
> the slaved media elements is somewhat in conflict with this paragraph.

I tried to fix this.


> I would like to propose three changes to the spec:
> 
> + Modify the section "bring the media element up to speed with the new 
> controller"[5] to require that a media element added to a playing media 
> controller must begin playing, and one added to a paused media 
> controller must pause.
> 
> + Modiy the section "controller . play()"[6] to require that the user 
> agent unpause all the slaved media elements.
> 
> + Modify the section "controller . pause()"[7] to require that the user 
> egent pause all the slaved media elements.
> 
> + Remove the section from "user interface"[8] which requires the user 
> agent unpause all the slaved media elements, quoted above.

I don't really understand this proposal. Could you elaborate on this?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 June 2012 00:13:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC