Add Level Manifest recovery

[NicolasSiver]

Description of the Changes

Ability to recover from the failure is an important part of good playback experience. By this time we had a segment zigzagging feature (the feature where we would hunt for a playable segment through all available levels and jump from primary to backup streams and back).

We are going introduce the same "zigzagging" logic for level manifests. Another benefit, that all these behaviors are driven by retry configuration for both: segments and levels. To complement feature, playlist loader was adjusted to not create extra retry requests, since all retry management is completely managed by Level Controller.

How does it work?

If you have a backup stream, it will look like a zigzagging hunt for the "available" segment/level manifest:

Where: F - Bad Fragment, L - Bad Level

As you can see, if you don't have enough extra renditions, recovery logic will not be able to add extra value to your platform.

Retry Recommendations

If you have 4 renditions and a backup stream:

• Level: don't use total retry less than 3 - 4
• Fragment: don't use total retry less than 4 - 6
• Implement short burst retries (i.e. small retry delay 0.5 - 4 seconds), and when library returns fatal error switch to a different CDN

Notes:

• resolve Faulty playback of Alternate-Audio Playlists with Primary/Backup, if Primary returns 404 (since hls.js 0.8.3) #1438
• resolve Typo in comment #1446

CheckLists

• changes have been done against master branch, and PR does not conflict
• no commits have been done in dist folder (we will take care of updating it)
• new unit / functional tests have been added (whenever applicable)
• Travis tests are passing (or test results are not worse than on master branch :))
• API or design changes are documented in API.md

[mangui]

thanks @NicolasSiver
it would be great to add your PR explanation (with the pic) in design.md !

[mangui]

if my understanding is correct, in case of levelError with redundant streams available, we first schedule a setTimeout(() => this.loadLevel(), delay); then we switch to redundant a couple of lines after ?

[NicolasSiver]

Right. Logic for zigzagging is for both: levels and fragments (condition: levelError ===true || fragmentError === true). Where level specific logic (since we also handle Retry Management for levels in the level controller) happens a bit earlier because we can reach the limit and we have to produce fatal error.

By placing level related logic at first, we have the opportunity to bail out in a bit more DRY way.

[NicolasSiver]

@mangui added notes to Design document.

[mangui]

LGTM, a second pair of eyes might be useful.

[johnBartos]

Not a big fan of the irregular whitespacing here since it breaks convention with the rest of the codebase (and if we decide to upgrade our linter to something like eslint, this may give us problems)

[NicolasSiver]

It will not. We use eslint. It's a common technic for big inline object representations.
JSHint does not have a warning for that structure. There is a big issue, it's when a line is longer than 80-120 characters. As you can see, in this review you already don't see all line.

[johnBartos]

Ok fair enough. Since it's a matter of opinion I'm fine with it as is

[johnBartos]

To me, the spec implies we should go to auto:

In the event of an index load failure on one stream, the client chooses the highest bandwidth alternate stream that the network connection supports.

Going to auto should also handle the case where we don't have a level below (but may have one above)

[IvanRF]

@NicolasSiver when I saw this commit I thought it was the solution to my current issue, but apparently not. Does it work only for backup streams?

I have only Bad fragments (404 errors) for 360p & 480p but the player never reached the 720p level. It throws a fatal error.

I opened a new issue here: #1458