Expand on bitrate switching documentation
Move bitrate switching docs out of the readme. Add some pretty graphics.
Showing
9 changed files
with
40 additions
and
0 deletions
docs/bitrate-switching-1.graffle
0 → 100644
No preview for this file type
docs/bitrate-switching-1.png
0 → 100644
28.7 KB
docs/bitrate-switching-2.graffle
0 → 100644
No preview for this file type
docs/bitrate-switching-2.png
0 → 100644
35.3 KB
docs/bitrate-switching-3.graffle
0 → 100644
No preview for this file type
docs/bitrate-switching-3.png
0 → 100644
41.2 KB
docs/bitrate-switching-4.graffle
0 → 100644
No preview for this file type
docs/bitrate-switching-4.png
0 → 100644
38.1 KB
docs/bitrate-switching.md
0 → 100644
1 | # Adaptive Switching Behavior | ||
2 | The HLS tech tries to ensure the highest-quality viewing experience | ||
3 | possible, given the available bandwidth and encodings. This doesn't | ||
4 | always mean using the highest-bitrate rendition available-- if the player | ||
5 | is 300px by 150px, it would be a big waste of bandwidth to download a 4k | ||
6 | stream. By default, the player attempts to load the highest-bitrate | ||
7 | variant that is less than the most recently detected segment bandwidth, | ||
8 | with one condition: if there are multiple variants with dimensions greater | ||
9 | than the current player size, it will only switch up one size greater | ||
10 | than the current player size. | ||
11 | |||
12 | If you're the visual type, the whole process is illustrated | ||
13 | below. Whenever a new segment is downloaded, we calculate the download | ||
14 | bitrate based on the size of the segment and the time it took to | ||
15 | download: | ||
16 | |||
17 | ![New bitrate info is available](bitrate-switching-1.png) | ||
18 | |||
19 | First, we filter out all the renditions that have a higher bitrate | ||
20 | than the new measurement: | ||
21 | |||
22 | ![Bitrate filtering](bitrate-switching-2.png) | ||
23 | |||
24 | Then we get rid of any renditions that are bigger than the current | ||
25 | player dimensions: | ||
26 | |||
27 | ![Resolution filtering](bitrate-switching-3.png) | ||
28 | |||
29 | We don't want to signficant quality drop just because your player is | ||
30 | one pixel too small, so we add back in the next highest | ||
31 | resolution. The highest bitrate rendition that remains is the one that | ||
32 | gets used: | ||
33 | |||
34 | ![Final selection](bitrate-switching-4.png) | ||
35 | |||
36 | If you'd like your player to use a different set of priorities, it's | ||
37 | possible to completely replace the rendition selection logic. For | ||
38 | instance, you could always choose the most appropriate rendition by | ||
39 | resolution, even though this might mean more stalls during playback. | ||
40 | See the documentation on `player.hls.selectPlaylist` for more details. |
-
Please register or sign in to post a comment