Categories
Tech Explorations

RTMP systems for multistreaming

Given the current events, livestreaming has become an enticing alternative for giving some continuity to many activities that otherwise would not be possible during these difficult times. However, creating a professional quality setup for broadcasting live events is quite a challenge, especially because until just about a decade ago, the idea of creating a live TV studio in your bedroom was ludicrous to say the least. If you’re working with large groups of people, consider it a powerful tool to reach out to your audience.

This post is going to narrate the hoops I went through in the process of creating such broadcasts with professional quality and a relatively friendly budget in mind, as well as explaining a bit how livestreaming works, and how everything ties together for creating both creative and functional livestreams.

I: The gist of it all

Pretty much every social network worth its salt has some sort of livestreaming capability built in, ranging from the gimmicky to studio quality. For the purposes of this article, we’re going to be focusing on three: Facebook, Instagram, and YouTube, as they’re the ones I usually broadcast in.

  • YouTube is pretty much a pioneer on the subject, introducing one of the first livestreaming services available for everyone to use, and has pretty much everything nailed down at this point, providing a stable and reliable platform for pretty much every scenario.
  • Facebook also has a pretty solid platform for livestreaming, and it’s a personal favorite of mine because it will process and transmit pretty much everything you throw at it.
  • Instagram is the most frustrating one to work with, as it does not officially support broadcasting outside of its mobile app, and as such provides plenty of head scratching and hair pulling during the setup process.

Regardless of platform, pretty much every livestreaming service out there works using the Real-Time Messaging Protocol (RTMP), originally developed by Macromedia and now maintained by Adobe. The standard is (mostly) open and it works great, so it’s to be expected that everyone is using it. However, it does not specify a video standard per se, so you can send pretty much anything you want (this will be a problem later). RTMP works by using a streaming server address and a streaming key to connect and begin the transmission, which are different for each platform and are provided by them when you begin a livestream. Depending on the site, the stream key changes for each stream or after a set time, be mindful to keep them up to date.

For any livestream, there are four basic links in the chain that make it work. The chain is only as strong as its weakest link, so all of them must be reasonably balanced to get good results; these are Capture Hardware, Video Processing, Restreaming and Internet Connection.

II: Capture hardware

This is the first link of our broadcast chain, and involves everything needed to capture video and audio data that will go in your livestream. Integrated webcams are the default (and sometimes only) option for many people, but I decided against them mainly because of their poor quality; low framerates, issues with exposure, noisy output, etc. Modern external cameras like the ones offered by Logitech are a good alternative -ignoring the cheaper ones which often suffer from the same issues- you can easily get 1080p at 60fps with them, but since I don’t own one, I went with my preferred method, a video camera and a capture card.

For this method you can use whatever camera as long as it has a clean video output (avoid the ones that show all the controls and menus through the video output) and whatever capture card capable of processing the desired resolution. In my case I used a Panasonic HDC-TM700 portable video camcorder and an Elgato Game Capture HD USB capture card (a beaten old warhorse, and a story for another time.). Both are over five years old at this point, but I can still get a clean and reliable 1080p/30fps video into my broadcasting software with no issues. Both companies offer newer products that can be used instead, and as long as you have a compatible setup, you’ll be fine with whatever you can find.

For audio capture, you can use the audio straight from the camera’s microphone or, as I did, use an external audio interface to plug in dedicated microphones. I used a M-Audio Fast Track C600 audio interface (which I actually got for free, I’ll write about that adventure at some point) which works great, but requires a bit of a workaround, as probably most multichannel audio interfaces will. This gave me a clean sound and four mic channels for plugging whatever I want.

III: Video processing

Now that we have all the AV equipment set up its time to set up the software. I use good old OBS for it, because it’s light on system resources (a must for me running it on a laptop) and pretty much endlessly customizable. This is not a tutorial on how to use OBS, -and there are many of them out there who could explain it way better than I ever could- but it’s basically a video editor but live. you can have different scenes and switch between them, mix different audio sources, capture windows or screens, add text and graphics, and much much more. For me, I also had to install the Elgato Game Capture app which includes the drivers for my capture card, which work right out of the box with OBS as a video source. I also installed the OBS ASIO plugin to connect to my audio interface, as it provides low-latency and stable performance (drivers for de C600 are a bit janky, and ASIO gave me the least glitches.). For multichannel interfaces this is a must, because while OBS supports 2+ channel audio, it will not give independent control of each channel without it. I also added a window capture, which worked perfectly too (although beware if you have switchable graphics when capturing screens/windows, they are known to be a pain to set up).

Before we move on, we need to talk about video resolution aspect ratio. Because RTMP does not specify said parameters, each platform works in its own way, and has its own set of rules. Facebook is the most forgiving of all, allowing pretty much any resolution at whatever aspect ratio, vertical or horizontal. YouTube on the other hand, will only work with horizontal 16:9 video, and will complain about any resolution other than 1920×1080 (although it will still work), filling the screen by scaling up the video stream if it doesn’t match with the widescreen aspect ratio. Instagram will do the same, only this time it exclusively supports vertical video, and will scale up the video if you give it anything other than 9:16 video, losing everything but a sliver of video. For my setup, horizontal video made the most sense, so we were careful to frame the most important parts on that small sliver, but we still lost some important parts of the video. It might be possible to reprocess the video to remediate some of these issues, but not having the entire frame on Instagram was a reasonable compromise for me.

IV: Restreaming

As the title implies, we want to do multistreaming -also known as simulcasting- which means to transmit to multiple platforms at the same time, a task which OBS does not handle natively (you can run multiple instances of OBS with the -multi argument, but video capture devices and webcams will not allow you to use more than one stream at a time). A few comercial alternatives are available to solve this issue, such as Restream.io which is free for some platforms (but not for Instagram, which was a dealbreaker for me) and a limited number of streams. This left me with the predicament of having to set up my own restreaming server.

For this task I used NGINX, a ubiquitous, open source web server software which is -depending on who you ask- the most used web server on the Internet. Fortunately for me, someone had already made an RTMP module for NGINX which worked perfectly (all credit goes to this amazing post on the OBS forums detailing how to make it work). I ran the server on a Raspberry Pi 3B+ which was more than enough to make it work (the restreaming server doesn’t do any sort of processing, it just forwards the incoming stream to the desired servers). In theory you could run it on the same machine used for video processing, but I found NGINX for Windows to be very confusing and difficult to install, whereas the Linux (Raspbian Lite) install and configuration was very simple and straightforward.

Remember when I said that every streaming server used the same protocol? Well, that’s not entirely correct. While it’s true that all three platforms use RTMP for moving the stream around, only YouTube uses the standard protocol on port 1935 (the default port for RTMP), while Facebook and Instagram use RTMPS, which is just the standard RTMP protocol over an SSL tunnel on port 443. This complicated matters a bit because the RTMP NGINX module does not support RTMPS natively, so we now need to encapsulate the Instagram and Facebook video feeds on a secure tunnel.

This is where STunnel comes in. STunnel works as an SSL/TLS proxy, grabbing whatever data we throw at it and encrypting it before sending it back on its way to the target servers. This page helped me get it up and running with NGINX. Now that all the protocols are in order we can actually attempt a connection with the servers.

V: Internet connection

Now that everything is set up on our side, we need to connect to the streaming platforms. Before that though, make sure you have a stable internet connection (Ethernet is your best choice here, Wi-Fi can be very unstable and low speed in certain scenarios), and that your upload speed is greater than the OBS transmit bitrate (2500 kb/s by default) times the amount of streams you are going to simultaneously stream to.

For exact instructions, follow the tutorials listed above or check de OBS forums for help. For Facebook and YouTube is just a matter of copying and pasting the stream keys from their respective streaming menus and you’re on your way, but once again Instagram is going to put up a fight. For one, as we said earlier, Instagram does not officially support RTMP streaming, so we need to use software like YellowDuck that will trick Instagram into believing that it is receiving an RTMP transmission from a phone, the actual supported and official way of doing it. A quick note on any software or website designed to to this: logging in is very finicky. Test the stream beforehand with the actual account you want to use, to avoid screw-ups when the real time comes.

VI: Closing thoughts

After reading all of this, you might feel livestreaming to be a near impossible task but remember, most of the setup required has to be done only once, weeks in advance. after that is just a matter of keeping the stream keys up to date and making sure everything is working.

In dire times like this, streaming often brings a sense of community that not many other technologies can provide. It allows us to see a face, to feel like we’re part of something bigger. If you are in charge of anything that deals with people, please try to introduce it as a new way of reaching out to people, even after all of this is over. Good luck and happy streaming!

Categories
Tech Explorations

An Introduction

Hi! My name is Benjamin, and I’m an engineering student and overall tinkerer, maker, and explorer from Chile. This blog is going to be a place for me to present to everyone my projects, workarounds, and other interesting tidbits of my journey of making things work.

It’s probably not going to get updated very much, I don’t get to do projects worthy of a write-up very often as I’m still pretty much on the meat grinder at university, so free time is scarce. I may also write about other subjects of my interest, as long as they are at least tangentially related to the topic of the blog.

I’m also very open to chat, so drop me a line at my contact page if you want to get in touch and/or ask questions about my projects. Expect the occasional typo and odd sentence, as english is not my first language, although I’m somewhat fluent.

Cheers!