Buffering got you down? Looking for some tips to combat broadcast delays caused from streaming? Plagued by syncing issues and need some help?
Join us as we tackle some of the most common dilemmas our broadcasters face while explaining what leads to delays in a live stream.
If you are looking for more in-depth studio setups, though, please reference our Video Studio Recommendations white paper.
- Broadcast delays from shooting to stream
- Production equipment workflow
- Battling with bandwidth
- Live transcoding and video delivery
Broadcast delays from shooting to live streaming
“3, 2, 1, Start Broadcast! Now what?”
With any broadcast, especially in television, there is always a delay. When you broadcast live and notice a 30+ second delay there are multiple hops that are involved to make your broadcast hit the IBM Video Streaming player. Essentially, the process is boiled down to an encoder sending the stream to an IBM server where it is live transcoded and then delivered to the end user.
Now let’s go into the workflow of this process, and each element required, before dissecting what leads to a delay and also how to prevent viewer’s from experiencing buffering.
Production equipment workflow
IBM Video Streaming is a powerful platform to broadcast live. It’s as simple as setting up your account, connecting your camera and encoder, and pushing the “GO LIVE” button. Sometimes, however, broadcasters can hit a bump in the road before, during, or after their broadcast. We know at times it can be frustrating figuring out why your audio is out of sync or why your equipment is not working. Perhaps you are experiencing excessive buffering or your broadcast just isn’t showing up on mobile. Don’t worry, broadcasters: we can help!
Before your broadcast, do some research. IBM Watson Media offers an exhaustive knowledge base for the video streaming solutions. See what software is recommended for streaming from your device(s). It is always important to first research the right software before purchasing expensive equipment that might not work.
Here are key items you will need in order to broadcast:
- Camera
- Microphone / Audio
- Capture device
- Encoder
- Internet
Note: that this workflow is quite different if using your mobile device, like a smartphone, for streaming. For those looking for advice here, consult our how to live stream from your smartphone or tablet article.
Camera
There are a couple of cameras out there that are recommended for high-quality streaming. You can either use your built-in camera from your computer, USB connection camera, or a camera with an HDMI or SDI output.
Read this article on selecting live streaming cameras for more details.
Microphone/audio
Audio is the feature that makes your stream come alive and captures the perfect sound for your broadcast. You can capture your audio either from your built-in computer microphone, camera, mobile device, or an external microphone that runs through an audio mixer into your computer. Here are a few cable examples:
XLR cables
RCA cables
For more information on XLR, RCA cables and general audio troubleshooting consult this resource.
Capture device
Using a capture device is important to have when using a camera that has an HDMI or SDI output. With these setups you want to plug that into your capture device and your computer using a thunderbolt cable. Besides digitizing the source, this device can have added benefits like providing inputs for multi-camera shoots.
For more information on video capture cards and device, consult this article. Note that if you are using a USB camera, aka a webcam, you don’t need a capture device.
Encoder
There are multiple encoders out there you can use to broadcast, ranging from hardware to software. Hardware examples include the NewTek TriCaster and Teradek products. Software examples include Wirecast and vMix. You can even use the browser based option inside your IBM Video Streaming account as well, through the “GO LIVE” button.
For software encoders, first connect your camera to the capture device into the computer and then launch the encoder. The encoder allows you to control what you want to broadcast to your channel.
Internet: battling with bandwidth
When it comes to broadcasting to your channel page, the most important thing you should always have is a reliable Internet connection.
When you are watching your broadcast and experience buffering, choppiness and at times a blue spinning wheel, don’t panic! Here are key items you should follow before every broadcast.
BEFORE every broadcast, we strongly recommend the following:
-
Hardline Internet connection is recommended when it comes to reliable bandwidth during your broadcast. If wireless is the only available option, make sure you are the dominant user.
-
Run a speedtest from the computer you are broadcasting from. Please visit www.speakeasy.net/speedtest to check your upload speed. The most important part of this test is the upload speed. If your goal is to broadcast in HD (high definition), you must have at least 2.5 mbps and above for your upload speed level. If you experience lower than 2.5 mbps then SD (standard definition) is your only option.
-
When you are configuring your broadcast settings in your encoder, make sure to match it with your bandwidth level. For example, if your upload speed is at 1 mbps then the highest bitrate should encode at is 500 kbps, because the bitrate level will fluctuate during the broadcast. If you exceed your available bandwidth the stream will buffer. Please review the chart below for appropriate bandwidth and broadcast settings.
Recommended encoding settings
-
If buffering still occurs throughout your broadcast (test as early and as long as possible), try lowering the bitrate on your encoder to match with the available upload speed.
Click here for more information on bandwidth requirements.
Live transcoding and video delivery
To help with compatibility and delivery, IBM Watson Media implements live transcoding on the video feed sent by the encoder. This is done to make the content accessible across a wide range of devices, from desktops to smartphones. It also enables IBM to offer adaptive streaming in the video player. This process enables a variety of different quality options, like 1080p HD versus 480p SD, that the viewer can choose from while also automatically selecting one based on their connection speed. To read more about this technology and how it works, check out our Adaptive Bitrate Streaming white paper.
After being transcoded the content is then distributed over a multi-CDN (Content Delivery Network) infrastructure. This is done for boosted reliability and also worldwide delivery. The goal is to decrease the physical distance between an edge server, part of the CDN, and the viewer to reduce delay. This also mitigates strain, working to avoid outages caused by congestion. In addition, a software defined QoS (quality of service) process is at work behind the scenes. This works like adaptive delivery, but on a source level. For example, if a viewer is experiencing buffering the service will seamlessly try to change their delivery source to a different edge server or CDN to try and mitigate this. Not only does this offer a more ideal end user experience, but can also avoid potential outages that might be caused by congestion.
Broadcasting delay summary
A delay in broadcasting is the result of the feed having to make several hops, from camera to capture device (sometimes) to encoder and then to IBM. Additional delay is introduced from live transcoding, to make the feed compatible across a wide range of devices, and then the actual delivery process through the CDN to the viewer. An increased delay can also be introduced based on your Internet connection speed, in terms of lack of stability or a lower connection speed. Essentially the service is setup to try and mitigate buffering, airing on further delay rather than viewers experiencing this due to issues with the host connection speed.
Those looking to mitigate this delay should first realize there will always be some delay for live streaming. In the case of IBM Video Streaming, a 30 second delay is normal. If you routinely experience much more than this try testing your connection and work to improve it. For many use cases, the delay will not impact the end viewer experience. If there is a 30 second delay or not the viewer will often be unaware. Furthermore, the advantage of aspects like live transcoding and source switching lead to mitigating viewers from experiencing buffering, generally a much more sought after result.
For more information on use cases related to live streaming using IBM technology, consult our virtual conference solution page or our enterprise video platform page.