Live Module Guidelines and Best Practices

Product(s)
Video Cloud
Live
Role(s)
Studio User
Topic(s)
Live Module
Live Streaming

With Video Cloud Live, you can easily set up live events and deliver multi-bitrate streams to the web, iOS, and Android devices. This topic outlines a series of best practices and recommendations to help ensure a high quality, stable live streaming experience.

Note: Live streaming support is available only for Video Cloud Pro and Enterprise publishers.

If you are looking to quickly get started broadcasting a live event, check out Quick Start: Using the Live Module with Telestream Wirecast topic. For a list of all the options available from Brightcove for delivering live streaming video, see Delivering Live Streams.

Certified encoders

For a list of supported encoders, see Supported Encoders for Live Events. Other hardware and software based encoding tools may work with the Live module, but their use is not supported. If you have a question about a specific tool, please contact Brightcove Support for more information.

Input stream guidelines

Providing a high-quality, stable input stream is the only way to ensure the best user experience for viewers. A good input stream provides the best video quality at the highest consistently available bandwidth from a location.

Input restrictions

In order to ensure the highest quality, most consistent streaming experience, Brightcove Live limits input stream settings to:

  • Maximum 1920x1080
  • Maximum 60 fps - 30fps is typical. When using 60fps, Brightcove recommends increasing the bitrate significantly and using a constant frame rate.
  • Less than 10 Mbps

Testing bandwidth

The first step towards arriving at the appropriate settings for the input stream is to determine the available bandwidth on site. There are a few tools that can help:

  • SpeedOf.Me (http://speedof.me) - Determining the total bandwidth available for HTTP connections is a good first step. However, since the input feed will be streamed to the Live module over RTMP instead of HTTP, the actual bandwidth available for RTMP connections will be significantly less.
  • Speedtest (http://www.speedtest.net) - Online tool for determining current upload and download speeds.

Input Bandwidth

Providing a high-quality, stable input stream is the only way to ensure the best user experience for viewers. A good input stream provides the best video quality at the highest consistently available bandwidth from a location.

  • Minimum input bandwidth: 2.5 mbps
  • Maximum input bandwidth: 10 mbps

Note: For the best user experience, match your output renditions to the quality of your encoder stream.

Determining encoder capabilities

Understanding the capabilities of the software and hardware used to encode the live stream and send it to the Live module is also important. There may be plenty of bitrate to send a high-quality, 1080p input stream, but the hardware also needs to be able to encode in faster-than-realtime speeds. Some encoding tools display information about the total CPU usage and bandwidth being used. For example, Telestream Wirecast will display the output statistics at the top of the page. This information is useful when determining the most stable, highest quality stream that is possible on given hardware.

Things to watch in Wirecast:

  • CPU should be less than 80%
  • Datarate should be near the target bitrate
  • FPS should be at the rate of the input stream settings

Preparing for an event

Before using the Live module for a production event, testing the entire end-to-end chain is critical to ensure success. There are two main areas to test:

  • The video production workflow
  • The tools being used to connect to the Live module

For every new location, or any time hardware or software configurations change, a new round of testing should be performed.

Production

The live feed being generated and sent into encoding hardware or software can be as simple as a webcam and as complex as a multi-camera, edited live broadcast. In either case, the incoming video feed must be consistent throughout the event. Ensure that switching between camera angles or systems results in the same resolution and number of audio channels.

Connection to the Live module

The connection to the Live module should be tested on the same network, using the same input live feed, being sent through the same encoding software as will be used for the production event. The goal is to mimic the production event as closely as possible.

The Day of the Event

You should plan on starting the live stream at least 10 minutes earlier than the scheduled broadcast. Starting 30 minutes early will provide some extra time to coordinate and solve any issues.

Issues during live streaming

The work of testing a live stream, finding the ideal settings for the input stream, and preparing the venue for the event will greatly reduce the chance of errors occurring. However, it is important to always be prepared to handle any issues that may arise.

Disconnects

Network outages, encoder malfunctions, or power outages can all contribute to the Live module connection being lost. Live events have a Reconnect Time, which is the time in minutes to wait for a stream to reconnect. When a connection is lost, the Live module disconnects the after the chosen Reconnect Time. Set the reconnect time by expanding the Advanced Options when creating an event:

The Live module will accept any number of disconnects and reconnects during this reconnect time without needing to start a new stream. Once a stream has been reconnected, playback will resume from the most recent frame. If the event ends without the stream being reconnected, the player will return a warning that the stream was not found.

Note: When disconnecting and reconnecting, the stream settings must stay the same. Any changes to the number of audio channels, resolutions, or codec settings will result in unpredictable behavior.

Latency

Streaming latency, or the time difference between the events a viewer is watching and the actual live event, is introduced in three places:

  • The on-site encoder
  • Cloud transcoding
  • CDN delivery

The on-site encoder and the Live module’s cloud transcoding system introduce a total of 1.5 to 5 seconds of latency. Depending on the CDN, there may be another 15-90 seconds of latency introduced. In general, latencies between 15-90 seconds are considered normal for live feeds and are necessary for the Live module to be able to serve millions of concurrent viewers watching live events.

Troubleshooting live stream issues

Problem Resolution
Playback freezes, audio continues Check the input feed to the encoder, and check that the encoder is still properly connected and encoding video. If there was a disconnect, ensure that the stream settings are identical before reconnecting.
Stream appears frozen in the player The Live module has most likely stopped receiving data from the input encoder. Confirm that the input stream is active, connected, and sending data faster than real time.
Choppy playback Ensure there is more than enough bandwidth to support the bitrate of the input stream. Choppy playback is usually an indication that there is something wrong on the production side or there is insufficient bandwidth.
Blank Screen Confirm that there is enough bandwidth. In the case of a disconnect, be sure that no settings have changed before reconnecting.
Longer than expected latency Check the available bandwidth and ensure that data is being sent to the Live module in real time. It may take up to 10 minutes for a stream to be published. During this time, the stream is cached and the latency will be the longest. After being published, latency will continue to decrease until stabilizing between 30-90 seconds.
 

For further help

If you need further help getting your live event to work, you can contact us. To make sure you get the fastest response possible, below is a list of what Brightcove Support will need to solve the problem.

  • The specific symptoms the stream is having. For example, does it not play at all or does it stutter or freeze?
  • Whether this stream worked correctly in the past
  • The entry point URL you are using in your encoder
  • The encoding software and hardware are you using
  • The URL to the player to which you have published the live event
  • The video ID of your live asset in Video Cloud Studio
  • The results of a trace-route from your encoder to the publishing point host