Thoughts on the Chromecast

I’d love to get a bunch of those, but not for the reasons most people would think.

I’ve been tinkering with digital signage (after a fashion) for a year now (it’s been my little side project at work, with great results at Codebits last year), and the Chromecast hardware seems perfect for the most common use case – i.e., playing videos on large screens.

We’ve been using Raspberry Pis for that (and rendering web-based status boards) at the office for a long while, but that has a number of issues:

• They’re too unreliable by my standards (even with various degrees of paranoia coded into our custom client and swap disabled, I have to re-image corrupted SD cards every couple of weeks or so).
• Even with the watchdog timer enabled and running the latest firmware, the things still crash and lock up mysteriously (often causing SD card corruption).
• Without a decent browser rendering pipeline, it’s simply too slow for rendering many web pages (hence my having fiddled with streaming a live desktop to it and setting it up as a bare-metal RDP client).
• The boards are still a tad too big to mount unobtrusively in some situations (and they have lots of bits sticking out).
• We can’t stream our laptops to them trivially for quick presentations.

This last bit has been a particular niggle of mine, especially since pretty much every modern TV has some form of UPNP support that just sits there unused. A desktop PC can stream video to literally hundreds of clients depending on refresh rates and overall quality (streaming a full-screen browser is a no-brainer, and takes up very little bandwidth), and this is, after all, the XXIst century, so why haven’t we figured out a universal standard for doing presentations wirelessly yet?

So up to last week I’ve been looking for ways to implement something like AirPlay mirroring (which is a shady deal at best, but entirely feasible).

The trouble with most solutions so far is that you need some sort of client software, which is a major pain.

But the Chromecast’s browser integration should (mostly) fix that – albeit with another, equally proprietary and fiddly protocol, but a much more widely available client.

And in a world where 90% of most people’s work eventually gets rendered on a browser, putting a Chromecast dongle in every meeting room is a no-brainer (even if some form of adapter might be required).

I’ve been fiddling with a couple of Android HDMI dongles in an attempt to fix all of the above, but every single hardware and firmware combination I tried was too iffy to consider deploying, and thanks to high-pressure, throwaway hardware design cycles it’s pretty damn near impossible to find an ubiquitously available, cheap and minimally open platform. Ironic, I know.

But the Chromecast is almost perfect – even if Google, in their characteristic US-centric way, has yet to emit more than vague noises regarding selling it worldwide – by which I mean “including Portugal”, of course.

Looking at the publicly available source code, using the Chromecast for digital signage should be trivial – the thing uses SSDP for discovery, the basic protocol seems easy enough to implement/clone/spoof, and there’s even a barebones, Python-based emulator already – which, obviously, runs on a Raspberry Pi. Well, at least it’s already crashing on mine¹.

The devil, of course, is in the details. There’s still a fair amount of work to be done (and likely a fair amount of network tweaking) to design a signage system that can manage a bunch of Chromecast dongles and still allow for ad-hoc presentation use, but I’m positive it can be done.

Obviously, I need to get my hands on one first – so if you’re sitting in one of these offices reading this and can help me with that, feel free to drop me a line. There seems to be a fair amount of legalese involved in developing for it, but I’m game, and have a couple more ideas for it besides this.