NymphCast – Open-source Chromecast Alternative | Hacker News Reader

NymphCast – Open-source Chromecast Alternative

github.com

222 pointsnedp69 comments

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.

Well NymphCast does that too. The 2nd feature mentioned in their README:

> Streaming online content by passing a URL to the server.

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.

Why wouldn't it be able to do both? youtube-dl has solved that exact use-case for years.

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.

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.

And this title is misleading.

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.

Yes but it’s unusable in 99% of apps, so it doesn’t matter how technically brilliant it is

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.

Yet Linux is not 99% of the apps, 99% of the apps are the Android and iOS apps used by billions of users.

And even better would be to support the Google Cast protocol to increase adoption while offering a roadmap to transition to a better protocol.

Unfortunately that's not possible for receivers barring a break in crypto. Receivers are authenticated by the sending devices:

https://blog.oakbits.com/google-cast-protocol-receiver-authe...

An alternative Chromecast receiver needs cooperation from the sender one way or another.

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.

Now, that's an esoteric choice of language. I'm curious about the rationale to chose Angelscript over the more common scripting languages.

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.

It will also be more difficult to find contributors.

IIRC Maya has responded to this with something along the lines of “It’s a pet project and I like AngelScript”, which I’d deem fair.

Someone got really tired of there not being any good complete cross platform streaming alternatives to Chromecast ;-)

That's a huge amount of effort between, love it!

Past discussion: https://news.ycombinator.com/item?id=22457351

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.

You can do it using your distro of choice and KODI.

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 you have multiple smart TVs in your house, it’s simpler to have a single media server and connect to it via the smart TV software.

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.

Proper security, phones on a different VLAN.

No Bluetooth nonsense with notification sounds.

Better sorting via software like Plex or something else, then casting that stream to something else.

Casting doesn't mean transcoding either.

Casting to a group of devices that stays in sync.

My Chromecast Audios will be online for a very long time.

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.

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.

If your stick uses Google Cast, one app meeting that description is “the Youtube website”.

I think only if you're using the Google Chrome browser...

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.

Is this a completely independent effort or is it piggybacking on DLNA?

It has nothing to do with DLNA or Chromecast. It's pure Not Invented Here stuff.

This is excellent, finally we'll be able to cast to Raspberry Pis and other Linux-running computers. Well done!

Will we? Seems like it's an entirely different protocol from Google Cast?

You didn't really have to wait, you could do the same thing with Jellyfin already and any Linux device on your network using jellyfin-mpv-shim

Does that expose a Cast device? That's very interesting.

It doesn't expose a Google Cast device. It only allows streaming media from a Jellyfin instance to that device.

Oh, then it's very different from what I want...

Check out Kodi plus the TubeCast add-on. I can cast stuff from the official YouTube app for Android into my Raspberry.

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.

This is basically a reverse Jellyfin. The server is the one playing the stream and the client the one providing it.

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.

[0]: https://developers.google.com/cast/glossary#c

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:

https://cast.otter.jetzt/

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.

https://twitter.com/JanHenrikH/status/1374098303470682113

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)

So then this is the same as Kodi, Plex, etc

No, it operates just like a Chromecast, but with a different protocol.

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.

How do you cast a movie from your laptop to Kodi?

First, that isn't how Chromecast works.. however, for me to cast a movie from my laptop to Kodi I just enable file sharing on the directory that I want to share and then I can access it in Kodi and play it using the remote. I can also serve it via HTTP or SFTP.

Update: Saw that NewPipe even offers a stream to Kodi option. NewPipe is a popular open source YouTube interface.

That is how Chromecast works. And it doesn't require you to setup a local file share, then browse to it via another interface.

For example you can open a video in a player (like VLC) and choose "Render -> to Chromecast".

That is because VLC would act as the streaming device and that functionality exist with Kodi as well.

So it doesn’t really turn it into a Chromecast. That’s the language that makes it confusing.

It turns it into a device that can receive control and streams from another device using software specific to this implementation.

Sounds cool, though "nymph" gives it a vaguely erotic vibe, which might not be what you're after.

I think the "cast" makes the association with fly fishing obvious enough.

That is in no way obvious, lol.

I would say it's more obvious than confusing it with something erotic.

But this is still dependent in Google hardware and firmware?

To be more specific, I will need to "onboard" a fresh chromecast into my network with Google Home before i can use this?

Where does it say that?

> software solution which turns your choice of Linux-capable hardware into an audio and video source for a television or powered speakers

That's literally the first line in the repo description.

Reply on news.ycombinator.com