Developing for the Chromecast – Part 1: Context

Developing for the Chromecast – Part 1: Context
oktober 28, 2013 erik.lupander@squeed.com

This will be a series of blog posts with the purpose of explaining how to develop applications for the Chromecast.

chromecast

Part 1: Context (this post)
Part 2: The programming model
Part 3: HipstaCaster example. Receiver app
Part 4: HipstaCaster example. Android Sender app

Please note that the Google Cast SDK is a developer preview which is subject to change before it’s final release. Read more about it here.

For those of you that have missed Googles summer launch of the Chromecast device and what it is, I can refer you to Google’s own page about the device. If you’re into a bit more detail about how it relates to stuff like the AppleTV, Plex, XBMC and other (sort of) similar solutions, I’ve written a short summary.

General overview
The Chromecast is more or less a slightly pimped Chrome Web browser embedded into an HDMI-stick. It offers two ways to present content on your TV:

  1. Mirroring a Google Chrome Tab running on a Windows or Mac, having the requisite Chrome-plugin installed. By mirroring, this solution refers to actually encoding the graphical content of the web browser tab into a media stream sent over to the Chromecast using WiFi. This is pretty similar to what AirPlay och Miracast offers. Technically, this mirroring seems to be using WebRTC and VP8 for encoding the video stream. The advantage of this mode of operation is that anything* you can display in a Chrome tab, you can cast over to your TV. The downside is that it takes some muscle on your PC/Mac to do the actual encoding of the video stream, the resolution is limited to 720p, a good WiFi network is required and that the final result still may suffer from frame drops and slight lagginess. Currently, it is not possible to cast a Chrome Tab from Android or iOS. (Linux is not supported, buy may very well work anyway.)
  2. Sender / Receiver mode. This is what I would refer to as the main mode of operation. Your app (an Android, iOS or Chrome app) starts the Chromecast device by sending a unique API key to it. The Chromecast looks up the URL mapped to the key and loads and displays a HTML5 web application specific to the app’s service provider from the internet, for example YouTube or Netflix. You then control this application directly from the app, browsing content and selecting what you want to cast to the TV. The actual casting here does not actually happen over the phone/tablet/computer, it just tells the HTML5 application to start playing a video stream from some URL. Technically, this model is quite similar to the DIAL protocol. See the image below for Googles own view on how things fits together.

* Video Streaming services based on Microsoft Silverlight seems to have some copy-protection or similar scheme that makes it impossible for the Chrome Cast plugin to read the video stream. The video portion of the image cast over to the TV is just black. Flash- and HTML5-video based services works fine.

The (Sender/Receiver) model is what these blog posts will be about. I will describe how to get started developing, debugging, building a receiver app and building an Android-based sender app.

So, how does all of this fit together from a software development perspective? As already mentioned, one makes a distinction between the Sender and the Receiver. In the image above, you have the Sender bottom-left and the Receiver bottom-right. Those URLs directs you to Googles own Developer’s Guide. A Sender Application is either run in a image_5Desktop Chrome browser with the Google Cast plug-in, or as a Android/iOS app. The Receiver Application is always a web-based application loaded from a whitelisted URL using HTML, Javascript and CSS for it’s presentation and interactivity.

Uhm… whitelisted?

Whitelisting
For good or worse, Google has decided on a slightly different path for allowing 3rd-party applications to be run on Chromecast devices. As already mentioned, the Chromecast unit loads the HTML5 application from an arbitrary URL, based on the API key provided by the sender application. This actual lookup table is provided by Google, who will add key-to-URL mappings when they for whatever reason think your solution is good to go. So, yes – Google will be controlling which services that will be available to run on the Chromecast device. For example, Google has included some quite extensive usability and design guidelines I assume they want services to adhere to.

However, anyone can apply for whitelisting of their personal Chromecast unit for development purposes, providing Google with up to four URL:s your device will be able to access for loading its Receiver app. This includes 192.168 addresses, so it’s easy enough to develop something internally. It took me about 4-5 days to get my own Chromecast whitelisted for development.

In the next part of this blog series, we’ll be taking a closer look at the programming model and setting up a development environment with some IRL tips&tricks thrown in. Stay tuned!

1 Kommentar

  1. Marc Bellario 3 år sedan

    very impressive tutorial – I believe – the best I’ve seen – on chrome/google
    cast – which is kind of involved ? I would say…. some fine work – but I’ve
    not tried making it work – yet …

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *

*

Denna webbplats använder Akismet för att förhindra skräppost. Läs mer om hur dina kommentarsuppgifter behandlas.