DRM: Reload when playback is unexpectedly frozen with encrypted but only decipherable data in the buffer

[peaBerberian]

Note: This may be a controversial PR :p, don't hesitate to exchange here if you see problem with this logic or if you have ideas for improving it.
This should only impact contents relying on DRM.

---

The majority of our bugs are now DRM-related and device-specific, generally platform lower-level (CDM, browser integration...) bugs. Even if we very frequently exchange with partners to obtain fixes, this is not always possible (sometimes because there are too many people relying on the older logic and thus risks in changing it, sometimes because there are a lot of higher priorities on their side).

We are now encountering frequently, for some contents with DRM, what we call a "playback freeze": playback does not advance despite having data in the buffer, all being known to be decipherable (we know that we have pushed a license and that their linked key has a key id set to "usable" in the corresponding MediaKeyStatusMap).

Recently we've seen this similar issue on Microsoft Edge, UWP applications (Windows, XBOX...) and LG TV.

In all of those cases, what we call "reloading" after the license has been pushed always fixes the issue. The action of reloading means principally to re-create the audio and video buffers, to then push again segments on it.
Other work-arounds may work on some platform, but do not seem to work on other.

Although we prefer providing more targeted fixes or telling to platform developpers to fix their implementation, this issue is so frequent that we're now wondering if we should provide some heuristic in the RxPlayer, to detect if that situation arises and reload in that case, as a fallback mechanism.
The logic being the following: we prefer to reload over having an infinite loading or buffering phase.

What we are most afraid here is the risk of false positives: falsely considering that we are in a "decipherability-freeze" situation, where it's just a performance issue on the hardware side or an issue in a segment.

To limit greatly the risk of false positives, here are the rules that will lead to a reload under that heuristic.
All sentences after dashes here are mandatory:

• we have a readyState set to 1 (meaning that the browser announces that it has enough metadata to be able to play, but does not seem to have any media data to decode)
• we have at least 6 seconds in the buffer ahead of the current position (so compared with the previous dash, we DO have enough data to play - generally this happens when pushed media data is not being decrypted).
• The playhead (current position) is not advancing and has been in this frozen situation for at least 4 seconds
• The content has at least 1 audio or video Representation with DRM.
• One of the following is true:
  1. There is at least one segment that is known to be undecipherable in the buffer (it should not happen, the RxPlayer already preventing this situation elsewhere, this was added as a security)
  2. There are ONLY segments that are known to be decipherable (licenses have been pushed AND their key-id are all "usable") in the buffer, for both audio and video.

If all those conditions are true we will reload. For now with no limit (meaning we could have several reloads for one content if the situation repeats).
Note that at the request level, this only might influence segment requests (which will have to be reloaded after 4 seconds) and not DRM-related requests nor Manifest requests.

We tested that logic with success on some of the problematic devices.

We're now in a testing/reviewing phase where we are testing and considering the false positive risks, we're still adding and removing tweaks to the conditions.

This is only planned to be added on the v4 for our official release, for API-breakability reasons BUT we plan to test it internally at Canal+ in some special v3 pre-releases, to ensure that this works well.