{{ page.title }}

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:

Input restrictions

In order to ensure the highest quality, most consistent streaming experience, Brightcove Live limits input stream settings to:

• Protocol: rtmp, rtp, rtp-fec, or srt (all except rtmp are 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 1
• Audio codec must be AAC
• 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.
• Brightcove Live supports 608 captions in-band (inside h.264 headers). For more information on this topic, please reference Captions with Live Streams.^[1-2]

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).
• ^[1-2] You must set caption positioning in the 608 data when implementing 608 captions.

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:

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: It is recommended to use integer frame rates (such as 30fps) as this ensures consistent keyframe distribution and segment size.
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.

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.

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

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

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.
• Consider adjusting “Number of reference frames” to 4 for sporting / high movement content.
• Consider adjusting “Number of B Frames” to 3 for sporting / high movement.

Bitrate

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

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.

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

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

Updating the Player Version

Ensuring that you are using the latest version of the Brightcove Player is crucial for maintaining optimal performance, security, and access to the latest features. New releases often include bug fixes, performance improvements, and new functionalities that can enhance the live streaming experience.

Best Practices for Updating the Player

• Regularly check the Brightcove Player Release Notes to stay informed about the latest player versions.
• Ensure you have backups of your current player settings and configurations.
• Implement the new player version in a staging environment and test all functionalities, including customizations and integrations.
• Starting with a few low-risk live events to monitor performance before a full-scale deployment.
• Gather feedback from end-users and stakeholders regarding the new player version.

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

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
• The results of a trace-route from your encoder to the publishing point host