Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"to queue, download and then send to the display"

According to AvsForum news: "streams it directly to the Chromecast device from the cloud". So you are right about it being somewhat different from airPlay, but it clearly intends to be seamless, and not have a queue / download cycle, but stream it just as it would to your browser.

It also says "including Youtube, Netflix, and Google Play, Vudu, Hulu... anything that plays in a Chrome browser" which sounds a little different from "a method for driving-devices to send pointers to internet video streams". The latter seems to imply programming changes on the provider's part, whereas the former clearly does not. (I don't actually know which is true, just pointing out the differences).



>"streams it directly to the Chromecast device from the cloud". So you are right about it being somewhat different from airPlay

AirPlay will send a URL to the Apple TV if possible. If you're streaming a video from a web page, it most likely will just send the URL to the Apple TV. The only communication with the device is the control channel.


'queue' was referring to chromecast's touted ability for, say, me to be able to send a video to the chromecast and then you to send one for it to play 'next'.

And 'download' was to make explicit the chromecast is downloading the content from the internet itself; it's not taking a videostream from the device as in the Airplay/"device-as-brains" scenario.

I'm not sure there's any difference between the phrasings in your second paragraph. I certainly didn't intend to imply anything different.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: