There is clearly a lot of misunderstanding in the comments here. I feel like the repository is causing confusion by referring to Chromecast.
This has nothing to do with Chromecast, nor does it have anything to do with Google Cast, nor will it let or help you "Cast" anything like YouTube to your Cast capable devices.
What this is, is an (early) software implementation to stream media from a control device (your phone etc) to an SBC or other machine running the server code, and connected to a TV or monitor. It appears that the media must be resident on the controller and not the server.
It looks like they're aiming for multiple targets with "good" synchronisation, whatever that means.
Looks like a nice toy project for someone but there seem to be far more mature tools out there, at least for multi-room audio.
For video, if you don't need sync, Jellyfin (libre Emby fork) is quite capable.
You say this has nothing to do with Chromecast and then describe the #1 use-case for casting, to play movies that sit on your device (phone, laptop) on your TV.
Jellyfin, based on their website, looks like just another media server.
> the #1 use-case for casting, to play movies that sit on your device (phone, laptop) on your TV
Is it really, though? I've used "casting" many times, and it was always to cast something that was "on the cloud", never something that was on my phone, to my TV. For example, it's a lot easier to find a specific YouTube video with my phone than with my TV remote.
I'm guessing this won't work for the "cast" button from my computer or from apps or websites on my phone like Youtube, Vimeo or All Four (the uk channel 4 app).
I like what they've done, but Google has really locked this down unfortunately.
I suspect what they mean is digging around in the source of a webpage to find the content url, hoping it's not obfuscated or DRM'd, and passing that; not "passing a URL" in the sense of streaming arbitrary web pages as Chromecast is able to do.
The #1 use case for 'casting' with a chromecast in my house is absolutely to stream from online services to my tv or monitor while controlling it from a device that would melt or run down its battery if it tried to act as a go-between for the data, or had to potentially re-encode data from its storage to what the tv can support.
That's still the niche that chromecast fills better than anything else at a price point that means you can buy one for every tv and monitor in your house for the cost of a more fully featured device with storage on one or two tvs.
Sadly google seems to hate the chromecast and even their own software gets worse at casting to it every year.
> Sadly google seems to hate the chromecast and even their own software gets worse at casting to it every year.
Yeah, I've always been amazed at how unreliable and broken the Chromecast software seems to be (for me, at least). I feel like Google really missed an opportunity here.
If this hadn't been the case, I personally would have purchased more of them and, importantly, recommended them to many people. But, after a couple tries (gen. 1 and gen. 2), I gave up.
Technically it might be an "open-source Google Cast" alternative but it's definitely not an "Open-source Chromecast" alternative. If it was, I would be able to open any app that supports Google Cast and control a device running this software like I can control a Chromecast. But it doesn't support that, and that's what most people are expecting/wanting. It might be a great project but it's not able to provide the tight integration that makes Google Cast so good.
On the contrary, an open alternative to Google Cast is very welcome and much better than a Chomecast clone. The protocol is not very good so trying to re-implement it is just asking for trouble.
Chromecast is also unusable for 99% of apps. On Linux, there is no reliable way to use it to play movies with embedded subtitles on your TV. Probably because the protocol is too hard to implement.
I'm curious. Usually when something like an open source alternative to a product is highly sought after feature, someone will often attempt to reverse engineer the apis or something mostly so it works with the current ecosystem. What has made Google Cast so resistant to this? I can't imagine the protocol being a complex one. Does anyone know?
from what I've heard it's actually quite complex, using different "streaming" strategies (often not streaming from the source device at all, but instead loading the desired content directly on the chromecast device) depending on the nature of the content.
IIRC there's also a per sink device signature verification scheme inherent in the protocol as the devices check in to Google's backend that makes it nearly impossible to just spin up arbitrary sink devices. Google has to have known about the device's public key before they'll talk to it, and it requires their backend fundamentally to work. That key association is probably a manufacturing step that we're not privy to.
I've only ever seen Angelscript used in an extension to a 22-year old game. AFAIK it's purely interpreted and mostly just very simple to integrate. (And somewhat more secure by default because it's so simple and interpreted)
Any serious product using it which depends somewhat on performance should probably integrate V8 or something similar instead. The Angelscript language is very similar to Javascript etc. but so niche that you'll keep having to look stuff up.
I thought this might have been the thing I'm looking for; relatively painless screencasting or sharing from a local (Linux) PC to another device on the network (e.g. Raspberry Pi + Big Screen TV). The use case isn't necessarily full motion video + audio, but more for business/conference room type use, where response time isn't wildly important, since it's something like a whiteboard.
Monitor-over-network would be great too, but not a requirement; I'm aware that solutions exist, but so far everything I've tried has been painfully clunky.
I'm still looking for a VLC plugin that let's you stream to VLC via UPNP/DLNA. If that existed you could basically turn any raspberry pi into a Chromecast using your distro of choice and VLC.
Yeah and I used to use that, but it is a pain. If all you're doing is sending video from another device like you would with a Chromecast, all the features that come bundled in Kodi are bloat.
I don't understand the point behind "casting" something in a home environment, unless one keeps the client unsupervised. It could make sense in contexts where say one or more unsupervised signage displays are connected to small embedded boards that throw at the screens whatever feed is being streamed to them. That would be ok, but what about home environments?
Let me give an example. I keep all my media in a home NAS (Nas4Free plus RAID etc.) as simple files (mpeg4 etc.). My home TV is connected to a RPi running Kodi that accesses the file list through SMB/NFS shares, as every other computer in the house.
If I want to watch a movie, I use Kodi to navigate the file list until I find the relevant file and play it. There are no downsides since it's a one click solution, and the pretty good CEC support by Kodi and the RPi makes it a breeze (one single remote for both the TV and Kodi) but this way the file is being transcoded by the player (the RPi) and not by the streming hardware, which would be an often less powerful platform like a NAS.
This also means the streamed content travels as compressed packets through the network, in fact loading it a lot less than for example it would happen when streaming it after transcoding. As a result, I could have like 10 machines watching each one its own Full HD movie on a home wired network, which would be unthinkable if the poor NAS had to transcode all of them on the fly, not to mention the much heavier network load.
So the question is: what's the point in streaming in home environments rather than navigating file shares?
If I discover a new movie trailer on my phone, and I want to watch it on my bigger TV screen, it's much easier to immediately cast the video that I've already pulled up than to try to find the same video with my TV remote.
My example was with each Smart TV / PC / Media Box, etc. watching different programmes at the same time from the same NAS. By treating everything as a file it is being sent as compressed therefore not loading excessively the NAS or clogging the network with much higher bitrates.
Completely unrelated but I would love a CLI/GUI type tool on my laptop that I could control a youtube client with. Most youtube clients on smart TV's, consoles, and streaming sticks support being controlled by a phone. I'd love to control it from my laptop instead of solely my phone.
https://github.com/albfan/miraclecast might be an interesting alternative, based on the widespread Miracast standard. No idea how up-to-daye that codebase is, though.
What exactly do you want? If you want to have some device appear in the target list when using google cast in apps then I think you are stuck waiting for Google to (never) open that up.
Edit: although maybe some apps still support DIAL and that might be an option.
Although often confused, the term Chromecast refers[0] to the product brand. The protocol is called[0] Google Cast. This is an open-source alternative to the software and the protocol (as it isn't a Cast implementation) rather the hardware.
Just bringing this open source audio streaming solution also to your attention. It says that it supports Snapcast, Spotifyd / Spotify Connect, Shairport Sync / AirPlay and can act as a PulseAudio Sink:
According to one of its creators, the device can be ordered partially pre-assembled for $10 and requires additional parts worth another $10 to be soldered on by yourself.
As many other commenters point out, I’m confused what this actually does?
Does this allow me to turn a SBC into a Chromecast? Meaning, do I install this on a SBC, or any Linux machine, and magically I can cast YouTube to it from my phone?
The README could use a quick FAQ of what this repo can and cannot do as it relates to the Chromecast/Google Cast ecosystem since they’re using that brand name in the description.
As far as i understand it, no. It allows to turn hardware running Linux ( like a Pi) into a Chromecast ( the dongle), to which you can stream video/audio from another device ( but not compatible with Google's protocol, so you can't click on YouTube's cast button to use it, you need extra software)
This is a joke, right? If it requires a Raspberry Pi then it is not different than Kodi or wherever else that supports the same functionality. I feel like the authors here reinvented fire and then are refusing to acknowledge or admit that it has already been done.
This has nothing to do with Chromecast, nor does it have anything to do with Google Cast, nor will it let or help you "Cast" anything like YouTube to your Cast capable devices.
What this is, is an (early) software implementation to stream media from a control device (your phone etc) to an SBC or other machine running the server code, and connected to a TV or monitor. It appears that the media must be resident on the controller and not the server.
It looks like they're aiming for multiple targets with "good" synchronisation, whatever that means.
Looks like a nice toy project for someone but there seem to be far more mature tools out there, at least for multi-room audio.
For video, if you don't need sync, Jellyfin (libre Emby fork) is quite capable.