What does HackerNews think of nginx-rtmp-module?

If stuck for a server I've used this in the past. nginx with an RTMP module.

Also linking a config file I commented for an example. Unsure if it'll still work and it could definitely be simplified for OP's needs. It was a proof of concept for a streaming service I was thinking up before realising how much money I don't have, haha

https://github.com/arut/nginx-rtmp-module

https://gist.github.com/cohan/7f676d3f561be62d0550785c015f00...

I have a pretty low-latency setup for that but it wasn't completely turnkey. First you set up nginx with the rtmp module[1]. Then you can use OBS to stream your desktop to the RTMP server. I set OBS to send a keyframe every 1 second.

On the client side you have two options:

1. For low-latency game streaming, I would suggest watching through the RTMP stream. The RTMP module for nginx will re-broadcast your RTMP stream to all the clients that connect. I was able to get a latency of around 1 second by watching through:

   ffplay -fflags nobuffer -loglevel verbose rtmp://my-servers-ip-address/live/test

I would expect better latency from a webrtc solution like Lightspeed but 1 second latency is pretty good for only having to install nginx.

2. HLS/Dash. The nginx RTMP module will also expose the video stream as HLS/Dash which is just cutting the stream up into files and serving them over http. Personally I set my segment size to 1 second and my playlist size to 4 seconds. Through this I get approximately a 4-second latency. Not great for competitive multiplayer games like Jackbox but if you're playing something like a world building game with friends then its acceptable. The real benefit to HLS/Dash is you can easily watch it through an html5 web video player or even a chromecast[2].

Bits you can add on top:

- I put my HLS/Dash directories in a tmpfs mount for speed and reduced wear on the drives

- I put the nginx stream module in front of my rtmp module so that it can handle TLS (making it RTMPS)

[1] https://github.com/arut/nginx-rtmp-module

On FreeBSD it was just a checkbox in the nginx port, so the work involved may vary by distro.

[2] I haven't attempted to play the RTMP stream through chromecast so for all I know, that might be supported too. All I've tested so far on chromecast is an HLS stream using the "castnow" CLI program. The Shaka player, which is a web player, will support chromecasting an HLS stream from your browser but I've only tested their demo videos, not my personal streams, and I had to use official google chrome, not chromium, but it worked on both android and linux.

The source is available here under a BSD style license: https://github.com/arut/nginx-rtmp-module

I don't know the paid/OS history of the module but all I had to do to get it was check a checkbox on FreeBSD since it was configured as an option in the port.

Some great points! I built a project similar to this (think online lectures but it never went anywhere) in spring when the pandemic hit. I highly recommend building a platform like this if you have some spare time. It involves lots of interesting engineering/architecture challenges all over the stack. IMHO, from a technical viewpoint, it's mostly integration work, as all the really hard parts were already done by excellent 3rd party tools and libraries. You'll probably have some kind of RTMP bridge (nginx [1]), wrap ffmpeg for transcoding and play it back using something like Shaka player [2] where the segments are being served by some kind of caching reverse proxy. It took me a few weeks to get a prototype running inside a K8S cluster where oAuth-ed users could publish RTMPS streams which could be watched by other authed users via HLS in a somewhat scalable way. It was surprisingly easy to build this using Elixir/Phoenix LiveView. Some thoughts on your comment:

> - Probably the hardest part of running these things is managing outbound bandwidth costs.

This. As others noted, you may be getting around this by using something like Hetzner's/Scaleway's/OVH's offerings. However, I think they won't be too happy if you really use that much bandwidth all the time. You can probably forget using IaaS of one of the bigger cloud platforms unless you negotiated some special terms.

> - You'll almost certainly need admin and moderation tools soon.

That's one of the main reasons why I did offer a public instance. It's probably best to host a platform like this in a non-public context such as members of a single org. Just look at what happened to Firefox Send...

> - Please don't keep using RTMP [...] and its security is, uh, _weak_.

Yes it is a bit of a pain to work with but AFAIK you can wrap RTMP inside a TLS session which is supported by OBS. I think I just exposed a stunnel instance back then which forwarded it to a nginx instance which handled auth/auth and forwarding to the transcoding backend. This way you won't leak any streaming keys or video data. Please correct me if I'm wrong. If you have any additional pointers regarding RTMP security, I would be highly interested!

Also, as others pointed out, SRT may be just around the corner. I think we're in for some interesting times as LL-DASH/CMAF and similar technologies are more widely supported. Additionally, there are interesting projects like [3] going the WebRTC route for delivering low latency streams.

[1] https://github.com/arut/nginx-rtmp-module

[2] https://github.com/google/shaka-player

[3] https://www.ovenmediaengine.com

You can license x264 to not have to worry about the GPL. Though that costs money and you may find yourself signing MPEG LA contracts.

edit: Your project reminds me, https://github.com/arut/nginx-rtmp-module is super worth checking out and might be helpful to you.

I don't know exactly what you mean, but I would use something like this: https://github.com/arut/nginx-rtmp-module

Have a look at what we use at https://fosdem.org [0][1]. In terms of software, a crucial component is voctomix [2], using it as a headless video mixer. Another invaluable component is nginx-rtmp [3] for streaming.

We made a heavy push to get all of this packaged in Debian. It's a surprisingly powerful combination.

[0] https://github.com/FOSDEM/infrastructure/tree/master/ansible... [1] https://github.com/FOSDEM/video/blob/master/instructions/FOS... [2] https://github.com/voc/voctomix [3] https://github.com/arut/nginx-rtmp-module/

> Streaming with a custom built NGINX instance? This person is one of maybe 3 in the world that can actually make this work.

From a cursory look, it looks like he is using nginx-RTMP - one of the most widely used streaming solutions out there: https://github.com/arut/nginx-rtmp-module + ffmpeg

If you know Linux - shouldn't take more than 5-10 minutes to set it up.

Personally, I use the nginx-rtmp module [0] a lot, but building nginx for that isn't too much of a hassle.

[0]: https://github.com/arut/nginx-rtmp-module

I can't edit my original reply, apologies for a bit of an offtopic tangent. This fits your project's requirements: https://github.com/arut/nginx-rtmp-module

You'll either want to push your HLS segments to S3 or a CDN if you want to persist them, or serve them directly off Nginx, depending on your audience size.

Check out nginx-rtmp [1] and ffserver [2] (from the ffmpeg team).

[1]: https://github.com/arut/nginx-rtmp-module

[2]: https://www.ffmpeg.org/ffserver.html

There is on open source a Nginx module that streams RTMP and creates HLS segments that looks promising: https://github.com/arut/nginx-rtmp-module

There are also red5 (http://www.red5.org/) and rtmpd (http://www.rtmpd.com/)