Overview

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

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.

Bitrate

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

Protocol

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

Retries

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

Input requirements

The following table shows requirements for the input live stream.

Notes

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

FAQ

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.