Determining Which Rendition Will 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)|
|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
- Remove all renditions that have a bitrate higher than the measured bandwidth.
- Sort the remaining renditions by resolution (horizontal line count) high to low.
- Point to the one that is closest to the player dimensions.
- Choose the one that’s one higher than that one.
The process is illustrated below:
- 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:
- All the renditions that have a higher bitrate than the new measurement are filtered out:
- Any renditions that are bigger than the current player's dimensions are filtered out:
- 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:
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.
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.