« January 2014 | Main | March 2014 »

February 17, 2014

Feature Wishlist for Chromecast

It is official.  I'm sold on Chromecast.  The whole KISS (Keep It Simple Stupid!) concept seems to work out well.  Things are smooth with all the officially supported clients.  I have a 95% success rate with the Casting extensions running on the x86 release of Chromium on Linux.  For software that isn't officially supported, it really isn't that bad.

I hate to whine about something so simple, but this is the Internet and that is how we do things here.

Things that I would like added to the Chromecast in order of importance.

  • Ethernet Jack.  I know, I know, the future is wireless.  Tell that to my neighbor with a 2.4Ghz phone from a decade ago.  Things are streaming great and then *splat*.  Regular Youtube content just buffers, but it breaks the DRM on the content streaming from the Google Play Store.  Which brings us to...
  • Dual Band WiFi.  Actually this is probably cheaper than adding wired Ethernet.  In my neighborhood that 5GHz band is wide open and the 2.4GHz band is heavily utilized.  I can imagine in a high density housing situation like an apartment complex, dormitory or condo that it would be much worse.  
  • Ability to use local (network) media.  This is probably the most requested feature and I can see why you aren't giving it up easily.  The dongle is a loss leader for folks to use your services.   Even if you limited something like this to Google controlled hardware like Chromebook, I'd probably buy your hardware just to allow me the convenience.  I know you can cast a whole screen including the audio (which is in beta), but I'd rather have an experience similar to what Songza provides for the Chromecast, but with my local media. 
  • Application Partners that don't require a login.  I get it, Netflix, HBO to Go, Hulu Plus and the like are subscription services.  Pandora does both subscription and free models, but why should I have to authenticate with their site to cast their service to the Chromecast.  Songza has it right.  Redbull.tv has it right.  
  • Application Wrappers for Interested third parties.  An example would be a streaming audio site like SomaFM, which I enjoy.  If an API wrapper were to be created that would allow anyone who is a Google Adsense vendor to cast various application from their site, with Adsense taking 1/2 or 1/3 of the screen real estate for ads and the rest for the customer, it would be a win-win situation.  They would get revenue from the advertising, you (Google) wouldn't have to host the service or pay for the bandwidth and the content can be governed by the current rules of Adsense that doesn't allow it to be used for the purposes of explicit content. 
  • A bit more security.  You know that these things are going to be used to connect large projectors to laptops at conferences and conventions, right?  You made such a neat little product and people won't be able to help themselves.  God help the Hello Kitty convention that has some pervert blasting Goatse images or renaming the units with the iPhone client to objectionable words that get displayed on the idle screen. 
  • Digital Audio Out.  A minor thing.  Not all of us have upgraded our HiFi systems to do HDMI switching.  I take an optical output from my tv and run it into my surround sound setup.  Either a coax or toslink/fiber SPDIF output would be great, but you guys are probably saving that for some sort of set top box that will make us forget GoogleTV.

Most likely your marketing guys have already figured out this stuff, but if not feel free to bring Google Fiber to my street as compensation.

February 02, 2014

Chromecast on Linux

I was recently pondering purchasing a Google Chromecast unit to mess around with at home.  The price is so low that they are almost giving them away.  I assume that is so Google can harvest your viewing habits and resell them, but that is another story.  Originally I was thinking about using a Raspberry Pi unit with XMBC to do media streaming, but as cool as it is, I don't have the time to install, configure and train my family... even if it is way cooler and would give me way more geek cred.  While Minimum System Requirements for using the Chromecast includes most of the normal equipment to be found on my home network, it doesn't support Linux.  Now, thanks to the best (and in depth protocol) explanation from Paul Donahue on the AskUbuntu forum, I know that I'm covered with my Linux devices at home.  Now all is right with the world again.  Thanks again Paul, you made my day a little better.  Now if Google would officially support it as a product and not a beta, that would be cool.

Screen Capture Edit/Addition: I actually wrote this a few weeks ago but never ended up publishing it.  Since then I've bought two Chromecast units to hook up to various TVs around the house.  I would rather have a direct Ethernet connection to them, but they never skip and you really can't beat the price.  I mainly use Ubuntu 13.10 with Chromium to cast content to the Chromecast units, but my kids use the iPad client and it is seamless.  Sometimes less is more.







Source from AskUbuntu:


The documentation from Google indicates that the Google Cast extension is not supported in Linux, but it actually does work.

To get this working in Ubuntu:

  • Make sure you are running either Chromium or Chrome version 28 or higher. Earlier versions will get a "This application is not supported on this computer. Installation has been disabled." error. The 'chromium-browser' package in Ubuntu 13.04 works fine.

  • Make sure iptables is configured to allow the UPnP/SSDP traffic used by the Google Cast browser extension to discover the ChromeCast device.

    The browser will send a multicast UDP packet from the local IP and an ephemeral (random) port to port 1900. The ChromeCast device will respond with a unicast UDP packet from the ChromeCast device's IP and another ephemeral port to the source IP/port of the multicast packet. Note that this is slightly different than most other UPnP devices, which will usually respond with a unicast UDP packet from port 1900 instead of an ephemeral port.

    The typical iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT rule WILL NOT match the response packet, as iptables does not currently have a conntrack helper that supports SSDP. In addition, the iptables -A INPUT -p udp --sport 1900 -j ACCEPT rule typically used for UPnP/SSDP will not work since the replies from the ChromeCast device do not come from port 1900.

    Therefore, you will need to add a rule to accept UDP packets on all ephemeral ports. The ephemeral port range for the initial multicast packet should be 32768-61000 (Verify with cat /proc/sys/net/ipv4/ip_local_port_range), so the following rule should work:

    iptables -A INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT

    After the ChromeCast device has been discovered (each time the browser starts), the browser will control it using TCP (HTTP) connections to port 8008, which should not require any special iptables rules.

  • Install the Google Cast browser extension in either Chromium or Chrome. Note that an app/extension called ChromeCast is available, but this is not what you want.

  • If you have not yet set up your ChromeCast device, follow the instructions that come with the device to set it up.

  • Once your device is configured, you should be able to simply click the Cast button in Chromium to Cast your current tab.