Remote Playback API is a new Web Working Draft

Right now users can use Google Chrome with the Google Cast extension to get a video from a website onto their TV. It may be a bit too specific, requiring a specific browser and additional software to be installed. This makes the casting ability less desirable to content providers, for whom this feature will only target a small demographic. Yet casting technology is pretty common today in smart TVs, whether the protocol is Miracast, AirPlay, DLNA, Google Cast, or simply plugging in an HDMI cable.

Each of these supports what’s called “Remote Playback”, the ability to queue a video from one device and start playing it on another. It’s something that has a lot of use cases, not just for videos, but audio and presentations. However, each technology is implemented differently and developers would have to inform users about different browsers and plugins to install as well as load additional code to handle each technology.

Remote Playback API

To aid this adoption, W3C (the World Wide Web Consortium), the organization responsible for creating web standards, has released the first public working draft of the “Remote Playback API“. This was formed by the “Second Screen Presentation Working Group“, whose participants include representatives from Intel, Google,
Mozilla, Apple, Netflix, other tech companies, and various telecoms.

This specification defines an API extending the HTMLMediaElement that enables controlling remote playback of media from a web page. It aims to make remote playback devices such as connected TVs, projectors or audio-only speakers, available to the Web and takes into account playback devices that are attached using wired (HDMI, DVI, or similar) and wireless technologies (Miracast, Chromecast, DLNA, AirPlay, or similar).

If you, as a web developer, already use best practices for displaying videos, then you shouldn’t have to do much additional work. As shown in the examples, the HTML video element will have an additional remote
property that can query for available remote devices and respond to changes in playback on these devices.

When will this be available?

When can you expect these APIs to be available? This is the first draft, so it will likely go through many revisions as the public get a chance to comment on this feature. Then, once this is published, browser vendors will be expected to add this feature into the product. Due to the slow adoption of new APIs in some browsers, this could take many years.

Don’t worry too much, as you likely won’t have to wait that long. To aid developers in adopting these features, there are often “polyfills”, JavaScript libraries that provide compatible features when they aren’t technically supported. Polyfills for remote playback will likely happen at some point. Also, some browsers may add support early as a way to test the APIs. Chrome and Firefox have been investing in TV with their company products, so it’s likely this will be added soon as a way to improve their products. (Google and Mozilla are also in the group.)

Are you a web developer? Do you think this is a good step in browser functionality? Let us know your thoughts in the comments below.

Nick Felker is a student Electrical & Computer Engineering student at Rowan University (C/O 2017) and the student IEEE webmaster. When he's not studying, he is a software developer for the web and Android (Felker Tech). He has several open source projects on GitHub (http://github.com/fleker)
Devices: Moto G-2013 Moto G-2015, Moto 360, Google ADT-1, Nexus 7-2013 (x2), Lenovo Laptop, Custom Desktop.
Although he was an intern at Google, the content of this blog is entirely independent and his own thoughts.