Brightcove Live: Best Practices
Brightcove Live provides a robust service for creating live streaming events or 24/7 live streams. This guide outlines best practices for optimizing your live streams
The type of content being streamed needs to be considered as it has an impact on the required settings for maintaining the quality of the input. Note that there are trade-offs and using the highest possible settings may cause issues such as skipped frames.
Based on the information below, we recommend that you test different setting combinations for quality and performance before your live event.
The key input parameters are outlined in the following table:
|Input bitrate||The bitrate that the encoder sends. Higher rates are more susceptible to network loss so should be kept as low as practical.|
|Input resolution||This should match the source content. There is no benefit in making this greater than the original source and the higher this value is, the higher the bitrate is required to support it.|
|Input bitrate to top profile ratio||
To ensure optimal performance during live events, we recommend setting the input bitrate to match the bitrate of your highest bitrate live rendition. However, exceeding the maximum rendition bitrate significantly can potentially result in buffering, high input/output drift, and other related issues. Therefore, Brightcove recommends carefully considering the following factors when determining the input bitrate:
|Profiles|| The different profiles (baseline, main, high) compress the data in ascending amounts (baseline: lowest, high: highest). Greater compression improves the rate of transmission, but also requires greater CPU resources to decode the data. Unless the encoder is highly constrained in available resources baseline profile should be avoided. On the other hand, using high profile at high bitrates is more likely to cause skipped frames due to the increased decode CPU resources required.
Also see GOP structure below.
|Frame rate|| This should match the source.
Higher rates will require proportionally higher input bitrates e.g. with action sport content a 60fps input stream carries substantially more data than a 30fps stream.
High rates such as 60fps are more likely to have skip frame issues on complex content at high bitrates.
|Keyframe rate|| The most efficient setting for this is the segment duration x frame rate - for example, if you have 6 second segments and 30fps making the keyframe rate 180 (6x30) would result in the lowest decoder load.
However, to account for any fluctuations this is set to 2 x the frame rate - for example, 60 for a framerate of 30 fps.
|GOP structure||See GOP structure below.|
In order to ensure the highest quality, most consistent streaming experience, Brightcove Live limits input stream settings to:
rtmpare for MPEG2-TS inputs)[1-1]
- Resolution: 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.
- The max input bitrate that can ingest is set at 30Mbps. And the max output bitrate is 20Mbps.
- Constant Bitrate (CBR) greatly reduces the chance of problems
- Video codec must be H.264
- Slices: If your encoder has this option, set it to
- Audio codec must be
- Audio sampling rate: 44.1khz and 48khz are the recommended sample audio rates to use
- Keyframe Rate or GOP (Group of Pictures) aligned:
- 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.
- 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.
- [1-1] If you have multiple video/audio tracks in your TS input, we will pick the first for each. We also strongly recommend using FEC, as plain TS over UDP over the internet is very unreliable. For FEC, we could note that the smaller the values you use for rows/columns, the more reliable the error correction will be (at the cost of increased bandwidth.
Long running jobs
If you have long-running jobs (such as linear channels), please reactivate them on a monthly basis to get the advantage of bug fixes and new features.
Key issues with streaming
There are several issues that are generally encountered that relate to problems with the streaming experience from the encoder to Brightcove:
- Network instability affecting the input:
- While the internet is generally quite reliable it is not infallible and issues do occur. Issues are more likely to be noticed on higher bitrates.
- If it takes longer to upload the video than real time then this can result in input drift (the time that the video is received is substantially later than when it was sent)
- Transcoder overload resulting in skip frames: while we do everything to make sure our transcoders have enough overhead sometimes sudden spikes in either content complexity, network hiccups/ catchups or other interruptions to our transcoders can cause skip frames. The more complex the input is then the more likely it is that skipped frames will be encountered. There is also a known issue where changes from a still image for an extended duration e.g. longer than 5 minutes and a sudden change to action content can cause an overload.
- Encoder sending variable frame durations: the frame rate should be constant and it should be such that it allows for a keyframe interval that is constant. For example, for a frame rate such as 29.97 aka 30000/1001 or 23.976 aka 24000/1001 it is not possible to set a keyframe at a regular interval and as such should be avoided.
- Encoder sending keyframes that are not a consistent duration apart, the keyframe rate should be a minimum of 2x the frame rate in seconds. For example, for a frame rate of 30fps the keyframe interval should be 60 frames which is 2 seconds and should be a maximum interval of once per segment - for example, if you have a 6 second segment then the maximum interval would be 180 frames at 30 fps
Generally, more complex content will require using the higher of these settings and as such is more susceptible to skipped frames. The table below shows some examples in order of complexity. Note that these are examples only, and as just about every encoder setup is different. Testing and verification should be performed.
|Content Type||Example Settings|
|Talking Head / News||
|Live Sport High FPS||
Transmux Live jobs
Set the insertion of key frames so that it matches the request segmentation settings. For example, if the frame rate is 25 frames per second and the desire is for a 6 second segment then set the keyframe interval to be at least once every 300 frames.
Test the encoder settings/output with desired target devices. This is particularly important if using a broadcast contribution encoder that may have advanced settings that result in a stream that may not be compatible with all consumer devices. It is also a good idea to avoid particularly advanced settings - it is hard to say what these are exactly as there are so many possible encoders and options. But a general top rate profile should be something like:
- 6Mbps peak bitrate
- H264 High profile
- B frames: 2
- 8bit 4:2:0 color
Verification and testing
Ideally you should start with the lowest possible settings on your most complex (most changing content) and test with their content by increasing the various settings until the output is acceptable. This is because generally the higher the settings the more likely issues are to be encountered in either the network or transcoding.
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 (https://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 (https://www.speedtest.net) - Online tool for determining current upload and download speeds.
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: 20 mbps
Input limit spikes
- Maximum input bitrate: 30Mbps
- Maximum output bitrate: 20Mbps
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 bottom of the Wirecast window.
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
The Group of Pictures (GOP) structure of the video is dependent first on the profile that is used as:
- Baseline profile only supports I and P frames and CAVLC entropy encoding
- Main and High support I, B and P frames and CABAC entropy encoding
Main and High profiles generally result in better compression at better quality but also require additional computation to encode and decode, as such may be more susceptible to skipped frames. In addition, as these profiles use B (bi-directional) frames, they induce some delay in the encoding process.
Baseline profile requires less CPU to encode and decode, but as it offers less compression, it requires a higher bitrate to maintain quality and as such is more susceptible to network issues.
Notes on frame types and their likely impact on performance:
- I frames: uses the most bandwidth. Best added for complete scene changes or at the segment boundaries - i.e. the more the content changes the more of these you need (shorter GOP length)
- P frames: are the base unit between I frames
- B frames: use both prior and future frames, the more you add the better the compression will be but the higher the CPU and latency
The use of I frames should ideally be limited to start of segments (critical if using passthrough) or scene changes. All or high numbers of I frames should be avoided as this can cause excess load leading to skipped frames.
- Use options for preventing dense placement of key frames (example:
- Use options ensuring a regular cadence of insertion of Key frames. For example, instead of specifying GOP length in seconds, specify it in exact fractions or frames.
- Consider adjusting “Number of reference frames” to
4for sporting / high movement content.
- Consider adjusting “Number of B Frames” to
3for sporting / high movement.
- Minimum input bandwidth: 2.5 mbps
- Maximum input bandwidth: 20 mbps
- Make the stream "almost CBR"" - with
max_bitrate= 1.1 * target_bitrate.
- Use strict HRD-compliant rate control mode, if available.
It is important to note that the internet is not a guaranteed delivery network, and that while an internet connection may be considered "good", it may not be good enough for reliable live video streaming at high quality. A small disruption in the path between the customer encoder and the Brightcove transcoding platform such as a small amount of congestion at an ISP, an unplanned failover between routers, or similar issues can cause a disruption in the video output. In high stakes live broadcast it is normal practice to have multiple dedicated networks consisting of either dedicated fibre, booked satellite bandwidth, or committed bandwidth on a managed network. This comes with a substantial cost, and in most cases it is possible to achieve a good enough outcome over the internet. If, however, it is critical to maintain fault-free transport please consider AWS Direct Connect or an ISP that can provide some level of dedicated bandwidth.
Generally, we recommend dedicating bandwidth two times the encoder's expected stream size to completely avoid any bandwidth-related network issues.
The options we recommend are (in order):
- SRT - provides a good combination of speed of transport (UDP) with some control and error resilience. Not available on all encoders, though there are tools that can translate from local RTP such as srt-transmit.
- RTMP - being TCP based, it provides a good level of error resilience, downsides are that this comes with a substantial overhead. Note that not all features such as multiple audio tracks are available with RTMP.
- RTP-FEC - provides fast UDP based transport with some error resilience
- RTP - provides fast transport and advanced features with no error resilience
See Supported Encoders for Live Events for list of encoders known to work with Live. Note that other encoders may also work, but have not been tested.
- Amazon CloudFront
We recommend enabling retries for the RTMP connection from the encoder. A large number of retry attempts with a 5-second retry interval will mitigate any intermittent connectivity issues between the encoder and the entry point.
Job settings (Live API only)
Recommended job settings
Start a live stream recommendations
A job must be activated before the encoder connection. Also, activating a job after starting the stream from the encoder is not a supported procedure and may cause unexpected behavior.
Slate source file recommendations
- Resolution: (best in your encoding ladder)
- FPS: (same as your source)
- Bitrate: (best in your encoding ladder or better)
- Audio: (same bitrate, channels, sampling frequency, and bits per sample as your best rendition, or same as your input)
Below are recommended output settings, but note that for many encoders, the RTMP input is limited to 20 MBPS (video + audio) and a framerate of 30fps.
|Bitrate||The current max output bitrate supported is 20Mbps|
|Keyframe rate||2 seconds|
- if the job is in the waiting state (not yet started) and the
max_waiting_time_mshas elapsed, the job is finished/deactivated.
- If the job is in the disconnected state (started, but disconnected) and the
reconnect_timehas elapsed, the job is finished/deactivated.
- The number of
channel(24x7) jobs is limited to 0 or a low number per region (depending on the account type).
- The number of concurrently running
eventjobs is limited by region, generally to 100.
- The number of concurrently waiting to connect
eventjobs is limited to 5.
- The number of SEP jobs per region is limited to 3 or 10 (see Supported AWS regions).
- 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
- The results of a trace-route from your encoder to the publishing point host
How soon do you have to start streaming after creating a live job?In Brightcove Live, there are two conditions when the state transitions from
event_length is greater than 30 minutes, the job will terminate in 30 minutes. If the
event_length is less than 30 minutes, the job will terminate in
For example, if the
event_length is 60 minutes, then, the live job will terminate in 30 minutes. If the
event_length is 15 minutes, then, the live job will terminate in 15 minutes
reconnect_time has no effect for waiting state.
What are the limitations on concurrent live job_settings?
A maximum of 5 active waiting, unstarted jobs is allowed at any time.
Additional limitations on concurrent jobs:
Any of these limits can be adjusted on an account level by Support. Contact your Customer Success Manager if you need additional capacity.
Can Brightcove Live push 1080p quality provided the input bandwidth is sufficient?Yes, 1080p input is enabled for all accounts.
Is DRM available?Yes! Contact your Customer Success Manager if you are interested in adding DRM support to your live account.
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.