AirPlay vs ChromeCast: breakdown and differences

AirPlay vs ChromeCast: breakdown and differences

Original Article :: http://giovanni.bajo.it/post/60352255570/airplay-vs-chromecast-breakdown-and-differences

Last month, Google released ChromeCast, a "click-to-TV" dongle. Overall, it is similar to AirPlay (which has been the first consumer implementation of click-to-TV), but there are important differences. I'll try to break them down in this article.

First, remember that there are two important but strongly different protocols, that are similar in usage but totally different in implementation. 

• What Apple calls "AirPlay": it is used to send a pure video / audio stream from a sender (eg: a phone, or a computer) to a receiver (eg: a TV, or a computer). Technically, the sender sends a URL to a stream to the receiver, and the receiver starts streaming from that URL.
• What Apple calls "AirPlay Mirror": it means mirroring the screen of the sender (whatever it is display on it: an app, a game, a settings pane, whatever) to the receiver. This is done by encoding the screen of the sender into a continuous video stream that is then played by the receiver.

So, now to the full breakdown:

• Cloud vs local. ChromeCast is currently limited to streaming online contents. You can stream from YouTube, NetFlix, Google Music, and so on. On the contrary, AirPlay allows both cloud and local contents: you can use it to watch a video that you have downloaded or recorded on your iPad, or to see a photo slideshow. Will ChromeCast ever support local content? There was a rage of fury when Google blocked (through an automatic software update) a homebrew application that managed to play local content, but later Google did acknowledge that this might be allowed in the future. I can't see why it shouldn't, actually.
• Single-user vs multi-user. ChromeCast has been designed with the multi-user experience in mind. Any sender that talks to a ChromeCast receiver has access to information on the currently played stream, and the playing queue. Basically, it's like sharing a jukebox, where you can add to the queue songs with the friends. On the contrary, when a device sends a video to an AirPlay receiver, the receiver stops whatever is doing and follows the order. It feels like having two remotes for the same TV: the last wins.
• Platform compatibility. Google has announced that it plans to make ChromeCast multi-platform, and not bound to a specific producer/receiver. Right now, the choice is quite limited: only one model of Chromebook, no desktop Linux, only the Chrome browser, only the ChromeCast HDMI dongle. This notwithstanding, I am sure the offer will grow overtime. On the contrary, AirPlay is officially Apple-only, but it is actually  upported by a lot of devices (eg: Synology NAS) and Media Centers (eg: Plex and XMBC), thanks to the protocol being reverse-engineered in the past years. Even the Raspberry PI can be turned into a AirPlay receiver.
• Mirroring. ChromeCast has an experimental support for browser tab mirroring: it encodes one tab of the browser and sends it to the receiver. No support of mirroring from mobile phones yet; since it would require OS support, I guess it won't happen on iOS, but eventually it'll be there on high-end Android devices (not on 4.3 though). With AirPlay, you can mirror within the Apple device ecosystem (eg: mirror your iPhone to your Mac), and there is third-party support for mirroring to and from Windows as well.
• Hardware acceleration. For mirroring, hardware acceleration means being able to real-time encode a HD video stream without affecting the running application, and with a good latency (to avoid lag). Think of playing a game on a tablet; you really don't want your game to have less resources available because there is a CPU-driver encoding of screen being performed in background! The native AirPlay support on OSX and iOS uses 100% hardware acceleration for H264 encoding (in Mac, it's part of Sandy Bridge and newer chipsets, while for iOS it's present in newer models of iPhones and iPads). On the contrary, the choice of implementing the mirroring within Chrome (instead of at the operating system level) makes it probably harder to leverage hardware support in ChromeCast. A software solution obviously can have some advantages as well (eg: you can decide to mirror only a specific program or browser tab from your computer, a feature which is in fact only available in third-party software AirPlay Mirror implementations like AirParrot).
• Application support. Being integrated into iOS, AirPlay is supported by (almost) all applications that play media streams on iOS and Mac OSX. Basically, if you use the native video player widget, you've got transparent AirPlay support. The most important exception is generic video players implementing video codecs in software (eg: VLC playing a DivX movie). In fact, even if AirPlay as a protocol is codec-agnostic, most if not all AirPlay receivers only support H264, so even if you can technically push a DivX stream onto your Apple TV from VLC, it won't play. ChromeCast has wider codec support (not HUGE, but supports a few more options for sure), but is currently limited to Chrome and a few selected apps. Any other app willing to support ChromeCast must manually do it (that is, link its SDK, write and test the code, and release a new version); this means that it might take a while to see wide adoption. 
• Software customization. Besides playing a video or showing a copy of the screen, can applications leverage the technology in different ways? AirPlay Mirror on iOS allows applications to specify a different window (rather than the screen) to encode and send to the receiver. Some games use this API to show the main game screen on the TV, while giving a full-screen control pad on the phone. ChromeCast instead is fully customizable: the device runs a cut-down build of Chrome, and it is capable of displaying basic HTML5 (with some limits): in fact, the basic video support is just a simple html with a <video> tag, while mirroring is being done through WebRTC. Applications can send custom HTML fragments to the ChromeCast device (called "receiver apps"). I still don't know the exact limits of the cut-down browser, but it is surely looks like an exciting feature.
• Cost. The ChromeCast HDMI dongle is quite cheap ($35). As usual with Google's hardware, it's probably being sold at zero margin. The only AirPlay Receiver, the Apple TV, is much more expensive ($99), though it also has additional software features (specific apps for specific media channels, etc.) and hardware connectors (ethernet, in case Wi-Fi doesn't cut it; optical audio, in case you have an external Dolby/DTS decoder). Alternatively, a Raspberry PI can be used as a AirPlay video receiver, but the experience is not bug free.

My TL;DR: AirPlay is a more mature technology, with wider support, and is also quite supported in third-party software and hardware, even though it is an undocumented proprietary protocol. ChromeCast is very promising, cheap and theoretically more powerful, but it is a bit limited today.

Best regards,

Yuanda Xu