This page has moved - you will be directed to the new location in 3 seconds. Please update your bookmarks!

Brightcove Live: Best Practices

This topic provides a guide to best practices for creating live streams using the Live API.


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

Content context

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:

Key Input Parameters for Live Streaming
Parameter Notes
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 The input bitrate should be higher than the rate of the top profile, but too much higher may result in dropped frames or other issues - e.g. if your top rate is 1080p 30fps, the input should ideally be around 4 MBPS. Note that this is affected by the profile.

If you require a high bitrate top output it is worth testing the copy_video setting which will simply copy your input encode to the output.

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.

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:

  1. Network instability affecting the input:
    1. 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.
    2. 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)
  2. 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.
  3. 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.
  4. 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

Content types

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 Examples
Content Type Example Settings
  • Resolution: 360p
  • Bitrate: 1 MBPS
  • Profile: Baseline
Web conference
  • Resolution: 480p
  • Bitrate: 2.5 MBPS
  • Profile: Main
  • Resolution: 720p
  • Bitrate: 2.5 MBPS
  • Profile: Main
Talking Head / News
  • Resolution: 720p
  • Bitrate: 4 MBPS
  • Profile: Main
Live Concert
  • Resolution: 1080p (or source)
  • Bitrate: 5 MBPS
  • Profile: High
Live Sport
  • Resolution: 1080p (or source)
  • Bitrate: 6 MBPS
  • Profile: High
Live Sport High FPS
  • Resolution: 1080p (or source)
  • Bitrate: 10 MBPS
  • Profile: High

Verification and testing

Ideally customers should start with the lowest possible settings on their 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.

GOP structure

The Group of Pictures (GOP) structure of the video is dependent first on the profile that is used as:

  1. Baseline profile only supports I and P frames and CAVLC entropy encoding
  2. 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:

  1. 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)
  2. P frames: are the base unit between I frames
  3. 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.

Additional notes:

  • Use options for preventing dense placement of key frames (example: min_keyin = 3+).
  • 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.


  • Minimum input bandwidth: 2.5 mbps
  • Maximum input bandwidth: 10 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.

The options we recommend are (in order):

  1. 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.
  2. 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.
  3. RTP-FEC - provides fast UDP based transport with some error resilience
  4. RTP - provides fast transport and advanced features with no error resilience

Supported encoders

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.

Supported CDNs

  • Akamai
  • 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

Recommended job settings

Job Settings
Field Recommended Value
ad_audio_loudness_level -23 (EBU R.128 standard)

Input requirements

The following table shows requirements for the input live stream.

Input Requirements
Item Requirement
Protocol rtmp, rpt, rtp-fec, or srt (all except rtmp are for MPEG2-TS inputs)[1-1]
Video format h.264
Audio format AAC
Maximum audio sampling rate up to 48000 Hz (Brightcove Support can increase this value on request)
Resolution Up to 1080p (width: 1920 pixels; height: 1080 pixels)
Bitrate Must be at least as high as the highest output bitrate - maximum: 10MBPS.

In almost all cases, Brightcove Support has found that using Constant Bitrate for the input stream greatly reduces the chance of problems.

Framerate 30 fps (you can submit a Support request to have the limit raised to 60fps)
Slices If your encoder has this option, set it to 1


  • [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.

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)

Output recommendations

Below are recommended output settings, but note that for many encoders, the RTMP input is limited to 10 MBPS (video + audio) and a framerate of 30fps.

Output Recommendations
Item Recommendation
Video codec h264 is currently the only option
Audio codec aac is currently the only option
Width If no width or height is supplied, the source dimensions are used. If either width or height is supplied, the other dimension will be calculated to maintain the aspect ratio of the source.
Height If no width or height is supplied, the source dimensions are used. If either width or height is supplied, the other dimension will be calculated to maintain the aspect ratio of the source.
Bitrate Less than or equal to the input bitrate
Keyframe rate 2 seconds
AWS regions

See the Live API Overview.


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 waiting to finishing :
  1. if the job is in the waiting state (not yet started) and the max_waiting_time_ms has elapsed, the job is finished/deactivated.
  2. If the job is in the disconnected state (started, but disconnected) and the reconnect_time has elapsed, the job is finished/deactivated.

If the 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 event_length .

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

The 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:

  • 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 event jobs is limited by region, generally to 100.
  • The number of concurrently waiting to connect event jobs is limited to 5.
  • The number of SEP jobs per region is limited to 3 or 10 (see Supported AWS regions).

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.