Analysis from our broadcast on Saturday: Part 1
First off, a huge shout out to the Distinguished Young Women of A-C-H for allowing us to utilize the circumstances on Saturday to work on the new technology we are using for point to point broadcast, SRT (Secure Reliable Transport). We were hired to produce a DVD of the production and took the opportunity to try out the technology under fire.
What makes SRT such a wonderful technology is the ability to stream video through congested and variable networks.
On Saturday, the only source of internet available to us to use was cellular service. Cell service is notoriously unstable when it comes to streaming because the traffic is very congested and you can have dropouts.
Now, since this our first time under fire working with this technology in a production setting, we offered it for free because I knew it would not be great the first time out. We learned a ton from the experience as we encountered variables that you don't normally think about.
Yesterday, I was able to work in the studio replicating what we encountered. This will be a week-long series talking about our results. That's how positive of an experience this was for us. Today, we will dive into the bitrate issue and what we learned.
Extremely Low Bitrate
So, on Saturday, we were encountering a bizarre situation of extremely low bitrate for our pipeline. We were only working with bandwidth of 0.4 MBps maximum. In most circumstances, we would not have even been able to get a stream off the ground.
RTMP streaming is the broadcast transport for sending a stream to such services as Facebook and YouTube. RTMP needs a decent pipe to be able to stream, and will notoriously disconnect if it has a dropout or inconsistency (i.e. packet loss, bitrate shifts).
The approach we took with the broadcast is reminiscent of what you see on TV with satellite uplink to the station. Station then originates the broadcast on its networks for our consumption.
Using SRT, we used a similar technique of point-to-point to our studio. The video and audio was transported to our studio, and from the studio we sent the stream out to the masses via Facebook and YouTube. So our bitrate for our stream was a high quality 5+ MBps broadcast, which is excellent for broadcasting.
Now, we are dealing with an incoming stream that is only 0.4 MBps maximum. This creates several pitfalls as it only allows for a thin margin of error on the broadcast side.
In calculating an SRT setup, you have to factor in three things.
Ping Time or Real Time Transport
What your bandwidth is available.
From this three instances, there is a series of calculations that takes place to determine certain settings from this information that are key to delivering a smooth broadcast. Those are the values of your latency, your bitrates, and your maximum pipeline.
Once, you have these numbers in place, you can setup your SRT stream.
Now, we learned a few lessons in this environment changed our approach to finding out this information more accurately, because, like I said, our margin of error is low.
I found an app yesterday for $24 on the Apple App store that helps measure these quantities for us the best. On Saturday, we were using a free app that I had been using for years for streaming and I discovered that it doesn't do enough to be able to give us good numbers for streaming SRT. The app is called SpeedTest Master by Spring Tech Co.
What makes this app perfect for this application is it gives me more accurate numbers for cell and low bitrate circumstances.
One such number is a realistic ping time. Speed Test by Ookla is a great app, but it only gives me ping times to the nearest network head or cell services originator. In case of Saturday, that was AT&T in Bothell. By the way, we didn't get any better numbers on other services either so you know.
With the SpeedTest Master, I am able to ping my IP address directly. This is key as I am doing a point-to-point transport to my decoder, not to a cell provider. This was a realization I didn't think about until we were under fire.
The other item that this app helped us to be able to leverage is a packet loss rating. When using cell technology, you expect some sort of packet loss as the network is usually congested or unstable. While you are pinging the decoder in my studio, it lets me know if that direct connection is actually giving me a packet loss issue.
In concluding today's analysis, I want to say, that if we didn't leverage this technology, even though we were in the process of learning how to use it in extreme circumstances, without it we would not have been able to share that event on Saturday for the people who couldn't attend due to COVID-19 precautions live.
The next opportunity we have to use this technology in those circumstances, you will see a huge difference. We are looking for that opportunity to show how our work is creating the Skeeterbuggins Difference!
Interested in having us do a project in a remote setting and want a broadcast added on, we are looking to partner with you so we can work more on getting this more and more refined! Contact us today!