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||
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
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.
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.
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:
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||
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.
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.
- 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):
- 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.
Recommended job settings
The following table shows requirements for the input live stream.
|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] 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)
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.
|Bitrate||Less than or equal to the input bitrate|
|Keyframe rate||2 seconds|
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
- 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.
event_lengthis greater than 30 minutes, the job will terminate in 30 minutes. If the
event_lengthis less than 30 minutes, the job will terminate in
For example, if the
event_lengthis 60 minutes, then, the live job will terminate in 30 minutes. If the
event_lengthis 15 minutes, then, the live job will terminate in 15 minutes
reconnect_timehas no effect for waiting state.
- if the job is in the waiting state (not yet started) and the
- 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
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).
Any of these limits can be adjusted on an account level by Support. Contact your account manager if you need additional capacity.
- The number of
- 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 account manager if you are interested in adding DRM support to your live account.