[natethomas]

MilhouseVH, I said the sales only matter for devs who might work to make XBMC act as a SENDER of content to the Chromecast dongle. If there aren't a lot of dongles in the wild, why would we support it? I then went on to say that, irrespective of sales, XBMC as a chromecast RECEIVER would be awesome, because chromecast could be a viable platform agnostic service.

[Milhouse]

Amen on the receiver part.

[Memphiz]

If they screwed it up again like miracast which relies on linux kernel only features - at least i won't work on it. If i will then this has to be working for all our platforms (and as all of you know these are a couple these days ).

Well but for an ETA its like with airplay. We rely on some proper protocol definitions - so basically i will wait until someone reverse engineered and documented it in a proper way. Then we will see if its doable in a sane amount of time and worth it.

Of course it is possible that someone else beats me to it - no problem with that

@Nate i don't think we need an webserver for supporting the receiver side of chromecast. And if even - we already have one (e.x. json-rpc) ...

[Knocks]

I may be way off base, but could XBMC be simply ported to Chrome? That way you could fire it up directly in the browser on any of your "hub" devices, including your main PC, and stream to any TV equipped with this $35 stick.

[mikeplow1961]

Looks like a very interesting device. I have a Rikomagic stick on the way but will definitely buy a Chromecast as soon as they are available in the UK, it'll be great for my daughter using Youtube on her tablet etc and people are already reporting they can play their local content using the browser mirror function. At around 25 pounds it's got to be worth a punt.

Personally, with the Google machine behind it, it's simplicity and the Netflix 3 month offer, I think it'll do really well.

[krish_2k4]

Frankly, the idea of shooting video from XBMC to this dongle doesn't especially excite me. Mostly because that's not what XBMC is really for. XBMC can act as a tablet interface, but it remains primarily designed as a 10-foot interface. It was never intended to be a desktop or laptop interface.

With that said, if this little device supports acting as a UPnP receiver, I imagine it wouldn't be too hard to include it in the list for our GSOC UPnP project. But dealing with an entirely new protocol to deal with this single device sure feels like a waste of time at the moment. Maybe people will end up buying 100 million of them and it'll make more sense. Until then, I wouldn't hold my breath.

If they don't sell 100 million dongles, the most interesting thing to me remains using the protocol to make XBMC a receiver for airplay-like content from all mobile apps, not just those that come from Apple. That could also be virtually impossible though, as it certainly seems like XBMC would need an integrated web browser, which we don't have. It might be feasible in Android or possibly Linux, where software does a much better job of talking to each other, but it'd potentially be pretty tricky anywhere else.

setting the bar way too high on a 100million dongles!.

I was thinking of using the interface on your tablet then having an option (like a button) to play the movie on Chromecast.

This is how they demoed Netflix on the presentation. They used the normal interface on the tablet, then selected the movie to play on chromecast and just the movie played. Anyways I guess time will tell.

[jammastercd]

I'd vote for implmenting XBMC as a Google Cast receiver. Perhaps it could start as an add-on? Then later be built into XBMC as standard functionality?

https://developers.google.com/cast/refer...ver/jsdoc/

[BrooksyX]

Seems like a neat device and but I don't see myself personally using it very much. I only have on TV that my is connect to my XBMC media server, sometimes I stream to my phone but most of the time its on the TV which is connected via HDMI.

Now my parents on the other hand would probably use this device. Seems great for someone who relys on netflix for media and does not own a smart TV. I personally haven't used netflix streaming in years.

[BradleyR]

MilhouseVH, I said the sales only matter for devs who might work to make XBMC act as a SENDER of content to the Chromecast dongle. If there aren't a lot of dongles in the wild, why would we support it?

Well it sold out everywhere in less than 24 Hours my guess is this will be really popular and adding the option to act as a sender to the xbmc android version its not gonna be that hard and would be an attractive feature imho


When i saw the demo my first thought was I could make an app (Im an android dev) to scan/manage my videos on my NAS and send the link to the Chromecast, but then i realize Ive already have an app that does that and does it great and only needs the send to Chromecast part aka XBMC

[peeyes]

Earlier I thought it is a full fledged device like Apple TV, Roku or any other android sticks (Riko magic etc.) and got excited, but when I realized it is just a 'casting' device my big excitement gone! So I am happy with my Raspi for now, however looking forward to hear latest development on this...

[bubbleguuum]

This Chromecast tech is as closed source as it gets.

A Chromecast app using the Google Chromecast SDK must be *approved* by Google.
From the developer's site download page:

"Note: You may not publicly distribute or ship your Google Cast application without written permission from Google, per the terms of service described below"

YOU MAY NOT PUBLICLY DISTRIBUTE CODE CONTAINING THIS SDK OR REFERENCING THESE APIs WITHOUT A WRITTEN AGREEMENT WITH GOOGLE ALLOWING YOU TO DO SO.

You cannot just download it, integrate it in an app and be done. Google will look over your shoulder to approve it. That is not nice.
Then, for developping, you need the USB dongle and whitelist it for developement with this fantastic form.

So if I want to make a Googlecast app, I need Google's approval.
That is not developer friendly. And If it was, they would have allowed to use desktop Chrome as a Chromecast receiver (issue on bugtracker), and not attaching dubious strings to app distribution.

Now, suppose you want to make XBMC a Receiver, obviously without Google's blessing. It is a closed protocol. So first you have to reverse engineer it. Given the tight control Google seems to seek
on both Senders and Receivers, this is not good news.
The protocol itself seems simple (JSON data transmitted over a Websocket). Multicast used for discovery. Noone knows
yet if traffic is encrypted.

And there's the codec problem. It supports a ridiculous minimalistic list of codecs.
In fact it supports only html5 codecs, which makes sense since it runs in a browser.
For a Sender wanting to send to regular Receivers (eg, the official dongle), prepare to reeencode/remux all videos to mp4.
If making a custom Receiver, you can probably support more codecs.

My guess is that the protocol will be reverse-engineered, with OSS libraries allowing to write Senders and Receivers.
What Google will do then, nobody knows.

So to conclude, Google wants to achieve super tight control over who does what with this technology, and that's very disappointing.
It is probable they target large Internet media content providers (Hulu, Pandora, Spotify, ...) and do not care much about the rest.

[Milhouse]

I don't see any benefit in Google trying to prevent third party Chromecast Receivers, surely their intent with this product is to make their bread & butter phones/tablets more interesting by achieving feature parity with iOS/Airplay - the profit on the Chromecast dongle must be close to zero.

Hopefully Google will be quite keen for third party media playback products to include Chromecast Receiver support, perhaps with a view to it becoming the de facto standard, unless they're looking to licence it of course. That way Google stand to gain most if not all of the benefits from the platform without having to design, ship or sell any additional hardware.

[natethomas]

Yikes. Well that's disappointing.

[bubbleguuum]

One may wonder why it is so closed ?

In fact, Google may not have had the choice because of DRM.

I can see Netflix, Hulu and friends requiring from Google that the content cannot be pirated, eg saved to disk.
For that, it must not be possible to make non-approved (licensed) Googlecast receivers.

And since for now, no third party Sender app (except the few release app) has been release,
we do not now what kind of app Google will approve.
Making an app from non approved sources / content ? Maybe they will deny the ability to publish such app...

So wait'n'see...

[BradleyR]

Well its a preview sdk maybe thats why you need their OK to publish for now , well i hope this is the reason