.png)
4 months ago
3
I have tried a few different approaches to DIY streaming. DASH and HLS are both very common. Being file-oriented, they're stable even while streaming through FTP, but the latency is on average around 10 seconds which I wasn't happy with. The Media Source API was another one. It used to be that each chunk of data must begin with a keyframe, but from what I've heard, that isn't necessary anymore.
Still, I liked the idea of full control over the entire software, and this was a nice excuse to use WebAssembly & asm.js. So instead, the whole video stack is in the webpage. A similar thing for MPEG-1 has been done at JSMpeg, a wonderful project that is from a technical standpoint more impressive than what I show here.
The system involves three nodes: you, the streamer, who sends the video feed to a special relay server, which replicates the feed to all of its WebSocket clients. Obviously, there's also the webpage, which can be hosted statically. The main stream is sourced through a chunked HTTP request, authenticated with the stream key in the path.
To the right is an example configuration for OBS Studio. Simply go to the Output tab, select the Advanced mode and head to Recording (no, not Streaming). Most important is to select libvpx or libvpx-vp9 as your video codec, and libvorbis as the audio codec. For whatever reason, FFmpeg's native encoders vp8 and vp9 aren't available in the list. It is necessary to select the Matroska container, as the relay server depends on it.
Matroska is a very simple standard when you ignore most of it. When a Matroska stream begins, crucial information such as the codec types, their initialization data, resolution and sample rate, precedes the main feed, and it's never repeated again. For this reason, the relay must remember this header, and send it to each late client before the main feed. Though Matroska is formed as a tree, you can in practice detect the start and end of a header with a simple byte search. It's not correct, but it works, and it's kept the relay very simple so far.
The chatroom is Converse.js & my self-hosted XMPP server, but any server should work. If you try to join a disabled chat, it will say you are banned. This isn't true; the room just doesn't exist, but I don't think I can change the message without delving into third-party source code.
Problems:
- Obviously, being a standalone service leaves moderation to you. Should anything happen, there's no admins to the rescue.
- My chatroom is configured to allow anonymous participants, which is also problematic. But going the other way, the average chatter is too stupid to register an XMPP account for global use.
- For whatever reason, OBS Studio doesn't like the above mentioned configuration. When turning off the stream, sometimes it works, but sometimes it either crashes or hangs until explicitly killed. So far, nothing has happened to me in the middle of a stream.
- A bigger issue is that the above configuration only fits in the "Recording" section, when people prefer to stream and record a VoD for future use, something this doesn't allow. A solution would be to have the relay also write to a file. After all, the Matroska feed is there, and nothing special needs doing, per se.
- Currently, the relay supports only a single resolution. Otherwise, it would have to do parallel reencodings of the feed in realtime, something that would (without SVC) require a beefy server. It's not impossible, just not cheap, and it's additional complexity.
But on the bright side? Boobies is A-okay 👌👌👌👌
So, should you use this? The latency is quite tight and the protocol extremely simple, but the computational load might be a dealbreaker. If I ever do a stream I would use this, but it's up to you to weigh the pros and cons.
The entire project, MWSS, is available at the following link: https://mid.net.ua/git/mid/mwss/. It's a bit of a mess, since it involves three separate subprograms, but assembling it is not too hard for one with some sysadmin knowledge.
PS. You have no idea how awful it is to get programmatic audio working in the web without cracks and pops.
PPS. My beliefs in distributivism lead me to sympathize with decentralization movement on leaving the likes of YouTube or Twitch and distributing capital of the streamersphere, but most are offly silent on the details in getting there. Like it or not, very few people will go to the effort of setting up a Linux system on a VPS, wgetting source archives, compiling all of them, configuring their reverse proxy, securing their SSH server and so on.
Self-hosting remains very niche. To fix that the following are pretty much nonnegotiable: hosting services must let you rent a server and a domain in a single package; said domain must be automatically configured to point to your host; the server's operating system must come with a public web dashboard already enabled, running and accessible from the outside, thanks to the preconfigured domain; said dashboard should allow you to monitor the system, install or modify any* third-party services of your own choosing and configure the reverse proxy accordingly. In other words, you should never have to use a terminal or rummage in tens of config files.
If the best thing for the job is cPanel, then you know it's bad.
