Re: Draft of Second Screen Presentation Working Group Charter available (was: Heads-Up: Plan for Working Group on Second Screen Presentation)

Hi all, the way I think of this is divided into three cases:

(1) The content to be shown is an HTML document.  In this case the proposal
that Anssi put forward describes how this case would be handled.  The
controlling application would provide the URL to a page that it knows how
to control, which could generate the media itself or take a URL to the
media to play back.  The presenting and presented pages would agree
beforehand on the control protocol.

(2) The content to be shown is an application with a well defined control
mechanism known to the requesting page, but is not necessarily an HTML
document.  In this scenario the API would work something like

requestSession(‘dial://netflix.com/Netflix' <http://example.org/foo.html'>,
'application/dial');

(I am making up a scheme for specifying a DIAL application, we could
overload the http:// scheme for this or use another type of URN.)

Netflix could publish the control protocol for their application or a JS
library to encapsulate it, if they wanted to, or keep it proprietary to
their site(s).

(3) The content is a generic media type (such as would be shown in <audio>
or <video>) that could be rendered in multiple ways.  I agree with Louay
that we don't have a good standardized control mechanism for this case.
 Here are a few options that come to mind.

(3a) Specify (in this WG or elsewhere) a set of high level control messages
that must be understood by all screens that accept generic media.
(3b) Evolve the API to integrate more closely with the <video> or <audio>
element to enable them to be presented remotely.   Control would be
implemented through the <video> or <audio> element (along the lines of
Anssi's proposal).
(3c) Expose the underlying mechanism for remote playback (Airplay, Cast,
uPnP) and assume a compatibility library can be built that abstracts over
the differences among them.

I believe that one of these approaches will pan out, and I would feel
comfortable leaving generic media playback in scope of the charter.

Also, for Cast, we have shown a good uptake of our generic media player
application that essentially allows sites to send a video URL to Chromecast
and control playback without having to write a custom application for the
device.  So there is some demand for this functionality. [1]

m.

[1] https://developers.google.com/cast/docs/receiver_apps#default "Default
Media Receiver"



On Tue, May 20, 2014 at 9:51 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Tue, May 20, 2014 at 9:23 AM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>>
>>
>> On 5/20/14, 8:57 AM, "Mark Watson" <watsonm@netflix.com> wrote:
>>
>> >Sent from my iPhone
>> >
>> >> On May 20, 2014, at 5:20 AM, "Kostiainen, Anssi"
>> >><anssi.kostiainen@intel.com> wrote:
>> >>
>> >> Hi Louay, MarkF, All,
>> >>
>> >> On 20 May 2014, at 11:56, Bassbouss, Louay
>> >><louay.bassbouss@fokus.fraunhofer.de> wrote:
>> >>
>> >>>> -----Original Message-----
>> >>>> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
>> >>>>
>> >>>> I feel media-specific control functions are out of scope for the API,
>> >>>>and I'd
>> >>>> expect such functionality will be provided by JavaScript libraries
>> >>>>build atop
>> >>>> the API.
>> >>>
>> >>> I am not sure if we could provide an abstract function in the
>> >>>Presentation API that can be used from  JavaScript libraries build atop
>> >>>to control the content. Since the Presentation API abstracts away from
>> >>>technologies used behind, the control part needs also to be abstract.
>> >>>There are two abstraction options in my point of view:  The first
>> >>>option is to specify control functions for each content type and the
>> >>>second option is to offer a messaging channel to the rendering service
>> >>>on the second display: in this case additional information about the
>> >>>communication protocol are needed (if Airplay --> exchange Airplay
>> >>>Messages, if UPnP --> exchange UPnP messages). first option is hard for
>> >>>specification and second option doesn't fit with our API design and
>> >>>Security requirements.
>> >>> @MarkA: Google proposed this feature could  you please give a short
>> >>>example how to control e.g. video content?
>> >>
>> >> Loya - here¹s a bit more elaborate explanation that hopefully
>> clarifies.
>> >>
>> >> MarkF - does this align with your thinking?
>> >>
>> >> In order to be able to use "common web technologies for messaging
>> >>between the authorized pages and the web content shown on the secondary
>> >>display² the URL we pass to the requestSession() or requestShow() must
>> >>point to a document that is transmitted with the text/html MIME type and
>> >>can be processed as an HTML document by either:
>> >>
>> >> 1) the initiating User Agent, or
>> >> 2) the remote User Agent
>> >>
>> >> It is up to the initiating User Agent implementation to decide whether
>> >>it should process the HTML itself or delegate the task to the remote
>> >>User Agent.
>> >>
>> >> For example, if the remote device (e.g. a display connected via HDMI)
>> >>is not able to understand HTML, then the initiating User Agent will
>> >>process the HTML document, render the HTML, convert the rendering into
>> >>video, and send it to the remote device for display.
>> >>
>> >> After either (1) or (2) has fetched and parsed the HTML document, an
>> >>in-memory representation (i.e. the DOM) of the HTML document is created,
>> >>and Web APIs can then be used to interact with this in-memory
>> >>representation. For example, to communicate with the initiating page,
>> >>control playback of the embedded media etc.
>> >>
>> >> The HTML document (foo.html below) may embed video, audio etc.
>> >>(<video>, <audio>) or other application-specific media (<object>,
>> >><embed>).
>> >>
>> >> The HTML spec specifies how to process HTML documents, embed media and
>> >>so forth. Similarly, there¹s a spec for web messaging we may reuse
>> >>and/or extend. We don¹t need to respecify those aspects in this API.
>> >>
>> >> In other words, the API would support:
>> >>
>> >> requestSession(Å’http://example.org/foo.html');
>> >>
>> >> Where foo.html is as follows:
>> >>
>> >> <!DOCTYPE html>
>> >> <html>
>> >> <head>
>> >>  <title>Foo</title>
>> >> </head>
>> >> <body>
>> >>  <video src="http://example.org/foo.mp4² autoplay></video>
>> >> </body>
>> >> </html>
>> >>
>> >> [ In a real-world scenario, you would likely implement also your own
>> >>media-specific control functions and use web messaging. For a primitive
>> >>example, see:
>> >> http://webscreens.github.io/presentation-api/#video-and-image-sharing]
>> >>
>> >> For MIME types other than text/html the API would fail. For example,
>> >>the following would not work:
>> >>
>> >> requestSession(Å’http://example.org/foo.mp4');
>> >>
>> >> ... as this would require us to expose implementation details of
>> >>connection technologies as you noted in order to be able to control the
>> >>content.
>> >>
>> >> All - do you agree that what is described above is a reasonable scope
>> >>for the API?
>> >
>> >No. User Agents should be able to support protocols such as DIAL
>>
>> The proposal that the URL always references an HTML document does fit
>> within DIAL, doesn¹t it? It just presumes there is only one type of DIAL
>> app that can be launched, a browser, which is implicitly identified by the
>> URL that references an HTML page. This approach resolves the desire raised
>> previously to only display availability of secondary devices that support
>> the desired app; there is only one app - a UA.
>>
>
> ​This is where I disagree, since there are millions of deployed DIAL apps
> that are not capable of rendering arbitrary web content and we would like
> this API to be able to be used by web pages to communicate with them​
>
>>
>> > which
>> >enable discovery of apps on remote devices which are capable of
>> >rendering particular content types or services. In such a case the UA
>> >can hand off rendering of URLs that do not resolve to html documents
>> >to such apps.
>>
>> So in this case, the URL is identifying an application and, potentially, a
>> media item? The discovered second screens displayed to the user should
>> then only be the ones that support the application, right?
>>
>
> ​Yes.
>
> ...Mark​
>
>
>
>>
>> Bob
>>
>> >
>> >The messaging protocol with such an app would be app-specific, but
>> >this is no different than the case of one web page communicating with
>> >another rendered on a remote UA.
>> >
>> >...Mark
>> >
>> >>
>> >> Thanks,
>> >>
>> >> -Anssi
>> >
>>
>>
>


-- 
http://wiki/Main/OnlyCheckEmailTwiceADay