September 13, 2021
When you preview the broadcast from your ClickBid EventStream account you may sometimes hear or even see a slight glitch or pop at nonspecific points. Here are several reasons why this happens with some suggestions on how to remove or minimize the issue.
UDP vs TCP Broadcasting*
This may not mean anything but it is the difference between how you watch “live” events like the superbowl and “really live” events like a live auction from ClickBid. TCP allows sent video data to be “verified” and ordered when it’s transmitted to a server. This means that if a data packet is lost or missing, TCP will tell the sender that they need to send it again. This creates a delay in handing the data out to people who need to consume it. In our case, this can create a delay in how long it takes data to be available. This is way that RTMP video streams are transmitted. While it reduces any hiccups in the data feed (since it verifies as it goes) it can create a delay over time. Services like YouTube and Vimeo use this protocol.
UDP however does not send any verification or ordering of packets when arriving at their destination. This means that you may get packet 1, 2, 3, skip 4, 5, 6, skip 7, etc. It also means that this data is much faster at being sent to the end user. This is the protocol that WebRTC uses and it’s based on staying right at the edge of real-time. Services like Zoom and Microsoft Teams use UDP. So does ClickBid.
Why Not Use “Verification” Instead?
ClickBid’s goal is to have a hybrid solution where “Bob” who could not attend the auction event can bid against “Bethany” who is at the event without any delay. Even a second or two delay stops Bob from being competitive with Bethany or anyone else at the event.
Have you ever watched a sporting event online while someone else watches it on TV? At some point, you may hear cheering coming from the other room and wonder what is going on. A few seconds later you see the touchdown that everyone was yelling about. RTMP cannot guarantee consistency across devices and platforms. WebRTC can.
So What’s That Little “Skip” I Saw and Should I Be Concerned?
The “skip” can come from a few different places. First, the person or team that is broadcasting from OBS may have a network that is dropping packets of data while transmitting. Remember that UDP is unordered and doesn’t have any verification. Therefore if a packet is lost, or even late, it’s left out of the broadcast. Dropped packets is not the same as your network speed. A speed test can tell you that you have 100mgb download and 100mgb upload but a packet loss test will tell you if you are dropping packets or delivering them late.
A great tool is packetlosstest.com which will let you simulate a broadcast. I recommend using the WebRTC Approximation to see how your network performs. The results will show you packet loss and late packets. The higher the percentage of loss, the more “skips” you’ll see.
Second, this same packet loss can happen to anyone watching the broadcast. The preference of our service is to stay on the edge of real-time, just like Zoom. Therefore, we will not let things get behind and at times, we’ll “catch up” an end user by skipping them slightly forward so they do not fall behind. Using our example above, you’ll know exactly what everyone is cheering about because there will be no delay on your superbowl feed versus what others are seeing on a TV.
How Do I Minimize This?
First, we always recommend connecting your broadcast computer to an internet cable and avoid WiFi whenever possible. Make sure your cable is not loose, bent or twisted. You should hear a snap when you plug it into the wall/router and your computer. If you do not, try another cable.
Minimize the number or connections from your broadcast computer to your internet modem. Jumping through too many routers, switches, USB converters, etc will increase the likelihood of dropped frames.
Check your packet loss stats using packetlosstest.com. Try it during the day and after business hours. If you’re in a crowded building you may have more packet loss when people are in than when people leave for the day.
Do a tech rehearsal of your broadcast. Start your broadcast and watch it from another device on another network. Use OBS’ View Stats window to see if there are any areas of concern. If you’re playing a video from your computer, make sure it’s on your internal hard drive so it doesn’t have to go through a USB device before broadcasting.
Check your audio levels. Audio that “peaks” is less forgiving over UDP/WebRTC. If it’s too loud it may cut off a bit. Drop the audio level in OBS to avoid any “peaking”.
In the end, you may experience a slight pop or skip in the broadcast. Know that this is normal and intended to prioritize real-time over delay. To minimize and even remove this issue, take these listed steps and know that all your attendees will enjoy a real-time experience bidding from home just like they were right there with you!
* For all the super nerdly broadcasters out there, please do not overly judge my explanations. This is my best attempt at describing these complex technologies in a more simplified manner.
