[whatwg] MediaController feedback
Jer Noble
jer.noble at apple.com
Mon Jun 4 22:59:15 PDT 2012
On Jun 4, 2012, at 5:12 PM, Ian Hickson <ian at 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
More information about the whatwg
mailing list