- From: Google <sysbot+gh@w3.org>
- Date: Tue, 23 Jan 2018 01:11:43 +0000
- To: public-secondscreen@w3.org
mfoltzgoogle has just created a new issue for https://github.com/w3c/remote-playback: == Compatibility of Remote Playback API with AirPlay mirroring == This is following up on on a conversation with @jernoble at TPAC. Please correct any mistaken assumptions below :-) Apple iOS devices allow AirPlay mirroring to be enabled at the system level, and this automatically triggers remote playback of `<video>` elements in Safari to Apple TV. In this mode, when the user plays a `<video>` then triggers fullscreen on the `<video>`, remote playback is triggered on the Apple TV and the poster is replaced with an AirPlay icon. I tested with the following site: https://mfoltzgoogle.github.io/sandbox/media/remote-playback.html In some cases, after exiting fullscreen and navigating (reloading), a new `<video>` was started in AirPlay mode and the value of `webkitCurrentPlaybackTargetIsWireless` was initialized to `true`. What does this mean for the spec? It seems like we should first clarify that this mode of use is possible, what state `remote.state` starts in, and what steps the user agent should take when the user enters/exits system wide remote playback mode. One set of suggested edits to https://w3c.github.io/remote-playback/#browser-initiated-remote-playback: > ...for example, by clicking a button in the browser _or connecting to a remote playback device through the OS_. If the user agent supports browser initiated remote playback, _the state attribute MUST reflect the current state of the connection to the remote playback device. When the browser initiates or terminates_ remote playback, _the user agent MUST fire the corresponding events by_ following the steps to establish a connection with the remote playback device and disconnecting from a remote playback device." A remaining issue is whether `video.remote.state` should start in the `connecting` state when its <video> element is created in a system-wide remote playback mode, and immediately begins remote playback. The user agent is already "connected" to the remote playback device so maybe a `connecting` state isn't necessary. But keeping the current steps would make behavior more consistent between site-initiated and browser-initiated remote playback. So I lean towards starting in a `connecting` state and immediately firing the `connect` event when remote playback has begun (i.e. element state has been remoted). I'll craft a PR with the suggestions above. CC @mounirlamouri Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/114 using your GitHub account
Received on Tuesday, 23 January 2018 01:11:46 UTC