Quirk in bitrate switching

[jeroen]

from -jj:

I was looking at the implementation of PlaylistItem.getLevel. Right now, it tries to find a level that has a bitrate that's not too high and a width that's not too high. It also ignores levels that are blacklisted. The code is clean and simple.

Unfortunately, it breaks really badly for some of our films. These days, we encode our films for our exact player size at a few bitrates and at larger widths at a few bitrates for when the user goes fullscreen. However, some of our older films are encoded at multiple bitrates, but all at 698 pixels wide. Since our player width is only 480 pixels, the currently algorithm always picks the lowest level no matter what. Hence, even if I have tons of CPU and tons of bandwidth, I'm stuck with the worst level. I suspect there are other people who may encounter this same issue, so it makes sense to apply a little bit more intelligence.

Here's the patch I wrote. It's a bit more complicated, but it's also a bit smarter. Also note that this patch assumes the levels are sorted by width, bitrate.

[jeroen]

This should actually be worked around by not providing the width in bitrate levels. That way, the player doesn't take width into account for switching logic.

In sum:

• If there's only a file per level, the player selects the first level it can play.
• If there's file and bitrate, the player sorts by bitrate, descending and selects the first level that fits.
• If there's file and width, the player sorts by width, descending and selects the first level that fits.
• If there's file, bitrate and width, the player sorts by bitrate, descending then by width, descending and selects the first level that fits.

If none of the levels fit, the player takes the lowest quality one.