Rendition Settings and Video Quality

Video Cloud
API Developer
Add Videos/Assets
Encoding Settings
Dynamic Ingest API
Ingest Profiles API

In this topic, you will learn about fields in your ingest profiles that affect the quality of the video delivered to viewers. Optimizing online video quality and performance is a complex challenge. This topic explains the different factors that affect quality and performance and the rendition settings for your ingest profiles that you can use to get the results you want.


We all want the best possible video and audio quality in our online video. At the same time, we want the videos to perform well, meaning that the delay between the moment the viewer clicks play and the actual beginning of playback is as small as possible, and that once playback begins, it continues smoothly, with no stalling or pausing while additional data is buffered.

Unfortunately, these are conflicting desires: the quality of the video depends primarily on the amount of data delivered to and processed by the viewer's system; performance, on the other hand, depends on not delivering more data than the internet connection and the client application and system can handle. To make things more complicated, there are considerable variations in connection bandwidth and system capacity based on geography, time of day, internet provider, type of device, and so forth.

Brightcove players help to optimize the viewing experience by detecting available bandwidth and selecting the video rendition best suited to it. The player can only choose among the available renditions, however, to it is up to you to try to provide a set of renditions that will match the needs of your viewers.

Video source

The first factor to consider is the video source file. The renditions cannot be of higher quality than the source, so it's important that you export the video at a higher bitrate than the highest one you want in your renditions.

On the other hand, there is no value in exporting at bitrates much higher than your highest target bitrate - you will just increase upload and transcoding time without increasing the quality of your online videos. We generally recommend that the source bitrate be no higher than twice the highest target bitrate. However, changes in technology, average bandwidth, and new devices might mean that higher bitrate renditions will be useful in the future, so you should save the raw video file to allow exporting a new source later, or export one version for use now, and another higher bitrate version for future use.

Rendition properties

There are several rendition properties affecting video quality and performance that you can set in your ingest profiles. These are explained below


The max bitrate fed to the decoder via a buffer. This setting is typically used only for streaming (RTMP, HLS, or broadcast video).

Only use this setting if you understand its implications, as it can decrease video quality.

Also see the max_video_bitrate section below.


The size of the buffer fed to the decoder when using a bitrate_cap, expressed in kbps. The buffer_size divided by bitrate_cap represents the size of the buffer in seconds; so if you set bitrate_cap to 1000 and buffer_size to 1000, the buffer is effectively 1.0 second. If bitrate_cap is 500 and buffer_size is 1000, the buffer is 2.0 seconds.

Only use this setting if you understand its implications, as it can decrease video quality. This should typically only be used for streaming (or for device playback).


Constrains the bitrate and macroblocks. Primarily used for device compatibility. For example, the iPhone supports H.264 Level 3, which means that a video’s decoder_bitrate_cap can’t exceed 10,000kbps. Typically, you should only change this setting if you’re targeting a specific device that requires it.


A maximum average bitrate for a movie. Overrides both the quality and video_bitrate settings to ensure that a bitrate doesn't exceed the provided number.

The max_video_bitrate setting works in conjunction with the quality setting to allow for encoding to a specific quality level (in variable bitrate mode) but having a "safety" limit in place. Brightcove will start by trying to encode to the quality setting specified, but while encoding, if we detect that the final average bitrate will be higher than max_video_bitrate, we'll stop encoding, and go back and do a second pass that encodes to the max_video_bitrate (in average bitrate mode), ensuring that the average bitrate of the video does not end up too high.

Using max_video_bitrate in conjunction with video_bitrate does not really make sense, so we just encode to the lesser of the two values specified.

The decoder_bitrate_cap setting, however, sets a maximum peak bitrate for the encoding, so that there will not be any "spikes" going higher than this bitrate, allowing for streaming the video without needing to stop and rebuffer. Note, however, that calculating those peaks is not straightforward, because it is limiting the fill rate for the video buffer, as opposed to limiting the bitrate of a single frame or a single time period. That is why the decoder_buffer_size is generally used together with this. The video encoder will still be able to pre-fill the buffer when needed (such as in a time when there is low action followed by very high action), so the bitrate of a single frame or even short period of time may be significantly higher than the value specified for decoder_bitrate_cap. Yet, if the video is transferred over a connection with a bandwidth at least equal to decoder_bitrate_cap, then it will never have to stop and rebuffer.

Note that max_video_bitrate does not limit peak values, and is not recommended for streaming situations.

max_video_bitrate is especially useful when encoding for mobile devices using the quality setting, which autoselects a bitrate. Mobile devices sometimes have fixed bitrate limits; for example, the iPhone 3GS has a bitrate limit of 1500 kbps.

max_video_bitrate can also help to avoid bitrate spikes that can occur at transition points between, say, a talking-head segment and a high-action or screencast segment. Such spikes can cause a video to stall because the data fed to the decoder temporarily exceeds its processing capacity.


By setting the quality for your renditions, you indicate the desired quality of the output, and the Video Cloud transcoding system will automatically select a bitrate that achieves that quality. The available settings are:

  1. Highly compressed. Mediocre visual quality, but small files
  2. Acceptable quality
  3. Good quality. Better than most web video
  4. Great quality. Looks excellent
  5. Nearly lossless. Large files. Not recommended unless you plan to encode this output again


speed determines target transcoding speed. Slower transcoding allows for more advanced file compression, while faster transcoding is possible by skipping some advanced compression features. Valid values are 1-5. If quick availability of the video is not critical, you may achieve slightly better video quality by selecting a slower transcoding speed.


The target output bitrate for a video, expressed in kbps. This results in a predictable output bitrate, but not predictable quality. For example, at 640x480, 500kbps might be enough for a video blog to look good, but an action movie might look bad at the same bitrate. Similarly, it might be too high for a screencast, resulting in a file that is larger than it needs to be.

Platform specific issues

  • The Edge browser uses Microsoft's "Media Foundation" (MF) codecs built into Windows for playback. There is a limitation in the "AAC Decoder" from MF that limits the maximum sampling rate of AAC to 48khz. If the player loads a rendition with an audio sampling rate greater than 48khz, the browser may return a MEDIA_ERR_SRC_NOT_SUPPORTED error.