Setting up stream

Last week, I was rather busy setting up my stream setup for BugsDoneQuick, the livestreamed event I'm organizing for July 6-13, where I will be fixing FOSS issues in projects I don't know, as fast as I can, in front of an audience.

(NOTE: Earlier versions of the BugsDoneQuick announcement post incorrectly said the livestreams would start at 14 UTC instead of 8 UTC. This has been corrected; check the announcement post again for the updated schedule.)

The project is still an experiment, as I want to gauge how useful working on-stream is for me and what kind of audience I might expect. If you want to see how it looks so far, here is a recording from a practice session I ran on June 23, where I spent two hours to find and fix a bug in KDE's file manager, Dolphin, which stemmed from one line a previous contributor replaced by mistake.

There is a lot that goes into a livestream of any kind:

• There is the content, deciding what to stream, for which I've picked open-source software contributions, but might end up changing if there are better topics out there.
• There is the technology, figuring out how to stream things, which is what I will be discussing in this article.
• There is the marketing, getting your stream in front of people, which... I wish I was more effective at.
• There is the public speaking / performance, delivering the content to the audience, which I'm currently learning, and might pen an article on later.
• And, there is the mental energy aspect, making sure you don't burn out while delivering content, which is something I suspect I would have more to say about once I'm finished.

At any rate, this article will be discussing only the technology. There are a myriad of articles titled "How to start streaming"¹ which cover only the technical side of things, so instead of a guide, this article is going to be mostly about how I did my setup.

The setup, V1

I usually do all my work on a Desktop PC/tower, that I sort-of inherited from a colleague in a time long past (long story). It has a good bit of RAM and a good CPU, but I doesn't have a GPU and for some reason I never got hardware video encoding to work on the CPU it's got.

With a slightly fancier microphone and camera and a fancy desk-in-corner home office setup, I used that machine to record medium-quality videos for my Bulgarian programming course. However, using it for streaming would be impossible—there is no way it can encode video fast enough to stream, and if I do any coding in compiled languages, the compiler will be competing with the livestream for same scarce CPU resource.

As such, while that tower is the best machine I've got for coding and work, it is also not the machine I'd use for streaming anything. I could probably get something out of it if I installed a GPU, but considering that this would involve swapping power supply units, I might as well rebuild the whole machine, and hey, I already used that excuse to nerd-snipe myself into optimizing how it uses its SSD before, so that's a no-go.

Instead, I decided to use the somewhat more modern laptop that I otherwise use only for traveling, since it can actually use hardware video encoding. The idea was to use the laptop for streaming, while using the desktop tower for compiling code.

As such, the initial setup started gathering form...

The first version of the stream setup involved moving all input and output devices over the the laptop, so that I can edit files on the laptop and stream myself editing them. I used the laptop's own screen to hold everything related to the stream (things like OBS (the recording software), the timer, any chats, and so on), while using the main screen, that I disconnected from the tower machine, for things that I'm going to stream.

Of note is the Ethernet connection between the two machines. Streaming requires a stable internet connection, so using any kind of WiFi is right out. Yet, I have only one Ethernet cable coming into the room, even if I now have two machines. I could in theory connect the tower machine (which is not streaming) through WiFi using USB tethering from a phone, or I could also run an extra Ethernet cable, but I wanted to see how far I can push things with what I had lying around, so ended up sharing the Ethernet connection from the laptop to the tower machine.
Thankfully, NetworkManager supports connection sharing out of the box, so it wasn't too much hassle to set it up. Hooray for the prescience of open-source developers elsewhere! 😂 🎉

From there, it was a matter of figuring out how to compile things on the tower PC while still having my text editor open on the laptop.

Initially, I thought I have all the projects on the laptop, edit them locally, and use distcc to send them over to the desktop for compilation. The nice thing about that is that it would let the laptop also contribute some of its own spare CPU cycles towards compilation, which would be even faster than the desktop working on its own. The not-so-nice thing was that, for some unexplained intricacy of the connection between the two machines ("cobbled-together Ethernet network from spare parts", anyone?), the whole process ended up bottle-necked by the internet connection and not by CPU speed, and as a result the compilation process was super slow.

Second thought was exposing only the source files from the laptop to the desktop using sshfs, but that was doomed to fail, since it was bottle-necked by that same Ethernet connection. I didn't even wait around for compilation to start; as soon as it hung trying to figure out which files it had to compile, I knew it was going to be slow.

Finally, I ended up moving the projects' source files to the desktop, and used sshfs to open them on the laptop. It was not ideal, but at least the text editor doesn't need to read all the files in the project, so it was manageable. Unfortunately, copying the built binaries back to the laptop to run them ended up slow itself, but it was the best I had.

I ended the test stream after playing around with OBS's source code, and called it a day.

And then came around HDMI capture cards.

The setup, V2

In one of my finer moments, I realized that if I want to get the picture from the desktop machine to show on the laptop, I could use an HDMI Capture Card—a kind of device which takes in an HDMI cable and exposes it almost like a webcam to the computer over USB.
I've never used or owned one before, and considered them only as a curious demonstration of the inefficacy of certain types of DRM, but it turns out, there is a rich history of people using capture cards to livestream games! Various console like the PlayStation-s, XBox-s, and Switch-es, all have very limited software options, so you can't really run your favorite live-streaming software (OBS) on them; plus you wouldn't want it competing with the game for CPU and GPU time. Instead, you can just take the HDMI output from the console, route it through a capture card, and stream that to your audience!

Inspired by that, I bought myself a cheap capture card (one of those unbranded ones that say "4K Ultra HD USB 3.0 HDTV Video Capture", though I have strong suspicion it is some kind of knock-off) for about €22, and hooked it all up into the new setup:

And it works much better! I still get to do the whole dance with Ethernet, as well as with reattaching cameras and microphones between the two devices; however, there is now no delay between me editing a file and being able to compile and run it, since everything important happens on one machine. Also, I don't need to run sshfs which makes the setup is a lot less flaky overall.

I was worried that the cheap capture card might somehow end up corrupting the image. It ended slightly making all colors orange-ish (I suspect it is because color correction gets applied one extra time between the desktop and the capture card), but it is hard to notice that on the actual stream; so, success!

One thing I missed in the new setup is the ability to use my mouse and keyboard to edit things on the laptop. Granted, I could reach out to the laptop's own keyboard; however, it is far less comfortable.
Thankfully, I found rkvm, which is a tool for sharing input devices between Linux machines (through uinput). I'm still perfecting that part of the setup; but now I can easily switch between using my keyboard on the laptop or on the PC with just a keypress.

Software

The article so far clears up the hardware aspect of streaming.

Software-wise, things are a lot simpler.

Like everyone else, I use OBS for setting up the "scenes" of my stream, switching between them, and well, streaming in general. On top of that, I use LiveSplit One for setting up a timer for "speedrunning" purposes (why that matters, you can, of course, find in the announcement article).

For the server which then broadcasts the stream to an audience, There are a lot of well-known services like Twitch or YouTube Live, which would broadcast the stream for you—if you don't mind subjecting yourself to "the Algorithm". However, all of those platforms are proprietary, and "free software needs free tools", so it wouldn't make sense to use one of them for an open-source stream.

Instead, looking at the current popular self-hostable open-source options, I could use either OwnCast or PeerTube. After some deliberation, I decided I want to experience the current state of PeerTube, so I signed up on the MakerTube instance, and now I have a channel there!

Conclusion

Aand.. that's it for now! I hope you found at least some part of what I described about my stream setup interesting, or perhaps even useful, in case one of the tools I mentioned is useful to you.

If you want to see the final result from all of that setting-up-stream work, you can check out this Monday's practice session, or check the event schedule to try to catch me live on stream!

This is my 14th post of #100DaysToOffload.