Intent to Implement: Remote Playback API

[Anton Vayvod]

Contact emails

ava...@chromium.org, mlam...@chromium.org

Spec

w3c.github.io/remote-playback

Summary

The goal of the Remote Playback API is to let websites use HTMLMediaElement to load, play and control media on a remote playback device (e.g. an HDMI stick, smart TV, wireless speaker).

Motivation

We are working on the specification within the Second Screen W3C working group [1]; we want to implement this API so that potential users can experiment and help us iterate on the spec. The API will allow developers to play media remotely without the complexity of the Presentation API and also expose the existing default behavior of most mobile and some desktop browsers to the websites. An advantage of the Remote Playback API over the Presentation API is that by narrowing the use case the messaging (media commands) becomes easier to standardise and more devices could be supported. It could also become a standard version of Apple’s existing prefixed API [2]. We have a full list of behaviors and use cases at [3].

Compatibility Risk:

* Backward compatibility risk doesn’t exist since this is a new API.

* Mozilla agreed with the use cases and is interested in the API but has no immediate plans to implement it. See the minutes of the second day of the Second Screen WG F2F meeting at TPAC last year - [4].

* Apple showed interest and is participating in the discussion via GitHub [5]. They have a similar proprietary API and said they would be interested in the standard API if it matches the use cases of their prefixed API.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android and Android WebView)?

All but WebView as it would require Android framework API changes to allow embedding apps provide the necessary UI.

OWP launch tracking bug?

https://bugs.chromium.org/p/chromium/issues/detail?id=578833

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5778318691401728

Requesting approval to ship?

No.

[1] https://www.w3.org/2014/secondscreen/

[2] https://github.com/w3c/remote-playback/issues/1

[3] https://github.com/w3c/remote-playback/blob/gh-pages/use-cases.md

[4] https://www.w3.org/2015/10/29-webscreens-minutes.html#item01

[5] https://github.com/w3c/remote-playback/issues/5

[Rick Byers]

Sounds very cool, thanks!

On Tue, Feb 23, 2016 at 12:15 PM, Anton Vayvod <ava...@chromium.org> wrote:

Contact emails

ava...@chromium.org, mlam...@chromium.org

Spec

w3c.github.io/remote-playback

Summary

The goal of the Remote Playback API is to let websites use HTMLMediaElement to load, play and control media on a remote playback device (e.g. an HDMI stick, smart TV, wireless speaker).

Motivation

We are working on the specification within the Second Screen W3C working group [1]; we want to implement this API so that potential users can experiment and help us iterate on the spec. The API will allow developers to play media remotely without the complexity of the Presentation API and also expose the existing default behavior of most mobile and some desktop browsers to the websites. An advantage of the Remote Playback API over the Presentation API is that by narrowing the use case the messaging (media commands) becomes easier to standardise and more devices could be supported. It could also become a standard version of Apple’s existing prefixed API [2]. We have a full list of behaviors and use cases at [3].

Compatibility Risk:

* Backward compatibility risk doesn’t exist since this is a new API.

* Mozilla agreed with the use cases and is interested in the API but has no immediate plans to implement it. See the minutes of the second day of the Second Screen WG F2F meeting at TPAC last year - [4].

* Apple showed interest and is participating in the discussion via GitHub [5]. They have a similar proprietary API and said they would be interested in the standard API if it matches the use cases of their prefixed API.

This bit is very promising!  When another vendor has real shipping experience with a proprietary API we should try to make the standard design process more efficient by using what has already shipped elsewhere as a baseline and incorporate the lessons learned from it.  I.e. all else being equal, resolve debates by trusting the opinions of the vendor who already has experience shipping an API to support the use cases.

[rek...@gmail.com]

Hi. this is a a super interesting API. I'm concerned though that as a browser implementor, there's no way for me to implement this without creating my own proprietary specification. That seems outside of the scope of the Remote Playback spec, but is vital to this being a useful specification.

What kind of implementations is Google going to ship for talking with devices? Will Google support any well known device control protocols, such as DIAL or the reverse engineered Chromecast CASTV2 specification or Miracast? Who will be able to build devices that consume this "Intent to implement"'s work?

[Anton Vayvod]

Hi!

On Fri, Feb 26, 2016 at 12:33 PM, <rek...@gmail.com> wrote:

Hi. this is a a super interesting API. I'm concerned though that as a browser implementor, there's no way for me to implement this without creating my own proprietary specification. That seems outside of the scope of the Remote Playback spec, but is vital to this being a useful specification.

What kind of implementations is Google going to ship for talking with devices? Will Google support any well known device control protocols, such as DIAL or the reverse engineered Chromecast CASTV2 specification or Miracast? Who will be able to build devices that consume this "Intent to implement"'s work?

On Android we can simply use Android's MediaRouter framework [1] which will support at least Cast, maybe Sonos for audio and any other MediaRouterProvider installed in the user system.

On desktop an analog of Android's MR is being built into Chrome for the Presentation API which will at least support Cast, I'm not sure about other protocols supported (e.g. DIAL, Miracast, etc). [2] The plan is to extend the MR to support Remote Playback API so that the protocol support is shared between the two. 

Note that Google doesn't have to reverse engineer its own Cast protocol you mention.

The Second Screen Working Group is going to discuss an interoperable protocol at the next face to face meeting later this year. We don't have a definite plan yet though. There's an interoperability document used to initiate the conversation [3]

[1] http://developer.android.com/guide/topics/media/mediarouteprovider.html

[2] https://www.chromium.org/developers/design-documents/media-router

[3] https://github.com/w3c/presentation-api/blob/gh-pages/interoperability.md

[rek...@gmail.com]

It's super disappointing to me that Google is developing a "web platform" that no one else will be able to interoperate with. Chrome serving as gatekeeper to a proprietary ecosystem of Chromecasts and closed source, no protocol Android devices seems like a subversion of what the Web is: a place where people can implement and interoperate. Just exposing some common JavaScript APIs but keeping everything else under lock and key- as seems to be the Intent to Implement here, and as Push API works- is the opposite of the open, extensible web- it doesn't deserve to be called web technology at all, in this form.

[Michael van Ouwerkerk]

On Mon, Feb 29, 2016 at 4:53 PM, <rek...@gmail.com> wrote:

It's super disappointing to me that Google is developing a "web platform" that no one else will be able to interoperate with. Chrome serving as gatekeeper to a proprietary ecosystem of Chromecasts and closed source, no protocol Android devices seems like a subversion of what the Web is: a place where people can implement and interoperate. Just exposing some common JavaScript APIs but keeping everything else under lock and key- as seems to be the Intent to Implement here, and as Push API works- is the opposite of the open, extensible web- it doesn't deserve to be called web technology at all, in this form.

For the Push API we have designed a standardized protocol at the IETF [1] in collaboration with other vendors. I think we have followed through on the intentions we set out in our intent to ship [2].

[1] https://datatracker.ietf.org/wg/webpush/

[2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/UdGlL9PtBLo/HOZZ4sjV-QkJ

Regards,

Michael

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[rek...@gmail.com]

Wow, that's an amazing turn around from where the Push API was when it initially got implemented! ++, great job! Many thanks for sharing that; it drastically alters my perspective & outlook. And congratulations on shipping such a great feature, rooted so nicely in inter-operating standards.

Also thanks for the links to the inter-operation assesment for this feature. It's a lot more encouraging to see in light of seeing Push API's nice bringing about, and I suppose I personally can feel a lot more easy about this Intent to Implement- onerous as it feels with no underway standards for interoperation present- in light of the efforts Google went to to set Push API right.

Thanks for your persistent replies. I hope this turns out well- feeling a lot more like that could happen now, thanks to Michael + Anton's kind replies.

[Rick Byers]

rektide@ thanks for raising your concerns and the follow-up!  Bringing features with deep platform integration to the web is challenging (especially when all underlying platforms don't share the same goals as the web), and there will always be some tradeoffs to be made in terms of incremental enhancement and achieving the vision of full interoperability.  

Adding new features like this in a way that effectively pushes the web forward while maximizing the chance of long-term interoperability is the primary problem our intent process is designed to navigate, and the concern most top-of-mind for us API owners.  Our goal is to improve the entire web platform (not just chromium-based browsers), so it's important we continually iterate on how we navigate the tradeoffs here.  Feedback from the community is essential to the process, so keep the feedback coming!

Like you, I'm optimistic that the experience with push suggests there's a similar incremental path for remote display.  It'll be tricky and may not ultimately go as well as we'd hope.  But as long as the folks involved are committed to trying to achieve full long-term interoperability based on open standards, then I'm inclined to support quick incremental progress - starting with the parts that are most tractable.  The biggest enemy to the effective evolution of the web platform are large inter-dependencies in API design.  We only break those dependencies by finding a constant stream of useful bite-size chunks to ship piecemeal, where we can learn and iterate at each step along the way.  It's messy and imperfect, but in an open platform like the web, it's far better than the alternative of perpetual indecision :-)

Thanks,

   Rick