v3.13.0

Release v3.13.0 (2019-05-15)

Overview

The v3.13.0 mainly brings minor fixes:

• we removed most references to the user clock, to resolve an issue that could arise if people updated their system clock while watching a live content
• we added a property called disableMediaKeysAttachmentLock to the keySystems loadVideo option, to get out of a deadlock when playing encrypted contents in some set-top-boxes
• we added more default codecs to our MediaKeySystemAccess default configuration. Again to be able to play encrypted contents on more peculiar devices
• we resolved some API problems for DASH multi-period contents

Limit reliance on the user's clock

To avoid synchronization issues, we try to avoid relying on the user's clock. However, we still stored internally several offsets relative to it.

One of these offsets was the presentationLiveGap. It is the difference between Date.now (which represents unix time) and the current last segment announced in the manifest.
Thanks to that variable, we could guess if new segments had time to be generated in the Manifest before refreshing it, Date.now acting here as a time counter since the time the Manifest was last downloaded.

That trick worked pretty well but there was still an issue we initially didn't consider: the user clock is not always linear. For example, two events can mess with our "time counter":

• the user updates its local clock
• Date.now assumes that there's always 86,400,000 milliseconds per day, as such leap seconds are ignored

The second problem was already known but ignored. Leap seconds are rare enough and the disagreement small enough that it basically doesn't matter.

The first one however was less expected. Someone messing with its clock while playing a content could lead to bad situations, like buffering for a very long time.

The current solution found was to stop relying on Date.now which is too much linked to the user's clock, but to rely on performance.now as much as possible instead. performance.now is guaranteed to increase monotonically over time so it's a perfect match here.

disableMediaKeysAttachmentLock

We found an issue with our EME (DRM) implementation on multiple set-top-boxes:

To be able to play contents mixing encrypted and unencrypted media on Chrome, we had to add a lock, which waited for the media element to have decryption capability before pushing media segments to it.
In better terms, it means that the object that provide decryption capabilities (MediaKeys) had to be "attached" to the HTML5 video element before we begin to play.

However, we found that in some peculiar devices (like some set-top boxes) this can create a deadlock: the browser in those sometimes wait for some content to be loaded before validating this attachment.

To allow people to activate or disable this lock we added a disableMediaKeysAttachmentLock boolean to the keySystems option you can set to loadVideo.

You can use it if you experience troubles playing encrypted contents in a specific environment.

This option is documented here.

Changelog

Features

• eme: add disableMediaKeysAttachmentLock key system option to bypass a deadlock (with possible tradeoffs) when playing encrypted contents on some peculiar devices

Bug fixes

• dash/smooth: never rely on Date.now when calculating time differences to avoid issues when the user adjusts the system clock while playing a live content
• eme: throw a better error (avoid toString is not a function messages) for a KEY_LOAD_ERROR when the getLicense function provided fails without a proper error
• api: fix rare situation with DASH multi-period contents where we reported no available bitrate, Adaptation nor Representation when switching to another Period.

Other improvements

• eme: add other default contentTypes when calling requestMediaKeySystemAccess to improve device support
• demo: update the demo UI
• code: change indentation style of a big chunk of the code to increase readability