Contact Support | System Status
Page Contents

    Live Module Guidelines and Best Practices

    If you are looking to quickly get started broadcasting a live event, check out:

    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 30 fps, which is typical. Brightcove supports up to 60 fps, but you will need to Contact Brightcove Support to have the limit increased. When using 60fps, Brightcove recommends increasing the bitrate to achieve the desired visual quality for the content and a constant frame rate.
    • Less than 10 Mbps
    • Constant Bitrate (CBR) greatly reduces the chance of problems
    • Audio sampling rate: 44.1khz and 48khz are the recommended sample audio rates to use
    • Keyframe Rate or GOP (Group of Pictures) aligned:
      1. A Keyframe should always occur every 2 seconds for both inputs and outputs (including 25fps video). Meaning a keyframe is sent to Brightcove from the encoder every two seconds of the stream itself. This process can be defined in different ways, but Keyframe Rate is the most common.
      2. It can be calculated in different ways by different encoders. For example:
        • Wirecast uses the amount of frames that pass, so for a 30fps video, the setting would be 60.
        • Elemental encoders use seconds so that the correct setting would be '2'.
        • 60 FPS video will only change if this setting is counted by the frames, in which case every 120 frames would equal 2 seconds.
    • If there is an option for Keyframe Aligned, Sync GOP, Align Keyframes, or something along those lines, make sure Keyframes are aligned. When Keyframes are not aligned, it causes synchronization issues with HLS segmentation.

    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 ( - 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 ( - 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

    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.


    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.


    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 live stream after the chosen Reconnect Time (or the event length, if that is less than the 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.


    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 takes some time for a stream to be published, which varies according to the additional services added on (SSAI, slates, encryption, etc.). 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.
    Already used up your allotted redundant streams based on your account. You may have redundant groups counting against your account limit. Once an event with redundant streams completes or is canceled it is no longer visible in the Live Module. However, such events can be listed and deleted via the Live API. See Live API: Redundant Groups.

    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

    Page last updated on 11 Jun 2021