4 ms·
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
by niftich 10y ago
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.
[1] https://developers.google.com/cast/docs/ads https://developers.google.com/cast/docs/ads
[2] https://developers.google.com/cast/docs/terms https://developers.google.com/cast/docs/terms
[3] https://developers.google.com/cast/docs/chrome_sender#setup https://developers.google.com/cast/docs/chrome_sender#setup
[4] https://developers.google.com/cast/docs/receiver_apps#choose-a-receiver https://developers.google.com/cast/docs/receiver_apps#choose...
- izacus 10y agoIsn't AirPlay pretty much analogous? Only available on a single brand of devices with an effectively DRM protected closed protocol?
- niftich 10y agoI 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.
- dingo_bat 10y agoYou can cast your desktop using Chrome cast. I'm pretty sure that's more than negotiation, handoff and control.
- matchu 10y agoI 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.
- mmahemoff 10y agoChromecast is available on iOS and the web, not just Android, ie any third-party iOS developer - not just Google - can support Chromecast. So platform support is more widespread, though your main point is valid insofar as Google determines which platforms it works on.
- mmrezaie 10y agobut still so many of applications that their version on android supports it, do not support it in their ios version e.g. soundcloud.
- cloudjacker 10y agoThat doesn't disprove that they are, in fact, NOT shooting themselves in the foot
- kelnos 10y agoOof! > 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.