Determining Which Rendition Will Play

This topic contains information on how the Brightcove Player determines which rendition to play.

HLS or MP4?

When using the new Brightcove Player, we recommend you choose or create an ingest profile that has both HLS and MP4 renditions in order to reach the greatest number of devices and browsers. This table shows how the player determines, at run-time, which rendition will play on a particular browser.

Browser Type Playback Technology Used By Default
Desktop Chrome 34+, Desktop Firefox 42+, Edge and Chrome 34+ on Android 5.0+ HTML-based HLS (using MSE[1-1])
Desktop (macOS) Safari, Mobile (iOS) Safari Native HLS (implemented by browser)
Older Firefox and Chrome Flash based HLS; requires Flash 10.3+ (will fall back to MP4 if Flash disabled)
IE 11 on Windows 8.1+ HTML-based HLS (using MSE)


HLS & DASH rendition selection

HLS and DASH video is broken into segments. These are typically about 10 seconds in duration but can be longer or shorter. If the bandwidth and resolution are known, the player will pick the rendition based on these criteria. If the resolution or bandwidth is unknown (for example, when creating a player with display:none), the player will start with the rendition closest to .5 MB/s (equivalent to 4000 kbs). On segment boundaries it will switch to a higher or lower rendition described in the text and images below.

Both HLS and DASH try to ensure the highest-quality viewing experience possible, given the available bandwidth and encodings, and at the same time considering player size. This doesn't always mean using the highest-bitrate rendition available. For instance, if the player is 300px by 150px, it would be a waste of bandwidth to download a 4k stream.

By default, the player attempts to load the highest-bitrate variant that is less than the most recently detected segment bandwidth, with one condition: if there are multiple variants with dimensions greater than the current player size, it will only switch up one size greater than the current player size.

During playback, the player will switch to a higher or lower rendition based on the following algorithm. Inputs to this algorithm are:

  • Available bandwidth
  • Player dimensions

High-level algorithm overview

  1. Remove all renditions that have a bitrate higher than the measured bandwidth.
  2. Sort the remaining renditions by resolution (horizontal line count) high to low.
  3. Point to the one closest to the player's dimensions and choose the one higher than that.

The process is illustrated below:

  1. Whenever a new segment is downloaded, the download bitrate is calculated based on the size of the segment and the time it took to download:
    HLS rendition1
  2. All the renditions that have a higher bitrate than the new measurement are filtered out:
    HLS rendition2
  3. Any renditions that are bigger than the current player's dimensions are filtered out:
    HLS rendition3
  4. A significant quality drop is not wanted just because your player is one pixel too small, so we add back in the next highest resolution. The highest bitrate rendition that remains is the one that gets used:
    HLS rendition4

If it turns out no rendition is acceptable based on the filtering described above, the first encoding listed in the master playlist will be used.

In this case, the best rendition would be 960x5@ 720kbpsbps because It is the “next highest” resolution from the one within the bounds of 900x500, which would be 640x360 in this case. Also, 720kbps is the highest bitrate within the theoretically unlimited range. It also depends on a pixel ratio (if this is a retina display, the player will treat it as 1800x1000). For more information about bandwidth, see Github.

If you'd like your player to use a different set of priorities, it's possible to completely replace the rendition selection logic. For instance, you could always choose the most appropriate rendition by resolution, even though this might mean more stalls during playback. See the documentation on player.hls.selectPlaylist for more details.

MP4 rendition selection

If running on a mobile device and playing an MP4 (based on the rules listed above), the player will choose the MP4 that has a bitrate closest to .5 MB/s. If on a desktop or laptop device it will choose one that is closest to 3 MB/s.

Audio track selection

The manifest determines which audio track to load depending on which video track is chosen.





In the sample above, there are two audio groups, stereo and surround. There are also 6 video resolutions in 8 bitrates:

  • The 3 lower bitrates use the stereo audio group
  • The 5 higher bitrates use the surround audio group

The two audio groups have two streams with different language and names. When this is present, it shows up as an alternate audio track in a menu on the player.


  • HLS doesn’t allow adapting audio streams in a demuxed audio scenario. So, if you have different audio groups or alternate audio like in the example above, it’s not possible to specify multiple quality renditions of the stereo or the surround tracks.

    However, if the playlist is audio-only, it is possible to do so if the audio is provided via the regular EXT-X-STREAM-INF tag.

  • For DASH, you can have adaptive audio but we do not currently support adapting it, unless it is an audio-only manifest. We choose a single rendition associated with the video rendition. This is the first audio rendition that we find.