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.
Is it vendor lock in if you're casting services like Netflix etc? You can use many different devices to watch your content. We've had a Chromecast since the first version and it has always worked well (with the exception of Netflix lately). I recently purchased a Sony Blue Ray player and was surprised to find Chromecast built in to that.
What he's referring to, is that without the extension, other Chrome-extension-compatible browsers are not anymore usable for Chromecast. You now have to use Chrome.
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?
DIAL/SSDP is not used anymore (except for legacy apps, like the Youtube one). Now, this is mDNS (good) and proprietary protobuf protocol. There is no documentation for this but several people have reversed-engineered the stuff from the source code of Chromium and the extension to get third-party client (third-party Chromecast is not possible since there is a signature mechanism for clients to check). I have done such an implementation here: https://github.com/vincentbernat/nodecastor (but not really maintained).
That's troubling. Has anyone got any sense about whether interoperability is merely neglected or whether there's strategic reasons for its abandonment (either from Google itself or via pressure from partners with 'premium content')
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!
This part is here since quite some time (since the introduction of the "new" protocol, two years ago). It is not the complete picture since it's only the low-level view (mDNS and protobuf). It's not sufficient to build a client since you still have to figure out the content of the messages. The gap is the extension that was provided until now (as a minified JS).
It seems like Cast would be an inferior way to stream HD content to a TV for many users. If the source host is wifi-connected, you're tripling the amount of traffic that's passed through your access points: once from the content source (e.g. Netflix)
to the laptop via the AP, then presumably from the laptop to the AP and back out to the Chromecast device.
This is not the case for apps such as Netflix, YouTube, and HBO. They all stream directly to the Chromecast from your internet connection, your browser or app on your phone just acts as a remote.
That's not how it's done. That's a complete fallback.
For Netflix what happens is your browser tells the cast device what URL to go to to play the content. Your browser does not need to steam the video to the cast device. It can fall back to that so you can cast anything, however.
This is true but there are a couple caveats, one being the device playing the content has to already be authenticated properly.
You cannot simply go near a Cast-enabled device and start playing your stuff, unless I am mistaken. If that is the functionality then that would be terrifying as I would be handing my credentials to this Cast-enabled device.
Not sure if it works with desktops/laptops, but there is a guest mode (disabled by default) in the settings (on the Android app) that allows anyone to add thing sto the player queue.
Only app I know for sure it works is Youtube. I'm not sure what other app handles it, maybe GPM and Spotify.
Actually this is how the chromecast works. You never interact with the chromecast directly to configure your Netflix account for example. I assume (hope) they send a URL to the movie it should play with a one-time token to access the movie source.
Most likely it isn't a username/password but an authenticated URL... https://foo.bar.netflix.com/(UUID-OR-SIMILAR) where that is resolved to a resource, and the user authentication is valid for X hours from start...
There's no need for a plain username+password to be used... it's just an authentication token as the resource or part of the url.
They really just need to send the Netflix cookie from your browser to the chrome cast. But I don't think they do that, like sarnowski said, i believe they put some data in the url thats like a 1 time key for your account and the video you want to watch.
Don't people check their assumptions before asserting them as facts?
I don't know why it's a terrifying concept either.
Anyway, Chromecasts can be configured to allow guest access at the device level. Phones that are even on distinct networks can still guest-Chromecast via ultrasonic noises emitted by the Chromecast. It's pretty nifty. It's nice to have a bunch of people over and have a shared YouTube queue. For more details (https://support.google.com/chromecast/answer/6109297?hl=en) expand the section "How do mobile devices connect with a Chromecast in guest mode?".
> It seems like Cast would be an inferior way to stream HD content to a TV for many users. If the source host is wifi-connected, you're tripling the amount of traffic that's passed through your access points:
That's a fallback method, but the expected methods for most sources is that the you send the Google Cast receiver (chromecast, etc) a URL for the media, and it goes and streams it directly.
Which sadly is default/enforced behaviour. One day I downloaded something on Play Movies, and moved to another location that has Chromecast connected via a 3g access point. I expected the movie to play from the cached file, but no - it just silently downloaded a new version. Most expensive streaming session ever...
Google Play Music support was one of the main reasons I added a Chromecast to my setup. It's a frustrating gap in the wide variety of content that Roku can handle.
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.
Not sure how related this is, but my parents have a one or two year old Samsung "Smart" HDTV. It doesn't have Chromecast built in, but it does have Youtube, Netflix, and a few other "apps".
I thought it was really cool one time when I was visiting during a SpaceX launch and experimental sea landing because I was able to swap from watching live via Youtube on my laptop to casting it to their HDTV. That was just by pressing the cast button and selecting their TV, which was automatically in the list without me doing anything.
It's awesome that Google's made this more convenient and I think it'll be something useful for a lot of people.
Those are YouTube-specific hacks, as I understand it. My Oppo Blu-Ray player also shows up as a cast-to destination in the YouTube application, but it doesn't show up anywhere else that has the casting ability.
I believe that this is the DIAL (http://www.dial-multiscreen.org/) protocol. I know Netflix and YouTube use it, as well as I presume others. Personally I don't think it is as cool as Google Cast as it requires an app/server installed on the target, where as Cast can open any website.
Weird. I'd take a look at your Mac audio settings (System Prefs -> Sound -> Output) and any weird applications you've installed with access to sound output.
Also try quitting all apps except chrome and see if the problem persists.
I have no apps that have access to the sound output. The problem persists even if I run ONLY Chrome.
I am not the only one - you can see such an issue on the Chromecast support forums for many users. I have tried all recommended solutions like media router enable/disable etc. including using the Canary version. No luck! I have also raised this with the Chromecast support team like 2 weeks ago. I haven't heard from them since then.
Thanks for your patience. Currently, audio is not supported when casting your desktop from a Mac computer/laptop. However, casting a tab does support audio. We're always looking for ways to improve, so your feature request has been duly noted.
Safari has gotten quite good, btw, if you're on a mac. I mentioned this to a guy on the original Chrome team, and he said he wouldn't be surprised if it were faster now.... Chrome used to be all about speed but now it's about features.
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.
But maybe they use md5 checksums to only store one copy of the same file for thousands of users. Or maybe that's violating some legal shield they have within their TOS.
Either way their MP4 conversion is waaaay too fast for some of the more popular files, and those aren't a part of the torrents.
I'm sure they check against the checksums when providing you a file that already exists. Doesn't make sense to waste bandwidth (hey there, Kim)
I think in their FAQ they mention that they have some dedicated nodes that do the MP4 conversion. I completely agree with you though, the conversion is unreal.
Since Google Cast has been open-sourced (upstreamed to Chromium), does this make it the de-facto alternative to Miracast? My Roku supports screen mirroring, but the fact that apps and companies are more keen on supporting ChromeCast has been frustrating.
It appears that Google will eliminate Chrome "packaged apps" in the next year; do I understand these to be locally installed apps? (I don't know Chrome). All apps after that must be on (a service?) the web. What could be the reason behind this?
Chrome is deprecating Chrome Web Apps in favor of native Web Apps. Essentially it's a push towards a more open web now that the APIs have caught up. It really has nothing to do with services.
Since this has happened my (gen 1) chromecast experience has gone almost totally to crap.
The built in functionality is supposed to be smart about down scaling for wifi speed, and thus has removed all options to do it manually; unfortunately it utterly fails (I believe because wifi speed is fine but the bitrate is too high for the hardware).
Not very, but I they've been opening up more. Just today they announced they were adding spotify connect support, and amazon echo voice control support.
Nice job, thank you! Now... how can I disable it? Next time I'm on a public wifi network, this is going to be sending out probes for Chromecast devices, and it's only a matter of time before someone finds an exploit.
> only a matter of time before someone finds an exploit.
Chrome is looking ripe for exploitation. IIRC the default install includes an mDNS responder. Check out the guy who has every Chrome instance on his network crash at the same time: https://redd.it/4xej0p
"people have casted more than 38 million times from
Chrome, watching and listening to more than 50 million
hours of content."
So Google is monitoring your watching habits. What other information do they collect as part of this? Are these details documented in a privacy policy somewhere?
The setting chrome://flags/#disable-cast-streaming-hw-encoding only appears to toggle hardware encoding or not. Can it be disabled altogether?
There is a "Automatically send usage statistics and crash reports to Google" checkbox right in the settings. It even asks you during the install. Just uncheck the box to disable.
They also recorded this data as part of the Chrome extension, not natively. If you want to see more about the native metrics Chrome sends to Google, check out "chrome://histograms/"
I really want a feature that would allow me to cast from my phone to my desktop. I have a big TV plugged into my desktop but I can't cast to it from my phone, I have to remote in and manually control the desktop, it's painful.
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).
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.
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.
I don't quite think so. AirPlay is a proprietary Miracast, long before Miracast existed. Although it's proprietary and the payload is protected with DRM, Apple uses it as an encrypted tunnel between approved (and first-party) devices.
Meanwhile, Google Cast is a media-streaming negotiation, handoff and control protocol marketed as a wireless streaming solution. It's not so much about packets on the wire as control commands and metadata. That, I feel, is a significant difference.
I don't think that's actually part of the Cast protocol. Google just built a desktop streaming app on top of the Cast protocol, and bundled it with the client.
> 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.
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.
There should be a campaign to call Chrome "Google Browser" to make it clear just how tight the connection is. A lot of more-tech people would have a slightly harder time saying they use GBrowse than Chrome.
Few months ago, I bought a Nexus 5x assuming that it will support Miracast (like Nexus 5 did). I was very disappointed to know that Google dropped support for Miracast. re-enabling Miracast support was just a matter of changing a line in a config file. However that required rooting the device.
Dropping support for standard protocols and forcing users to use their proprietary stuff? what happened to their corporate moto "Don't be evil".
Really appreciate that Intel's been working on a Miracast receiver for Linux. Been super sad that Linux has been so far behind on the Miracast & Wifi-p2p fronts.
The 5x also doesn't have SlimPort or MHL support (when I found an adapter that worked well for the 4 and 5, HDMI out was fantastic)
It may be that they found that Miracast just doesn't work well enough. I've got all sorts of Wifi gear and I can't get my Moto X Style to stream via Miracast reliably (to an Xbox One as a client). The Nexus 5 streams reliably but drops / stutters about once every two minutes, making music streams pretty much unusable.
I hope Amazon FireTV supports this soon, or supplies a client. I've already got several of these sticks, and I'd love to be able to cast a tab up from somewhere on my network.
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.
" In the past month alone, people have casted more than 38 million times from Chrome, watching and listening to more than 50 million hours of content."
Apologies for the stupid question, but how exactly does Google know this? Is there some "send statistics home" function in the browser?
Chromecast if left on (using the included power adapter) will use about 14gig of bandwidth downloading images for its background that you can not turn off. As someone on a metered MiFi that's a no go.
That really says something about the people who developed and tested these... (Something along the lines of "Hey, maybe you should try getting out of the Google campus/dorms occasionally, possibly even out of the Bay Area, and see how the world works for non-Google employees…")
Chromecast - only $35![1]
smallprint [1] requires unlimited highspeed broadband. May use several times it's purchase price in bandwidth per month if your employer doesn't provide free Google Fibre to your home.
I've posted at least once before about this. Google, Microsoft and a lot of other companies really don't think about "low" bandwidth (<20 megabit downstream) or situations where you're not always connected.
Props to Facebook for having "2G" day. I hope it still happens.
* Dropbox is meant to have a LAN sync but fails back quickly to syncing from their servers. There's no way to debug why it isn't using other hosts on your LAN
* OneDrive has no LAN sync at all
* There's no way to debug Windows 10's LAN update sharing if it fails.
* Windows 10 will default to uploading partial updates to other users on the Internet (bittorrent style)
* Windows 10 will let you set a Wifi connection as "metered" and actually behave quite well (deferring updates, driver downloads and OneDrive data), but there's no way to set Ethernet networks as metered, outside of a registry hack.
* Google not supporting SD cards in the Nexus line (yes, I know about the performance issues, I own several >$50 SD cards that are trash). Mobile data is expensive.
* It took Google until 2016 to offer offline caching of YouTube videos, and even then you have to pay them for the privilege
* Microsoft's newer .NET and Powershell stuff download >50 megabytes of dependencies from NuGet.org and MyGet.org. Offline caching is possible, but maybe not on Linux
Heh - it's quite a struggle for me to get 20megabits at my place. I've got reasonably affordable 12-14mbits of ADSL2 (with unimited traffic) for $70/month, but I can't get NBN where I live, there's no Telstra or Optus cable (our local shared 100mbit down HFC option which tops out a maybe 3mbits up) in my building complex, so the only "high speed" options are LTE (a several dollars per Gigabyte) or _maybe_ NBN fixed wireless (tops out at 50mbit).
I feel guilty every time I mention that I'm on the NBN - the real one. The fibre terminates into a NBNco branded box and as long as I've got a device that speaks PPPoE I'm online.
It doesn't solve all problems - there's massive congestion on Internode where I am that limits me to 20 megabits during the day, and TPG have messed up the routes to everywhere (Xbox Live gets <2 megabit, but Steam works fine).
So I just checked again - the brand new 200 apartment building up the end of my street is wired for NBN, pretty much all of the rest of my suburb isn't even in the planning stage still.
(I bet I could get a bunch of wifi signals from that new apartment block with my 24db gain 2.4GHz yagi...)
Regarding SD cards, you can use flash drives w/ micro-USB ports (or a regular drive with an OTG cable). Not as handy since they stick out, but for occasionally swapping out data or bringing extra content with you on trips, they're pretty useful.
workaround is to use the USB port on tv if it has it so chromecast only powers/off when the tv is on/off.
if that is not feasible, disable all the background options.
create an album of a single image on your google account.
enable showing photos from your google account, selecting that album..
1) create a google photos album with a single photo in it
2) in the "Google Cast" mobile app, go to Settings --> Backdrop, and uncheck/turn OFF everything except Google Photos
3) select your "single photo" album
4) profit
I was surprised to hear that not many people knew that Safari does something similar (kind of) with AirPlay. A lot of videos and content (on YouTube for example) can be Airplayed when using Safari, but not when using Chrome or Firefox.
You can find out the ip of your chromecast with the command "arp -a" and it should list Chromecast as one of the devices if its switched on and on the same wifi
Only works with VLC nightly builds 3.x.x. Also it is not very stable but gets the job done if you don't care about subtitles and scrolling through the video frequently.
THe best option is plex (works for many file formats). Second best option is videostream extension on Chrome (not on chromium). But videostream doesn't support all file formats. They keep updating though.
And yet, despite Google making a strong play for the education and corporate markets, Chromecast still doesn't work on enterprise wireless networks, effectively cutting out any use in those spaces.
- 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
reply