Reconnecting media elements to the playback about remote-playback

[mounirlamouri]

I think we should stop the media on the remote device if the page is navigated. Otherwise, we are going to recreate a Presentation API.

@jernoble, WDYT? It seems that Safari iOS stops the session if the page is reloaded but kind of keep it alive if the page is navigated.

[jernoble]

@mounirlamouri I think that would be best (if we stopped the session if the page was navigated).

[avayvod]

FWIW, both Chrome and Firefox don't stop the playback in these cases so may be we could be more flexible and say that the UA can continue playing the video remotely and provide user with some browser controls?

For Chrome, we're going to gather some data on the usage and see if it's useful but continuous playback no matter what as long as there's a way to stop it is preferred by the Chromecast guidelines and seems better for the user (although not for the developer). WDYT?

[avayvod]

@jernoble would you be okay with the proposal above?

[jernoble]

@avayvod Because it may not be a choice that the UA makes (the remote end may choose to end or continue playback when the UA disconnects without input from the UA) I'd be happy if there was some explicit flexibility in the spec w.r.t. the behavior when the page closes or is navigated.

[avayvod]

As I understand it, the resolution is to allow some flexibility in the spec so that the remote playback session doesn't have to be stopped when the media element goes out of scope, however, having a way to reconnect to the running session is not desired at this point (we could revisit it later if there's developer's demand for this API vs Presentation API allowing reconnecting, for example).

[avayvod]

Added a note to the Stopping remote playback section of the spec.

[anssiko]

We revisited this issue at F2F, so I'll reopen so we remember to update the spec with the latest considerations from the Open Screen Protocol.

Related F2F discussion: https://www.w3.org/2019/05/24-webscreens-minutes.html#x08

@mfoltzgoogle

[mounirlamouri]

@mfoltzgoogle @anssiko is there anything else to do here? I'm not sure why this was re-opened.

[anssiko]

Based on F2F minutes https://www.w3.org/2019/05/24-webscreens-minutes.html#x08 it seems this is a v2 issue and would not block v1 API advancement on the Rec Track?

I defer to @mfoltzgoogle to confirm.

[mfoltzgoogle]

We've made a change to the OSP to make it compatible with this scenario, but it would be a new feature as far as the Remote Playback API is concerned. I agree with Anssi that this makes sense to defer to v2.

[mfoltzgoogle]

Sorry didn't intend to close, just defer.

[mfoltzgoogle]

See additional discussion of how remote playbacks could be reconnected in the two openscreen issues above.
Any protocol updates can be proposed after we determine what the requirements are from the API.