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

Hi Dominik,

MarkS said it as well as I could.

Regarding NSD, we seem to agree this is inappropriate for the open web - or
at least unlikely to be implemented in that context. But the use-case we
are discussing is certainly appropriate for the open web, so a different
API is needed.

I didn't understand your comment about this use-case being out of scope for
the proposed Working Group: the scope of a Working Group is defined by its
charter, which is exactly what we are discussing now. Unless there is some
'meta-scope' I'm unaware of. I'm not proposing a new use-case after all -
just asking that a likely UA implementation of the 'flinging' use-case be
supported by the API.

...Mark

Sent from my iPhone

On May 27, 2014, at 5:27 PM, Mark Scott <markdavidscott@google.com> wrote:

Hey Dominik,

Re-iterating why these devices are meaningful - there's many tens of
millions of Smart TVs, and projected to be >100M (if we're not there
already) that support streaming content via specific built-in apps.  Pretty
much every connected TV you find on store shelves today fall into this
category.  Very few support handling arbitrary video streams without
additional peripherals.  Also, for a given piece of content, rendering
locally and then streaming an encoded version of that content is much more
demanding (on both the sending UA and on Wi-Fi), and generally results in
lower quality than leveraging the built-in player for that content.

I think we should talk concretely about what's actually being asked from an
API perspective.  All I think is being requested is that the site should be
able to provide the URL* to be presented in advance, so that
*displayAvailable* and *ondisplayavailablechange* can reflect ability to
present the stated URL.  How UAs make this determination doesn't need to be
defined by the Presentation API.  For UAs and displays that support all
URLs, this filtering operation is a no-op.

Content type negotiation is a separate issue, IMO.  Ironically it is *less
of an issue* for these custom players, because if they advertise support
for "netflix.com/*" you can be fairly sure that anything in the Netflix
catalog can be played.  By contrast, "web content" especially when it comes
to video could still be some mix of H.264/VP8/HEVC/VP9 video with
AAC/Vorbis/Opus/MP3 audio, with or without EME, and with or without MSE;
you sometimes won't know it works till you try.

Mark.

* or perhaps list of candidate URLs, but this isn't central to the high
level discussion.


On Mon, May 26, 2014 at 5:37 AM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> Hi MarkW,
>
> Thank you for the additional explanations and follow-up. It’s good to have
> this engaging open discussion. I’ll try to make the thread a bit more
> concise and summarise, please correct me if you feel the core ideas are
> incorrectly summarised:
>
> 1) You’d like the information about whether screens are available be
> specific to an URL scheme or a content type to match specific player apps
> on the second screen side.
>
> 2) You suggest to interface with a wider set of remote players/devices,
> not only those that would be a user agent rendering web content and those
> that would understand to playback a video stream that the initial UA sends
> them? For example, a YouTube.com<http://YouTube.com> or a Netflix
> specific player app that receives a content identifier of some sort. And
> you suggest to enable a custom type of communication to such players.
>
> However, I don’t see any new solutions to the content-type specific
> negotiation issues that I explained before. It’s a risk to the success of
> the specification that we as a group try to produce if in our first
> iterations developers are left alone with sorting out such compatibility
> trouble. The developer would figure out what content formats to provide and
> what protocol to speak, instead of a simple API that allows to use familiar
> web content authoring and communication methods.
>
> Also, I have not seen a device that would only have such custom player
> apps, but would not support a protocol or method to send it a pre-rendered
> video stream of web-content, or render such web content itself and could
> support web-messaging like communication. If you feel there is a large
> share of such devices and we can come to an agreement in the group that we
> want to support these, please let us know which devices you have in mind.
>
> NSD provides raw access to the discovery protocols alone. As I mentioned,
> it seems unlikely to gain wide traction because of the security and privacy
> issues. We need something much higher level like the Presentation API.
>
> The use cases for NSD describe not only the discovery, but also
> communicating with the advertised services, once they are found. Exactly
> what you seem to be looking for, from:
>
> https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#use-cases-and-requirements
>
> • Web pages should be able to communicate with Local-networked Services
> using the messaging channel supported by those Devices.
>
> • Web pages should be able to communicate with Local-networked Services
> using the messaging format supported by those Devices.
>
> I would strongly agree with you that we need something higher level, and I
> am convinced, this would also be more developer friendly and simple. We
> should avoid overlap to the scope of NSD, for its known privacy and
> security concerns.
>
> I’d like us to focus on the core idea of the community group: Bringing web
> content to nearby secondary screen, by asking what is the minimum spec and
> what are the minimum technical requirements we would need to enable that?
>
> We digress from this focus if we try to enable any type of communication,
> to any player software for enabling any custom content that such players
> may support, which I find similar to your suggestion 2). NSD is the way to
> do that, and it would certainly work well in a SysApps context, but as far
> as we can see from the discussion on blink-dev maybe not as an API that’s
> exposed on the open web.
>
> To summarize, presupposing I interpreted your points 1+2 correctly, what
> is proposed seems to be out of scope for the Working Group.
>
> That said, that is definitely something interested parties should continue
> experiment in this Community Group, and bring to the standards track when
> the ideas are more thought out.
>
> Regards,
>
> Dominik
>
>