Inside Chromecast

Inside the Chromecast it’s also a simple affair, I took a look at the FCC disclosure for the Chromecast which had internal images up right after the event, and noted inclusion of a Marvell 88DE3005 SoC and AzureWave NH–387 WiFi combo chip. On the backside is 512 MB of Micron DDR3L memory and 2 GB of flash. The antenna for the WiFi combo is printed on the PCB off to the side, there’s no diversity or anything special, just a single PCB antenna.

The Chromecast supports just 802.11b/g/n (2.4 GHz), sadly no 5 GHz is included. That’s somewhat alarming if you’re in an area where 2.4 GHz is congested to the point of being unusable (just about any major urban area), and even more so since streaming applications demand a good QoS for good experience. I have no doubt that 2.4 GHz-only was chosen for cost reasons here, but I would’ve gladly paid $5–10 more for 5 GHz and eliminating that as a potential problem.

Best I can tell, the Marvell 88DE3005 is a cut down, perhaps binned version of the 88DE3100 SoC that has shipped in Google TV for some time now with just a single CPU core enabled. Some hacking done by enthusiasts has confirmed from /proc/cpuinfo that only a single core is visible to the OS, and that the Chromecast also interestingly enough really runs Android, not Chrome, and includes a build.prop file like you’d expect an Android device to.

Google no doubt chose this Marvell SoC in part thanks to the presence of hardware VP8 decode, and I have no doubt YouTube on the device brings down VP8 versions of videos when available, and the Chrome tab to Chromecast streaming uses VP8 as well. Of course there’s hardware decode of H.264 High Profile onboard as well for Netflix and other YouTube videos without VP8 versions. Google lists the supported codecs on their Google Cast SDK page.


Under Load

Back when the power situation was unknown and still steeped in conflicting information about HDMI power delivery (again, it can't be powered by MHL-HDMI ports which can supply up to 500 mA at present spec, and HDMI doesn't supply enough current, just 50mA), I set about measuring power. I have a handy USB power meter which sits in line with devices and shows a small graph as well as data on its OLED display. I stuck the meter in line between the microUSB power supply provided with Chromecast, and the Chromecast, and measured around 420 mA at peak while decoding either a 1080p Netflix stream or Chrome tab streamed to it, and around 250 mA at idle. All of those are at 5 V, so at peak the Chromecast draws around 2 watts, at idle around 1 watt. Of course if the Chromecast is plugged into your TV’s USB port, chances are when the TV is off power is cut to USB, so idle really is completely off. It’s obvious to me that Chromecast definitely leverages that hardware decoder for both VP8 and H.264 processing to get these very low power numbers.

Introduction and Hardware The First Mode - Cast SDK
Comments Locked


View All Comments

  • MKBL - Tuesday, July 30, 2013 - link

    I'm confused. Right now I have a laptop with broken screen connected to a TV through HDMI. This setup handles most streaming efficiently, and I wonder if Chromecast will replace it with better efficiency. Maybe I'm facing my moment of being a tech-norant at age of 41, but I don't get the concept of the Chromecast. Does it receive all media data through laptop or tablet/smartphone that controls it remotely, or will it be streamed directly to Chromecast, which then decode it once the remote control - selecting channel/source, etc. ? If it is the former case, what is the difference between having a laptop connected and Chromecast connected to TV? I understand that the size is huge difference, and the price as well, but someone like me with extra laptop or media box like Zotac Z-box already, is there any benefit of having Chromecast? I'm not rejecting it, I am just confused.
  • savagemike - Tuesday, July 30, 2013 - link

    You will see no benefit.
    Chromecast uses both methods you describe. For the apps with it built in the controlling device is doing nothing but acting as a control channel. The content is streamed directly from the cloud source by the chromecast device.
    For the beta tab-casting feature using a Chrome browser on a computer - the source computer is encoding everything and streaming it to the Chromecast. It is actively mirroring it's content to the Chromecast itself.
    To the Chromecast device itself these thing are indistinguishable I imagine.
    In any event if Google could hand out laptops with no screens for $35 this would be an even more amazing product.
  • Wolfpup - Tuesday, July 30, 2013 - link

    Dumb question, but AppleTV basically does this same thing, but using OS X or iOS, right? Like Airplay can stream arbitrary content from OS X or iOS? (Though I guess not Windows?)
  • Sm0kes - Tuesday, July 30, 2013 - link

    Correct, this looks to compete directly with Airplay. I think the excitement around this stems from the fact that 1.) it's cheaper than anything airplay enabled 2.) and more "open" (as opposed to being locked to a single platform).

    Obviously, it'll take time for the developers and hackers to really dig in, but it's definitely a promising little device.
  • steven75 - Monday, August 5, 2013 - link

    It does a subset of the things ATV does, since ATV can:
    -Be used standalone without any other device
    -AirPlay local files from device-to-device (pictures/videos/apps)
    -Full 1:1 screen mirroring, no browser needed
    -Act as AirPlay receiver for multiple streams simultaneously (multi-room A/V)
    -More support from content owners: Hulu, HBO Go, MLB/NBA/NHL, etc

    Those things are definitely worth the extra $64 to me. YMMV.
  • matt30 - Tuesday, July 30, 2013 - link

    It seems that only the beta channel of Chrome has the option to share your entire desktop. You might want to test that.

    Also, I don't think the "second mode" as you called it, works purely over LAN. In part I think that's the source of the delay. Try casting a tab then cutting your internet. If I'm right the tab casting should stop despite the fact that there is still a LAN.
  • Sm0kes - Tuesday, July 30, 2013 - link

    Interesting. I can't imagine google would be encoding via the cloud?
  • matt30 - Tuesday, July 30, 2013 - link

    I'm sure the content is encoded locally but I suspect something funny might be happening with the routing.
  • savagemike - Tuesday, July 30, 2013 - link

    Why do you suspect this if you apparently don't have a unit to test it on?
  • matt30 - Wednesday, July 31, 2013 - link

    The latency and use of webRTC to transmit screen information.

Log in

Don't have an account? Sign up now