
NymphCast: Casual attempt at open alternative to Chromecast - ingve
https://mayaposch.blogspot.com/2020/03/nymphcast-casual-attempt-at-open.html
======
Xorlev
Looking through the code you can tell the author is putting a lot of work into
this project. It's not the cleanest code, but it's the kind of "home cooked"
project I really enjoy seeing. Built from the ground up using a self-rolled
RPC library and everything. It's really neat. Give it some more "bake time"
and this could be a really great way to use a Pi.

------
pjc50
As the article points out, ChromeCast is an _extremely_ locked down protocol.
It's designed to bind your device and all its clients permanently into the
Google ecosystem.

The real shame is that it had to exist in the first place and that DLNA was
never adequate for this.

~~~
makapuf
Im baffles that afaict we have no standard wireless protocol to send a still
image from a pc (Open architecture) or a mobile phone to a big screen such as
slides - never mind a video or reusing wifi

~~~
felixfbecker
What about Miracast?

~~~
rodgerd
Apple never adopted it, which meant that you had Windows + Android able to use
Miracast, but iOS not; AirPlay couldn't be used by the other side of the
fence.

DLNA could, in theory, be all things to all people, but like similar "all
things" it's such a pain in the arse to get renderers and servers all talking
to each other it never really "just works".

Of course, all of that wouldn't necessarily be a problem except that Apple and
Google are deeply invested in non-compatibility.

~~~
GeekyBear
Apple already had it's own standard in place before Miracast was created.

The audio only version of AirPlay (AirTunes) goes back a decade before
Miracast, and the version that also supports video predates Miracast by two
years.

It would be nice to be able to add an iOS plugin to add system wide support
for Miracast instead of just having some apps choose to support it.

------
thom
While I am not proud of this, Chromecast is a fairly core part of mine and my
family's routine each week. It's one of probably only two consumer
technologies that I've found transformative in the last ten years, the other
being Apple Pay. It'd certainly be interesting if there were an viable open
alternative, but it seems unlikely that NymphCast is going to make a debut in
the Netflix app anytime soon. I'd probably settle for a good Firefox
implementation of the Chromecast protocol, but that's obviously missing the
point here.

Also as an aside, AngelScript's is another of these programming language sites
where sample code seems to be more than three clicks away from the homepage. I
will admit I gave up before finding any.

~~~
Waterluvian
Chromecast is the killer product that drives our home's media use.

It just works. It's accessible to anyone with their phone. The UI are the
phone apps. It plus a few subscription services makes every other media box
obsolete for us.

I got a Roku tv last month. For jokes I turned on WiFi and tried out the built
in streaming. Just terrible. Great for people without phones, but who else
would want that kind of experience?

~~~
cortesoft
Really? I find other media players so much easier to use. I hate having to use
my phone to control the player; I can't look at my phone for things and
control the media at the same time. Switching back to whatever app I was using
often find I have lost the connection, and it takes a good number of seconds
to re-connect and gain control.

I also find it really hard to fast forward and rewind... I never get the
responsiveness that I get on my XBOX, and I can't rewind and fast forward with
nearly the precision, either.

~~~
woofcat
>I never get the responsiveness that I get on my XBOX, and I can't rewind and
fast forward with nearly the precision, either.

Comparing a $30 dongle and a multi hundred dollar computer seems a tad unfair.
I'm not buying an xBox for my mom to watch Netflix.

~~~
cortesoft
Sure, but the person I was responding to didn't talk about the price factor at
all; they simply stated it was the best media player.

------
mfoltzgoogle
Hi there,

I'm from Chrome, someone on my team pointed me at this thread. My team
supports casting features in Chrome. This is a fantastic project and it's
great to see energy around this.

I get the frustration around the inability to make devices work together for
casting. In the standards community, we have been working with other companies
and researchers on a protocol [1] that provides the groundwork for
interoperability in media streaming and media control on the Web between
browsers/apps and devices. We are developing an open source implementation and
plan to see it in future products.

There's a lot of other work going on in the Web standards community as well,
that in the near future will allow Web apps to create their own media codec
pipelines and streaming protocols customized to their needs [2] [3].

[1]
[https://w3c.github.io/openscreenprotocol/](https://w3c.github.io/openscreenprotocol/)
[2] [https://github.com/WICG/web-codecs](https://github.com/WICG/web-codecs)
[3] [https://github.com/WICG/web-transport](https://github.com/WICG/web-
transport) (client/server), [https://w3c.github.io/webrtc-
quic/](https://w3c.github.io/webrtc-quic/) (P2P)

If you have suggested use cases or questions engaging on GitHub through the
standards repos is a great way to get involved or you can email public-
secondscreen@w3.org.

Cheers, Mark Foltz GitHub:
[https://github.com/mfoltzgoogle](https://github.com/mfoltzgoogle)

------
robert_foss
This is super neat, having an alternative to Chromecast is really welcome.

------
guyzero
Chromecast and AirPlay are both locked down because they're fundamentally tied
to DRM and no content provider is going to spend any time on a platform that
doesn't have strong L1 DRM.

~~~
alkonaut
And it works the other way too: as a consumer I don't care about whether
something is open or not, if it doesn't stream the things I want to stream.

~~~
_eht
Consider caring.

~~~
alkonaut
I do care. I just care less about openness than convenience notice the " _IF_
it doesn't stream...". Given two systems that work equally well, I'd pick the
open one. That's rarely the case though. So I pick the polished one. I think
this goes for most consumers.

------
JeremyNT
I love to see some progress in this space! I was curious about using e.g.
Raspberry Pis or old Android devices as replacements for the now defunct
Google Chromecast Audio, that is a set of linked devices connected to speakers
throughout the house and all streaming from a single source that I can control
from my phone or PC.

Doing this seemed to be _unreasonably_ difficult. The closest thing to a
solution I identified was using Mopidy along with Icecast, where Mopidy is the
control plane and Icecast is the audio sink, and all client devices simply
permanently connected to the shoutcast stream.

This "worked" but it is very frustrating for a simple use case. Mopidy used to
be a MPD server implementation, but it has deprecated that in favor of its own
API, and the client options were very limited. And nevermind video, this was
just audio...

Anyway, I feel like NymphCast is a very welcome development, and I really hope
that Maya will continue to work on it.

~~~
kingosticks
FYI Mopidy-MPD is not actually deprecated. It just doesn't have a maintainer
that's interested in it. Some parts of the MPD protocol are a bad fit for
streaming services where the 'media library' is essentially infinite so it's
much harder to use performantly. That makes it really frustrating to develop
with considering the Mopidy core API is available and far better suited.

~~~
JeremyNT
That's good to know, I am still using the MPD support in Mopidy since I found
more clients for it.

Certainly as an end user the MPD ecosystem looks to be "stagnant" to put it
generously, many of the clients I tried demonstrated curious behavior, and at
least for audio there don't seem to be any obvious alternative standards
emerging to replace it yet.

------
kachurovskiy
Built something similar but with less features and moving parts, abandoned due
to the lack of interest:
[https://github.com/kachurovskiy/ArinaCast](https://github.com/kachurovskiy/ArinaCast)

------
crudbug
W3C has SecondScreen WG looking at similar open solution [1]

[1]
[https://www.w3.org/2014/secondscreen/](https://www.w3.org/2014/secondscreen/)

------
solarkraft
Looks cool! I have myself been super frustrated by the lack of free streaming
protocols or implementations.

DLNA (UPnP) is in theory perfect for this use case and it wouldn't be that
hard to use it together with VLC and a Python script and I have indeed
attempted this, but at the end just gave up due to the complexity of the
protocol (and my laziness).

I am currently still in the market for a good casting solution like this. I'll
probably try this, but at a first glance it seems like it may do a little more
than I need.

Does anyone know any other similar projects?

------
sneak
I think the real issue here is that streaming to these things requires buy-in
to support the client inside of eg the video player app or the audio player
app.

I have an iPhone, and it can only send system-level audio to AirPlay. The
Spotify app itself also supports streaming to Amazon devices. The YouTube app
will also stream to a Chromecast.

It’s all so balkanized. I’m not sure making a new format/protocol will solve
_that_ problem, although if it is solvable that’s certainly the first step.

~~~
hackkitten
One idea I have to perhaps get around this issue is to fudge in an
external/new audio/video output that can be targeted instead of the standard
outputs. This of course gets into some heavily platform-specific nonsense,
which is why I haven't pursued it further yet. Maybe after the first release
of NymphCast it's something to look at in more depth :)

(I'm the NymphCast author)

------
kingosticks
Playback of whatever media on a SBC (rpi etc) is not the problem. Of course,
it's great to have more software doing this and I applaud the effort
(personally I'd have leveraged gstreamer and saved a load of time since I've
used it before).

The real problem, quickly dismissed in this article, is support integrated
into 1st party apps. Chromecast lets you use a streaming platform app 100%
normally and then 2 clicks later it's playing on your big screen/speakers. You
could implement some sort of bridge app (that you'd "share" the content to)
but then you are switching between the streaming app for content discovery,
and the bridge app for control. That's not the chromecast experience. The only
way we can get that experience is with 1st class support built into the
streaming app. Spotify/Google/soundcloud/Amazon have no reason at all to work
on adding support for something new until it becomes popular, but that's
obviously a chicken and egg situation. Chromecast support is already built in
everywhere, but of course that's a non-starter since Google have locked
everything down sufficiently to prevent implementation of a receiver. I don't
know the answer to this.

~~~
hackkitten
I do not feel that I dismissed support for 1st party apps in the article. In
fact, I have considered doing so for Netflix and Spotify, among others. Some
have a control API for the 1st party app, such as what is used on Android, for
example.

It's however a lot of work, with spotty documentation and questionable
support. That's why for the first release I haven't really bothered with it
too much and instead focused on the core functionality of streaming audio and
video, and controlling the NymphCast server from the client.

(I'm the NymphCast author)

~~~
kingosticks
> In fact, I have considered doing so for Netflix and Spotify, among others

I must not understand because my argument is that the support absolutely must
be built into the netflix and Spotify apps themselves, that seemless
integration is what makes chromecast so usable. The media discovery and
control needs to be in their app, not split between two different apps. So
what can you do, other than provide a library for Spotify and Netflix to then
ignore?

~~~
hackkitten
My apologies, I thought you were talking about the server-side.

On the client side having it integrated into the 1st-party client apps would
be great, yes. Right now in the SoundCloud app I implemented a basic
track/album/author search function that uses the server-side app to search
through the SoundCloud database.

Though barebones right now, it provides essentially the same functionality as
using the SoundCloud website directly. I can imagine this approach working in
a generic fashion, assuming some network-accessible API is available that
provides this information.

~~~
kingosticks
The problem is that you end up trying to reimplement the functionality of
multipe 1st-party apps. Each of these different providers has their own API
with its own issues. You'll never do as good as job as the 1st party client,
and that's assuming they even give you API access (tidal don't provide a
public API, Spotify's API is a subset of the functionality, others impose rate
limiting etc). The only scalable solution I can see is to have service
providers integrate your tech. But how to get them interested?

Don't get me wrong, I think this would be a great thing to have and I'd love
to get involved. For audio playback there is Mopidy (I'm a maintainer) which
provides something similar but it would be so much better if there was a open
chromecast-like protocol we could hook into and integrate into 1st-party apps
rather than requiring the use of our clients.

~~~
hackkitten
Maybe you misunderstood me. I have made available a client SDK that will allow
anyone to create a NymphCast client with accompanying app on the server.

I have intentionally made this the same as things work with ChromeCast.

~~~
kingosticks
Apologies, maybe.

I understood it that I can't use the actual soundcloud app with all its
functionality that I'm used to. The same app I use when I'm playing music on
my phone. I have to use your client app as that's the one which includes
support for nymphcast. That's your client app where you've re-implemented some
subset of the functionality I want. Soundcloud could integrate the nymphcast
client sdk into their app and then I'd have the same experience I get now with
chromecast, but why would they do that?

~~~
hackkitten
The plan is to get NymphCast into a 'good enough' state, before sending an
inquiry off to various services to see whether they're interested in getting
their service on NymphCast.

As they say, you already got the 'no', so why not try to get the 'yes' or
'maybe'? :)

~~~
kingosticks
I admire your positivity and it's inspired me to take another look at where I
left my (audio only) attempts. I sincerely hope you prove me wrong with
getting streaming providers onboard.

For what my failed experience is worth, try getting some internal contacts at
these companies. The public, and even "developer", contact channels for
Spotify, Soundcloud, Tidal and TuneIn are a dead-end. At least, that has been
my frustrating experience. Presumably if you throw them money they take you
more seriously.

~~~
hackkitten
Yeah, there does have to be something in for them, even if it's just positive
PR which they can cash in for more subscriptions or such.

------
stevehawk
If you're an Android user there are alternatives to Chromecast.

I use Roku devices + Samsung's 'SmartView' which I'm pretty sure is just
rebranded MiraCast and it works like a champ.

~~~
bgorman
The biggest joke is Google removed Miracast support from Pixel phones

~~~
hocuspocus
It happened way earlier than Pixels. The Nexus 5 is the last device that
supports Miracast.

------
worldsayshi
Instead of talking vendors into supporting your particular protocol, wouldn't
it be possible to use a protocol like picture-in-picture to extract the video
stream?

[https://github.com/w3c/picture-in-picture](https://github.com/w3c/picture-in-
picture)

I guess it doesn't handle the audio though.

------
k__
I tried to get some streaming going on a spare monitor a few years ago.

Miracast and Chromecast were a garbage fire. In the end I only got AirPlay to
work and even that wasn't without problems.

------
BlueTemplar
How does one deal with mp4 being proprietary?

------
isuckatcoding
This is fantastic

------
aogl
This seems like a very unfortunate name..

------
deno
Miracast is much more straightforward and predictable and with 801.11ad you
can even go lossless. Also you can get an HDMI receiver for like $15, because
it’s just streaming instead of a full stack.

Chromecast will go of the way Google’s many Dodos. And good riddance!

~~~
remir
It depends on the use case, I guess. Miracast is good for quick sharing of
content stored locally on your phone/laptop, whereas Chromecast is better
suited to stream content that is hosted elsewhere, so it doesn't drain your
battery.

~~~
deno
That’s a single use case and you can just reverse it and have a ‘remote
control’ mode on the portable device.

In practice people are now buying Telescreens (not like there’s option tbh)
and they have Android or at least Netflix already built in.

------
vzaliva
Good project, but unfortunate bad choice of technologies (C++, AngelScript).

~~~
makapuf
Good and bad are relative and subjective. Can you elaborate why those are bad
and what better offerings there are and why ?

------
Krasnol
I have two of them and I hate it. I hate having to use a chrome browser to
stream online streams. Vivaldis last version just crashes on fullscreen tab
cast. Installed Chromium, it wouldn't find any of the Chromecasts. VLC finally
supports it but sometimes it's not working or you can't hit pause and resume.
It'll just stop and you have to start from zero. Also it's doing things online
I have no control over.

I'd be so happy to have an easy open source solution. I'm ready to spend some
money on it too.

------
amoshi
So many letter combinations in the world and they went for "Nymph"Cast? Like
Nympho (Nymphomaniac)?

~~~
ipnon
A nymph is a supernatural female diety in Greek mythology associated with air,
water and wood.

~~~
thwave
It also just means "a young wife", or "a marriageable maiden" in ancient
Greek.

