I'm still really disappointed that the Cast protocol is effectively closed, and Google only supports casting from Chrome, Android, and iOS.
I think Google is really shooting themselves in the foot regarding adoption. I'd love to have a command-line Cast client for Linux, integration into pulseaudio, a Firefox Cast extension, a native UI (non-browser) video player, etc. Sure, some people have reverse-engineered the newer protocol, but I've never gotten any of the unofficial clients to work reliably (and some just flat-out don't work at all).
Google's not shooting themselves in the foot because:
- Google Cast is not a general-purpose streaming protocol, even though it is designed to mimic that UX to a casual user
- Cast provides some features like 'ad breaks' [1] that are valuable to content providers and aggregators which you wouldn't find in a general-purpose streaming protocol, making it more likely that those who want these features will make their streaming app Cast-compatible
- The Cast SDK comes with a TOS [2] that's a rather enlightening read
- You have to register your application with Google if you're developing a Cast sender [3], or if you're developing a Cast receiver and don't want to use their Default Receiver [4] (presumably, because you're building your own).
Google's building an ecosystem here. This isn't Miracast or WiDi or even AirPlay, although kudos to them for making everyone think so.
> you must take appropriate steps to ensure that your application cannot be invoked to launch content for which you are not responsible
I read that as prohibiting an app that lets a user cast their own content or third-party content.
And that's interesting, because, looking at my phone, the only things that violate that are Google's own apps (Photos, the OS itself with its Cast Screen functionality), which obviously aren't bound by the SDK agreement.
Never got it to work with anything, video, audio, images. The ChromeCast screen changes as if it's loading something, but it just sits there forever and nothing plays.
There was formerly a Google-made addon for this. Now it's integrated into Chrome. There are two features here:
- Chrome can stream its renderer output to a 'Google Cast'-supporting stream sink, like a Chromecast. This option is buried in the hamburger menu.
- websites can be coded against a JS library that's implemented by Chrome [1][2]. Then the 'stream to...' menu is shown as the 'cast' icon near the address bar.
I love Chromecasts and brining Google Cast into Chrome made me quite happy since the integration with Hangouts (you can cast a tab into a hangout if the meeting is part of your Google Calendar) is terrific.
However as someone who helps out with the company's network, they are infuriating:
- They ignore the DHCP given DNS Servers instead using Google's. I'm sure the same is true for NTP though I haven't bothered testing that.
- They use mDNS and DNS-SD but not DNS-SD Wide Area Discovery. This makes subnetting more difficult and increases broadcast traffic quite a bit.
- Not a complaint, more a wish, but a PoE version of the Ethernet adapter would be immensely helpful.
OT: If someone wanted to block connections to Google's DNS servers, can it be done reliably? Is there a known, static range?
AFAIK Android also uses Google's DNS servers, and it's hard coded into the OS, and the client pings the server before any software firewall can load at boot. (Allow me to reemphasize: AFAIK; if someone knows more I'd appreciate it.)
You can capture all DNS outbound (port 53) traffic not to/from your local DNS server and redirect it to your local/internal DNS server if you really wanted to. This is often done in order to jail/freeze all traffic until authenticated as well as whitelist certain traffic for the purpose of authentication.
Recently I moved house. I had to wait 6 weeks for the internet to be connected (first world problem).
While I was waiting for the connection I inevitably tried to fall back on local content and discovered, much to my discontent, that my Chromecast wouldn't work at all without internet, even when I was trying to play local content.
Looking forward to some standardization/interop coming out of this. There's Presentation API[1], which spec's a web API, but that still leaves open the question of coordination between a controller (browser) and display. Chrome's working on it[2], and I'd guess would target Cast, so web pages might be able to request their own casting, but it doesn't seem like anything other browsers could compete/cooperate openly with atm.
Assuming they drop support for the Chromecast add-on, doesn't this effectively eliminate the ability for other browsers that can use chrome extensions to cast to a Chromecast? (e.g., Opera, Vivaldi, maybe Chromium)?
That's actually a very important question. Is Google opening up casting in the widest sense to 3rd party clients? I know there was some push in this direction when it was launched ( https://en.wikipedia.org/wiki/Discovery_and_Launch ) but I seem to recall hearing that there is now more to Google Cast than DIAL. Does anyone know how interoperable this all is?
Looking at WireShark last night Google Cast was reaching out to Google every 30 seconds. I narrowed it down to my web browser, removing it from the toolbar stopped it.
Assuming some of the logic for determining whether a page is castable (or what options to offer) reside server-side then I can imaginez why this might be necessary. However it also might be poor coding.
Was it onerous in terms of resources - or was there any hint of nefarious behaviour? My suspicion is many people will assume the latter despite the rather neutral tone of your post. Therefore I'd be interested to hear more detail.
I have been interested in the Hacking Team leak of spyware and hacking tools. I found in the documentation taken from the hacking team website that when you run Wireshark their spyware looks for that and won't install. I have heard of wireshark before but never tried it, once I had it I saw that google chromecast going on it is like a beacon telling Google my ip address over and over again. Seemed like a bad thing. Maybe not all totally logical, why bother, but being logical all of the time is boring!
For anyone who hasn't seen it, check out the "peerflix" project on github. It's an amazing way to stream torrents, and you can easily cast them from chrome.
Although I've been waiting for wireless screen-sharing between TV and PC for a long time, that sounds much more difficult than a simple HDMI cable to my laptop. It's actually one of the reasons I continue to buy laptops.
Just to point out, the 'difficult' step here is really the torrent download. If you already have the file locally, you can send it to your tv in a couple clicks using Videostream. Assuming everything works as you hope, it's more convenient than plugging in a cable for me at least.
Readit News
I think Google is really shooting themselves in the foot regarding adoption. I'd love to have a command-line Cast client for Linux, integration into pulseaudio, a Firefox Cast extension, a native UI (non-browser) video player, etc. Sure, some people have reverse-engineered the newer protocol, but I've never gotten any of the unofficial clients to work reliably (and some just flat-out don't work at all).
- Google Cast is not a general-purpose streaming protocol, even though it is designed to mimic that UX to a casual user
- Cast provides some features like 'ad breaks' [1] that are valuable to content providers and aggregators which you wouldn't find in a general-purpose streaming protocol, making it more likely that those who want these features will make their streaming app Cast-compatible
- The Cast SDK comes with a TOS [2] that's a rather enlightening read
- You have to register your application with Google if you're developing a Cast sender [3], or if you're developing a Cast receiver and don't want to use their Default Receiver [4] (presumably, because you're building your own).
Google's building an ecosystem here. This isn't Miracast or WiDi or even AirPlay, although kudos to them for making everyone think so.
[1] https://developers.google.com/cast/docs/ads
[2] https://developers.google.com/cast/docs/terms
[3] https://developers.google.com/cast/docs/chrome_sender#setup
[4] https://developers.google.com/cast/docs/receiver_apps#choose...
> you must take appropriate steps to ensure that your application cannot be invoked to launch content for which you are not responsible
I read that as prohibiting an app that lets a user cast their own content or third-party content.
And that's interesting, because, looking at my phone, the only things that violate that are Google's own apps (Photos, the OS itself with its Cast Screen functionality), which obviously aren't bound by the SDK agreement.
https://github.com/skorokithakis/catt
For example: https://github.com/xat/castnow
My TVs are typically much larger and at a different aspect ratio than my monitor
But unfortunately, there's no SDK or API to even begin considering this sort of thing
No desktop apps are able to get it
Dead Comment
- Chrome can stream its renderer output to a 'Google Cast'-supporting stream sink, like a Chromecast. This option is buried in the hamburger menu.
- websites can be coded against a JS library that's implemented by Chrome [1][2]. Then the 'stream to...' menu is shown as the 'cast' icon near the address bar.
[1] https://developers.google.com/cast/docs/reference/chrome/
[2] https://developers.google.com/cast/docs/chrome_sender
However as someone who helps out with the company's network, they are infuriating:
- They ignore the DHCP given DNS Servers instead using Google's. I'm sure the same is true for NTP though I haven't bothered testing that.
- They use mDNS and DNS-SD but not DNS-SD Wide Area Discovery. This makes subnetting more difficult and increases broadcast traffic quite a bit.
- Not a complaint, more a wish, but a PoE version of the Ethernet adapter would be immensely helpful.
AFAIK Android also uses Google's DNS servers, and it's hard coded into the OS, and the client pings the server before any software firewall can load at boot. (Allow me to reemphasize: AFAIK; if someone knows more I'd appreciate it.)
I've been less happy with it ever since.
[1] https://www.w3.org/TR/presentation-api/
[2] https://bugs.chromium.org/p/chromium/issues/list?q=component...
Was it onerous in terms of resources - or was there any hint of nefarious behaviour? My suspicion is many people will assume the latter despite the rather neutral tone of your post. Therefore I'd be interested to hear more detail.
Basically you just do:
And then navigate to http://localhost:8888 and cast the tab.Unfortunately it only works with MP4. There may be some workarounds with an ffmpeg command in the middle, but I haven't experimented with it much.