[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)
 
web link (github.com)
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)