W3C home > Mailing lists > Public > public-webscreens@w3.org > September 2019

Re: [openscreenprotocol] Multiple controllers of remote playback (#149)

From: Takumi Fujimoto via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 Sep 2019 20:47:48 +0000
To: public-webscreens@w3.org
Message-ID: <issue_comment.created-531385849-1568407667-sysbot+gh@w3.org>
> On a blank/empty HtmlMediaElement? What if it's not empty? Does it change the source of the remote element?

Maybe there can be two methods: one that always uses the controller's source, and another method that overwrites the local element with the receiver's media, if there already exists a session. This would let the site choose the behavior.

Alternatively, prompt() can handle all the cases, and the user can choose in the UA's UI which source to use. Then the controller page would know which by looking at the currentSrc (or src?) This would let the user choose the behavior.

We need to handle cases where we're using the receiver's source and the media types are different (\<audio\> vs \<video\>) between the controller and receiver elements. We can require the controller UA to prevent such reconnects, or throw an error. I think the former is a better UX.

> What can Presentations do right now?

It requires that the reconnecting PresentationRequest already knows the receiver's URL: ["Its presentation URL is equal to one of the presentation request URLs of presentationRequest"](https://w3c.github.io/presentation-api/#reconnecting-to-a-presentation). Its Remote Playback equivalent would be for the HTMLMediaElement to already have the media URL (or just the origin?) as a source, which I don't think is practical.

GitHub Notification of comment by takumif
Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/149#issuecomment-531385849 using your GitHub account
Received on Friday, 13 September 2019 20:47:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:19 UTC