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

On Fri, May 30, 2014 at 6:05 AM, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

> Hi Anssi,
>
> > -----Original Message-----
> > From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> > Sent: Freitag, 30. Mai 2014 14:52
> > To: Bassbouss, Louay; mark a. foltz
> > Cc: Francois Daoust; public-webscreens@w3.org; Mark Watson; Mark Scott;
> > Rottsches, Dominik; Bob Lund; Philipp Hoschka; Daniel Davis
> > Subject: Re: Requesting display of non HTML content (was: Draft of Second
> > Screen Presentation Working Group Charter available)
> >
> > Hi Louay, MarkF, All,
> >
> > On 30 May 2014, at 12:24, Bassbouss, Louay
> > <louay.bassbouss@fokus.fraunhofer.de> wrote:
> >
> > [...]
> >
> > > I like this proposal, this solves the media control issue by using
> > HTMLMediaElements and opens the door for using existing APIs like
> > MediaStream API, FileSystem API for accessing offline files, etc.
>  without the
> > need to touch the Presentation API spec.
> >
> > Louay - thanks for your support.
> >
> > Yes, that is exactly why I think reusing the existing building blocks
> makes
> > sense. Personally I feel this strikes the right balance. The proposal
> allows us
> > to reuse not only media controls, but also network state, ready state,
> > playback state of media as well as other goodies already defined by the
> > HTMLMediaElement.
> >
> > I also feel this is the abstraction level web developers are familiar
> with. We
> > must strive to make the API ergonomics as good as possible.
>

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.


> >
> > >> Obviously, canvas could be piped to a secondary screen similarly, but
> > >> I stop here.
> > > Actually you can adapt it to any DOMElement ;). This is what I already
> > proposed sometime at the very beginning of the CG discussion.
> >
> > That is definitely an interesting proposal, but I suggest we keep the
> scope we
> > have currently for the v1 spec ("the web content may comprise HTML
> > documents, web media types such as images, audio, video, or application-
> > specific media"), that is, concentrate on the HTMLMediaElements and the
> > HTMLImageElement initially.
>
> Completely agree
>
> >
> > Extending this to any HTMLElement would make an excellent experimental
> > extension spec I think, that could be worked on in the Community Group
> > first.
> >
> > MarkF - what do you mean by the "application-specific media"? Does it fit
> > into this model? That concept was landed into the draft charter as part
> of
> > your charter update [1].
>

"Application-specific media" meant content whose type was known to the
controlling page and the rendering agent, but not necessarily to a generic
HTML5 browser.  The scenario that has been brought up for this are "apps"
in a context like Google Cast [1] or DIAL [2] but it could be a PC native
application, Steam game [3], or other media that is not a standard
video/audio/image container and may not be HTML.

[1] https://developers.google.com/cast/
[2] http://www.dial-multiscreen.org/
[3] http://store.steampowered.com/

I can try to elaborate this a bit in the charter if it would be helpful.

m.

 >
> > >> IOW, we reuse the machinery already defined in the HTML spec for
> > >> media elements.
> > >>
> > >> All - WDYT?
> >
> > Thanks,
> >
> > -Anssi
> >
> > [1]
> > https://github.com/webscreens/charter/commit/472889d830730b34d116d7c
> > 61fe94f9433217dcb
>
>