DIY streaming with WebSockets and Matroska
Not using it would under perspective projection.
All content should be obvious.
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.
By convention variable declarations except for TEMP s should be done between simulating and rendering.
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.
- Many times you will get the identity of rotation.
- 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.
In each technique we have reached true 3D.
If the best thing for the job is cPanel, then you know it's bad.
