Re: [whatwg] MediaController feedback

On Jun 4, 2012, at 5:12 PM, Ian Hickson <ian@hixie.ch> wrote:

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

Looks good, thanks.

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

This too looks good.  We already store the results when we report the controller state, so at a first glance, exposing this property will be trivial.

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

Looks good.

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

Sure.

The overall purpose of the modifications is to achieve the following: when controller.play() is called, all slaved media elements unconditionally will begin playing.

Whatever use case is served by allowing a paused media element to remain paused in a playing media controller, that use case could also be achieved by removing the element from the media controller, then pausing it.

However, I now realize that the first change I proposed would turn all MediaControllers into autoplaying media controllers by default. So, I withdraw that change. :-)

And the modification to "controller.pause()" is unnecessary, so I withdraw that as well.

-Jer

Received on Tuesday, 5 June 2012 06:00:33 UTC