Chromecast - both cool and frustrating

Thu 21 August 2014 by Fred Clift

I recently purchased a Chromecast device. For the price it's a great media streamer. You can control it from your Android or IOS smartphone from many different apps. For chrome browser, you need to install a browser plugin. There are many websites that, when viewed in Chrome browser give you the option of casting the content.

By casting I mean, you tell the Chromecast device to load it's own special app and have that app directly stream the content. In Chromecast dev terms the app you tell the device to load is a 'receiver' app.

Youtube is a prime example. On your computer when watching a Youtube video, you find an extra button that allows you to send the video directly to your Chromecast device. This allows your Chromecast to directly stream the content, rather than needing your browser or smartphone in the loop.

You can also mirror the contents of any chrome tab and some android-devices to the screen. It takes a lot of bandwidth, but if you have a good network, the quality is good. (built on WebRTC)

There is a lot of clever magic going on behind the scenes to make all of this work on your home network. Initial setup for instance, is done by having the device create it's own wireless network, and having a setup program on your PC connect to the network and then to the device to talk to it directly.

Once it's set up, your devices find Chromecasts in the local network via Multicast DNS (... used to use DIAL/SSDP/UPnP ...) Some low-level code in the Chromecast API impelemntation, supported, at least in the Chrome browser takes care of sending IP multicast dns queries asking for any devices that will respond to the name _googlecast._tcp.local. All the responses are collected and cached.

Your Chromecast-api using app can then, at the user's request, contact any of the devices, ask the device to load a receiver app, and then establish a control channel to the app to tell it what media to load, to control playback, etc.

All the api communication with the Chromecast device is over ssl'd websockets.

Much more technical detail about how Chromecast devices work can be seen at Justin Loutsenhizer's excellent Github page, and at Sebastian Mauer's presentation.

Google is pretty uptight about the user-experience they will allow with published apps. See their Terms of Service. This agreement is what people who want to develop and distribute a Chromecast app must agree to to get their app usable by the general public. There is also the Google Cast Design Checklist and some User Interface guidelines.

I have some real problems with the terms of service. Some of it is understanable. Section 3.4.7 for instance is about user-data and privacy - common sense. Or, section 3.4.3 - don't encourage users to engage in high-risk activities... What I don't like are the terms that forbid exactly what I actually want to do with the device. 3.4.8 - must not automatically cast content, 3.4.1 - must not load arbitrary apps - only Google-Approved ones, 3.4.2 - don't allow usage of the device without the official API...

I wouldn't care (much) about being required to use only the official API if they would actually support a platform I cared about developing for. The three supported APIs are for Android, IOS, and chrome-browser apps. There is no native SDK/API for anything else.

What I really want? An daemon to run on my FreeBSD server in the basement, or on the family mac-mini that has access to the 60 Gig of family photos and home-videos, and to play random ones, if, and only if, the Chromecast device is on the home-screen. It would poll periodically to see if the device is busy, and restart showing photos if the device wasn't in use. I want it to start automatically, as a system service, find the device by name, and turn my tv into a giant digital photo frame.

Next post I'll talk about pychromecast, and the code I contributed that will let me make my dream a reality, while technically not violating Google's TOS.

refs, for me mostly: