[HN Gopher] NymphCast - Open-source Chromecast Alternative
___________________________________________________________________
NymphCast - Open-source Chromecast Alternative
Author : nedp
Score : 204 points
Date : 2021-06-12 08:23 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tmikaeld wrote:
| 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!
| gizdan wrote:
| 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?
| ghostly_s wrote:
| 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.
| monocasa wrote:
| 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.
| StavrosK wrote:
| This is excellent, finally we'll be able to cast to Raspberry Pis
| and other Linux-running computers. Well done!
| ekianjo wrote:
| 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
| StavrosK wrote:
| Does that expose a Cast device? That's very interesting.
| kokx wrote:
| It doesn't expose a Google Cast device. It only allows
| streaming media from a Jellyfin instance to that device.
| StavrosK wrote:
| Oh, then it's very different from what I want...
| icebraining wrote:
| Check out Kodi plus the TubeCast add-on. I can cast stuff
| from the official YouTube app for Android into my
| Raspberry.
| kingosticks wrote:
| 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.
| forgotpwd16 wrote:
| This is basically a reverse Jellyfin. The server is the one
| playing the stream and the client the one providing it.
| akent wrote:
| Will we? Seems like it's an entirely different protocol from
| Google Cast?
| matthewfcarlson wrote:
| 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.
| dragonwriter wrote:
| If your stick uses Google Cast, one app meeting that
| description is "the Youtube website".
| matthewfcarlson wrote:
| I think only if you're using the Google Chrome browser...
| alias_neo wrote:
| 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.
| akvadrako wrote:
| 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.
| xenomachina wrote:
| > 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.
| stuaxo wrote:
| 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.
| akvadrako wrote:
| Well NymphCast does that too. The 2nd feature mentioned in
| their README:
|
| _> Streaming online content by passing a URL to the
| server._
| ghostly_s wrote:
| 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.
| caslon wrote:
| Why wouldn't it be able to do both? youtube-dl has solved
| that exact use-case for years.
| stormbrew wrote:
| 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.
| mongol wrote:
| Is this a completely independent effort or is it piggybacking on
| DLNA?
| MikusR wrote:
| It has nothing to do with DLNA or Chromecast. It's pure Not
| Invented Here stuff.
| tucosan wrote:
| Now, that's an esoteric choice of language. I'm curious about the
| rationale to chose Angelscript over the more common scripting
| languages.
| breakingcups wrote:
| 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.
| tucosan wrote:
| It will also be more difficult to find contributors.
| solarkraft wrote:
| 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.
| bronco21016 wrote:
| 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.
| sofixa wrote:
| 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)
| bronco21016 wrote:
| 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.
| encryptluks2 wrote:
| So then this is the same as Kodi, Plex, etc
| akvadrako wrote:
| No, it operates just like a Chromecast, but with a
| different protocol.
| zibzab wrote:
| 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?
| ekianjo wrote:
| > 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.
| worldsayshi wrote:
| Where does it say that?
| taylorius wrote:
| Sounds cool, though "nymph" gives it a vaguely erotic vibe, which
| might not be what you're after.
| _pmf_ wrote:
| I think the "cast" makes the association with fly fishing
| obvious enough.
| Exuma wrote:
| That is in no way obvious, lol.
| ohyeshedid wrote:
| I would say it's more obvious than confusing it with
| something erotic.
| zozbot234 wrote:
| 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.
| squarefoot wrote:
| 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?
| joshtynjala wrote:
| 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.
| sbochins wrote:
| 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.
| squarefoot wrote:
| 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.
| seized wrote:
| 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.
| jrm4 wrote:
| 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.
| saagarjha wrote:
| Past discussion: https://news.ycombinator.com/item?id=22457351
| soul4krsna wrote:
| Terrible name. Nympho thoughts any one?
| forgotpwd16 wrote:
| 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
| _Microft wrote:
| 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
| kingosticks wrote:
| 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.
| akvadrako wrote:
| 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.
| crispyporkbites wrote:
| Yes but it's unusable in 99% of apps, so it doesn't matter
| how technically brilliant it is
| akvadrako wrote:
| 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.
| oneplane wrote:
| Yet Linux is not 99% of the apps, 99% of the apps are the
| Android and iOS apps used by billions of users.
| colordrops wrote:
| And even better would be to support the Google Cast protocol
| to increase adoption while offering a roadmap to transition
| to a better protocol.
| adinisom wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-12 23:00 UTC)