W3C home > Mailing lists > Public > public-secondscreen@w3.org > July 2015

Re: [presentation-api] Presenting the content of an <audio> or <video> element

From: Duan Yao via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Jul 2015 02:48:16 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-125416953-1438051695-sysbot+gh@w3.org>
I don't think limiting remote presenting to media elements is a good 
idea. E.g. what if one want to use a video player with custom UI?

This is my proposal (was posted to the mail list ["extend fullscreen 
API to support second 

Local UA                                   network
                              Remote UA

a Element                  -----------captured live video 
stream------->    a HTMLVideoElement
(requestSecondScreen(),    <----------input 
events----------------------    (fullscreened, RDP client)
RDP server)
a local RDP client)


To summarize:

* Any local element can `requestSecondScreen()` (a remote version of 
`requestFullscreen()`). If succeed, the element is _projected_ to the 
remote UA.
* The local element projected act as a 
[RDP](https://en.wikipedia.org/wiki/Remote_Desktop_Protocol) server, 
while the remote UA create a special HTMLVideoElement which acts as a 
RDP client, and connects to the RDP server. (Not saying that we must 
use RDP, just an example). The projected element is rendered locally, 
but according to the dimension of the remote screen. Input events of 
the second screen are sent back to the local UA to process.
* There is a pseudo-element `::mirror` act as a local RDP client in 
place of projected element to show a scaled-down view of it.
* No cross-document messaging required, and client code just feels it 
is working with a single document.

GitHub Notif of comment by duanyao
Received on Tuesday, 28 July 2015 02:48:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:58 UTC