--- title: "Custom Streaming Setup" description: "My second post of 100 Days To Offload details my custom streaming setup" author: Amolith date: 2020-04-26T20:24:38-04:00 draft: false cover: /assets/pngs/stream.png categories: - Technology tags: - Gaming - Streaming - NGINX - OBS - 100 Days To Offload toc: true --- The other day, I decided that I wanted to start streaming. I'll definitely be playing some games but I might also stream some other things like me playing music. We'll see where that goes. In any case, I don't like relying on third parties for things and didn't want to use Twitch so I started figuring out how to build my own open source and privacy-friendly "platform" (which is really just a [page.](/live)) ## The search for a platform Before settling on my own custom thing, I did some digging into ready-made platforms I could just throw on one of my servers and run. Two of the ones I found were [OpenStreamingPlatform](https://openstreamingplatform.com/) and [Restreamer.](https://datarhei.github.io/restreamer/) The latter isn't exactly what I was looking for but it could have worked quite well. The former, at first glance, was absolutely *perfect*. On a functional level, it still is. However, take a look at [the installation guide.](https://wiki.openstreamingplatform.com/Install/Manual) `` Steps 3 and 7 are unnecessary unless you feel like manually compiling your web server; it's already available in the [Debian repos](https://packages.debian.org/buster/libnginx-mod-rtmp) and, by extension, Ubuntu's. It's even been backported to Stretch. In step 4, he has `sed -i 's/appendfsync everysec/appendfsync no/'`. Like so many application developers, he's assuming that this is the only project that will be installed on the system. If someone is already using redis in production and they have a different value there, that command will fail. In step 9, the commands are copying the SystemD service files to `/lib/systemd/` but this is where the package manager, `apt`, stores its services. When you have your own that you're writing or copying from somewhere else, best practise is to put them in `/etc/systemd/system`. In addition, all of this is scripted for the "standard" install. Yes, you're always supposed to review scripts before running them but who really does that? When I see a project whose only supported installation method is a script, I nope right on out of there for exactly this reason. I know how my system *is* set up and I know how I *want* it set up. I can't stand it when they assume they know what's best. Just tell me what you *recommend* and I'll make decisions from there. `` ## NGINX & RTMP RTMP stands for [Real-Time Messaging Protocol](https://wikipedia.org/wiki/Real-Time_Messaging_Protocol) and facilitates streaming audio, video, and other data over the internet in real-time. The NGINX module mentioned above adds functionality to NGINX that allows it to handle RTMP streams and turn them into something a browser or media streaming client can use. Connecting directly via `rtmp://example.com/live/stream` is not very widely supported so protocols such as [MPEG-DASH](https://wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) and [HLS](https://wikipedia.org/wiki/HTTP_Live_Streaming) are used instead. On Debian-based systems, adding RTMP functionality to NGINX is as simple as `apt install libnginx-mod-rtmp`. After that, you'll need to add some things to your `nginx.conf` and whatever host file you're using for your website. ``` c rtmp { server { listen 1935; application live { deny publish all; allow publish 127.0.0.1; live on; interleave on; hls on; hls_path /tmp/hls; hls_fragment 15s; dash on; dash_path /tmp/dash; dash_fragment 15s; } } } ``` `1935` is the default RTMP port. `deny publish all` means you are denying *anyone* from publishing a stream (that includes you. `allow publish 127.0.0.1` allows *local* connections to publish content. I'm using this as a form of authentication---before streaming anything, I have to tunnel my connection to my server via SSH or a VPN. At the moment, I'm using SSH: ``` text ssh -L 1935:localhost:1935 user@example.com ``` The other options are just the basics needed to get DASH and HLS to work. The only other thing to do is use NGINX as a reverse proxy (sort of) to serve the streams. Add this to your site's virtual host. ``` c location /dash { root /tmp; } location /hls { root /tmp; } ``` That's it! Now you'll need to test your stream and verify that it actually works. ``` bash ffmpeg -re -i video.mp4 -vcodec copy -loop -1 -c:a aac -b:a 160k -ar 44100 -strict -2 -f flv rtmp://example.com/live/stream ``` This command has FFmpeg play the video and stream it to the server. You should then be able to open the stream in something like [VLC](https://www.videolan.org/) or [MPV](https://mpv.io/) and watch it from anywhere. ``` bash mpv https://example.com/dash/stream.mpd ``` However, I also wanted to embed it in a website and this is where it gets a little unstable. ## Browser playback `dash.js` is currently one of the best ways to play a live stream in a browser plus it's pretty easy to work with. The code can be found [on GitHub.](https://github.com/Dash-Industry-Forum/dash.js) Using the setup with NGINX I detailed above, this should work perfectly fine out of the box. ``` js
``` ## Web chat The last thing every stream needs is something for web chat. I tried a few different solutions and had mixed results. The first was [KiwiIRC](https://kiwiirc.com/) but the iframe wouldn't even finish loading because it connected to so many third parties with a lot of tracking. It functions very well and I might set it up on my own site eventually but it was a bit much to go through at the time. As an intermediate solution, I embedded [my instance](https://irc.nixnet.services) of [The Lounge,](https://thelounge.chat) a fully-functional web-based IRC client. This loaded perfectly right out of the box but it wasn't quite what I wanted; there were *too* many options and the friends of mine who tested it got frustrated because some of the essential UI elements were hidden due to the small viewport. It's just not quite suitable for embedded webchat. Finally, I landed on [qwebirc](https://qwebirc.org/) and it was pretty much *exactly* what I wanted. When the iframe loads, you're prompted to enter a nick, you click connect, wait a minute, and done! My one complaint is that the theme is very bright but I'll work on that later on. It's good enough for now :wink: **EDIT:** Since the time of writing, I have switched to hosting [KiwiIRC](https://kiwiirc.com/) on [Secluded.Site](https://chat.secluded.site) so all of the trackers and third parties aren't in use. My configs are below but I recommend going through [the wiki](https://github.com/kiwiirc/kiwiirc/wiki/Configuration-Options) and making your own decisions. `/etc/kiwiirc/config.conf` ``` ini logLevel = 3 identd = false gateway_name = "webircgateway" secret = "changeme" [verify] recaptcha_secret = "" recaptcha_key = "" [clients] username = "%i" realname = "KiwiIRC on secluded.site" [server.1] bind = "0.0.0.0" port = 7264 [fileserving] enabled = true webroot = /usr/share/kiwiirc/ [transports] websocket sockjs kiwiirc [reverse_proxies] 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 "::1/128" "fd00::/8" [upstream.1] hostname = "irc.nixnet.services" port = 6697 tls = true timeout = 5 throttle = 2 webirc = "" ``` `/etc/kiwiirc/client.json` ``` json { "windowTitle": "Secluded.Site Chat", "startupScreen": "welcome", "kiwiServer": "/webirc/kiwiirc/", "restricted": true, "hideAdvanced": true, "showAutoComplete": true, "showSendButton": true, "sidebarDefault": "nicklist", "theme": "dark", "themes": [ { "name": "Default", "url": "static/themes/default" }, { "name": "Dark", "url": "static/themes/dark" }, { "name": "Coffee", "url": "static/themes/coffee" }, { "name": "GrayFox", "url": "static/themes/grayfox" }, { "name": "Nightswatch", "url": "static/themes/nightswatch" }, { "name": "Osprey", "url": "static/themes/osprey" }, { "name": "Radioactive", "url": "static/themes/radioactive" }, { "name": "Sky", "url": "static/themes/sky" } ], "buffers" : { "messageLayout": "compact", "show_timestamps": false, "show_hostnames": false, "show_joinparts": false, "show_topics": true, "show_nick_changes": true, "show_mode_changes": false, "traffic_as_activity": false, "coloured_nicklist": true, "colour_nicknames_in_messages": true, "block_pms": true, "show_emoticons": true, "extra_formatting": true, "mute_sound": false, "hide_message_counts": false, "show_realnames": false, "default_kick_reason": "Your behaviour is not conducive to this environment.", "shared_input": false, "show_message_info": true, "share_typing": true, "flash_title": "off", "nicklist_avatars": true, "show_link_previews": true, "inline_link_previews": true, "inline_link_auto_preview_whitelist": "secluded.site|nixnet.services", "channel": "#secluded" }, "startupOptions" : { "server": "irc.nixnet.services", "port": 6697, "tls": true, "direct": false, "channel": "#secluded", "nick": "viewer?", "greetingText": "Welcome!", "infoBackground": "", "infoContent": "" } } ``` ## Actually streaming Once you're ready to start streaming content, I recommend using [OBS Studio.](https://github.com/obsproject/obs-studio/) If you're noticing issues with stream performance, play around with your output resolution and FPS---those are the biggest factors. To use OBS with NGINX, you'll need to go to `Settings`, `Stream`, and set `Server` to `rtmp://localhost/live/`. If you're using my configs as they are, the key will need to be `stream`. Literally every component requires specific paths so, unless you're careful, things will break and you'll spend hours trying figure it out like I did. Also don't forget that the connection *has* to be tunnelled if you want authentication as I mentioned above. If you don't have `localhost:1935` on your streaming machine tunnelled to port 1935 on your server, OBS is going to throw errors about not being able to connect. ## Summary I'm pretty proud of [the set up](/live) I have now but it could still do with some improvements. For example, I plan to mess with the CSS and make both the video and chat panes *much* wider as well as side-by-side rather than on top of each other. Everything is crammed together and it's not a very good experience. ## References This post has pieces taken from a few other articles and sites that also deserve a mention as well as a read. NGINX actually has an [official blog post](https://www.nginx.com/blog/video-streaming-for-remote-learning-with-nginx/) on setting up RTMP streaming (though they compile NGINX from source as well) that was a *massive* help. I also found another post that is very similar to this one about [HTML5 Live Streaming with MPEG-DASH.](https://www.isrv.pw/html5-live-streaming-with-mpeg-dash) A good number of the parts are the same but I used the NGINX module in Debian repos and they used a fork of it with additional features. My NGINX setup was mostly from the NGINX blog post and the embedded stream was primarily from Inanity's. I figured out some of the components I could use for all of this from [Drew DeVault.](https://live.drewdevault.com/) --- This was posted as part of [#100DaysToOffload,](https://100daystooffload.com/) an [awesome idea](https://fosstodon.org/@kev/104053977554016690) from [Kev Quirk.](https://kevq.uk/) If you want to participate, just write something every day for 100 days and post a link on social media with the hashtag!