RE: Requesting display of non HTML content (was: Draft of Second Screen Presentation Working Group Charter available)

Hi Dominik, all,

> -----Original Message-----
> From: Rottsches, Dominik [mailto:dominik.rottsches@intel.com]
> Sent: Dienstag, 10. Juni 2014 14:30
> To: public-webscreens@w3.org
> Cc: B.Lund@cablelabs.com; watsonm@netflix.com; fd@w3.org;
> markdavidscott@google.com; mfoltz@google.com; ddavis@w3.org;
> ph@w3.org; Kostiainen, Anssi; Bassbouss, Louay
> Subject: Re: Requesting display of non HTML content (was: Draft of Second
> Screen Presentation Working Group Charter available)
> 
> Hi Anssi, Mark, Louay,
> 
> On Mon, 2014-06-02 at 10:36 -0700, mark a. foltz wrote:
> 
> > I also agree that this is a good starting point, as it re-uses the
> > HTMLMediaElement APIs for both local and remote playback (and this was
> > one of the alternatives I proposed earlier for this functionality).
> > My only caution is that the devil is in the details as there is a
> > large set of functionality that is encapsulated in HTMLMediaElement
> > and not all of it may be compatible with rendering on a remote UA, so
> > we will need to address content specific negotiation of capabilities
> > at some point.
> >
> I like Anssi's idea and flexibility of using alternative types of content. But I
> also agree with Mark that spec'ing the behavior of an HTMLMediaElement
> that goes out to a secondary screen might indeed have the devil in the detail.
> 
> I think instead of spec'ing this behavior, it has a better place in a small helper
> library in JavaScript. Many sites probably already use video wrappers like
> video.js or flvplayer. We could have a companion project for a helper library
> like media-presentation.js that provides a JS function like
> 
> requestShowMedia("http://example.org/myvideo.mp4")
> 
> or that provides a wrapper for
> 
> <html>
> <video id="myvideo" src="myvideo.mp4">
> </html>
> 
> document.querySelector("#myvideo").requestShow()
> This is already doable with the current API proposal that we are discussing on
> the wiki.

Do you mean the helper js library implements requestShowMedia("http://example.org/myvideo.mp4") using something like this requestShow("http://example.org/wrapper.html") where wrapper.html contains the HTML from above and offer video control over webscreen messaging postMessage() and onMessage()?

> 
> I agree with Louay that the idea is desirable, and with Anssi that this would
> improve API ergonomics. But I think it has  better place in a library which can
> evolve faster and more flexibly than a specification.
> I think we reach our goals quicker if we only provide primitives and let library
> developers build on top.
> 
> If we see certain prominent usage patterns emerge from this example or
> similar libraries, we can move them to the native side step by step.
Apple uses just the x-webkit-airplay attribute [1] (possible values are allow or deny) in video elements to enable or disable airplay. Web developers can control and monitor the playback using the standard video functions and events as usual. I we consider this functionality in a programmatic way instead of  declarative way as in apple case, the result will be the same as Anssi proposed. 
> 
> Regards,
> 
> Dominik

[1]: https://developer.apple.com/library/safari/documentation/AudioVideo/Conceptual/AirPlayGuide/OptingInorOutofAirPlay/OptingInorOutofAirPlay.html 

Regards,
Louay

Received on Tuesday, 10 June 2014 13:14:20 UTC