Hacker News Reader

Comment by jfuhrman | Hacker News Reader

> 1.5B casts from Chromecast

Interesting, I didn't know that every cast was reported back to the mothership.

Actually it does - the casting isn't triggered locally directly, but the castee sends a chromecast ID + app ID to Google servers which then sends appropriate payload to the CC.

Interesting -- that seems like it'd be introducing a lot of points to grow latency if you're casting a Chrome tab. Do you happen to know if that works differently?

Chrome tabs use the same process for initiation, but then use WebRTC to actually stream the tab over the local network.

The actual media data / streams can of course cast directly by sending a local network URL to HTML5 part of your app, but the load of that HTML5 part is triggered via Google servers - essentially the Google server tells CC which URL to load for a certain app.

Not to say that it does. Users who have opted into provide data to Google might have a once-a-month ping containing the number of times it's been used.

There are plenty of other ways to get that information. Statistics (x number sold * y average casts per user), asking streaming companies (i'm sure netflix and hulu know when you're on a chromecast and could report rough numbers to google), and i'm pretty sure there are other ways that I'm not thinking of.

... and how would they know "average casts per user"?

You don't, but that's what the entire field of statistics was invented for to estimate :)

From the above, though, it sounds like that's not necessary since it's fundamental to the cast protocol.

Nope. As others have pointed out, every cast has to begin with a call to google.com (which is why chromecast must be connected to the internet). The call basically sends an id number to google, and then google returns a URL of where to get the code for that cast.

Reply on news.ycombinator.com