v3.11.0

Release v3.11.0 (2019-03-07)

Overview

This release mainly add two new features:

• languages/api: add the notion of preferred audio and text tracks, much more flexible than the previous default track configuration.
• allow playing a mix of unencrypted and crypted contents on Chrome. We're now able to do that at least in Chrome, Firefox and Edge (we did not test that usage on Safari yet).

It also adds multiple bug fixes and other little improvements, the most important ones being:

• minimumUpdatePeriod DASH attributes were accidentally ignored, we manage that again
• For smooth contents, you have now much less risk to encounter 412 HTTP requests
• For TypeScript users, the addEventListener and removeEventListener are now completely type-checked. Each event is linked to its corresponding payload.
• Each warning and error has now a readable string as their message attributes.

Language preferences

To permit much more control over language preferences, we added 4 new methods (setPreferredAudioTracks, getPreferredAudioTracks, setPreferredTextTracks and getPreferredTextTracks) and 2 new player options (preferredAudioTracks and preferredTextTracks).
Those take or return an array of audio or text track preferences (from the more preferred to the least preferred) and can be changed at any time: when a content plays as well as when no content is playing.

Those two specificities are particularly interesting for multi-period DASH contents, where you can have much more control over languages we automatically choose for subsequent periods.

Those new methods and properties and the corresponding behaviors are all defined in our documentation. Here are quick links for each of them:

• preferredAudioTracks player option
• preferredTextTracks player option
• setPreferredAudioTracks method
• getPreferredAudioTracks method
• setPreferredTextTracks method
• getPreferredTextTracks method

Consequently, the defaultAudioTrack and defaultTextTrack loadVideo options are now deprecated. To help you switch from them to the new APIs, we added a chapter in our documentation about deprecated APIs.

Mix of crypted and unencrypted contents on Chrome

We previously were unable to switch from an unencrypted segment to an encrypted segment in Chrome. Those "mixed contents" would buffer indefinitely when doing that switch.

This was because our previous logic tried to perform DRM negociations lazily (only when DRM is needed):
When first playing an unencrypted content we did dot initialize encryption-related logic, this was done just after the first encrypted segments was downloaded.

This strategy sound smart on paper but did not work with how Chrome implemented those APIs. We thus now begin to perform that logic immediately when starting the content (usually at the same time at which we fetch the manifest file) which is what most browsers expect. This behavior works at least with Chrome, Firefox and Edge. Safari was not tested, please let us know if you have related problems on it.

Note: This initialization only happens if the keySystems loadVideo option contains at least one key system, to avoid doing that unnecessary logic for contents we know to be unencrypted.

Less 412 HTTP errors for segment requests with Smooth streaming contents

After our last versions were deployed on multiple Canal+ applications, we saw a huge bump in our request error metrics: a lot of our segment requests were failing with a 412 HTTP error for HSS (Smooth Streaming) contents.

This usually means that we are requesting a segment before it was actually generated on the server-side.
This can be provoked by inferring future segments from the metadata of previous ones, and then requesting them too soon.

We now avoid those errors by doing a better estimation on which segments should be available on the server. This is done by considering the last manifest we downloaded and calculating the amount of elapsed time since.

As an example, we won't download a segment ending at a timestamp of 50 seconds if a manifest downloaded 10 seconds ago ended with a segment at a timestamp of 30 seconds (the max on the server now would be 30+10=40s).

addEventListener and removeEventListener type safety

We worked on improving type safety on the player in this release. If you're using TypeScript, you could now have type errors with addEventListener and removeEventListener depending on how they were used: the payload type is now correlated with the event string.

This brings several advantages:

• your calls will now be type-checked. You should thus detect more errors if you are using those methods wrongly
• depending on your editor and plugins, you could now have a nice contextual auto-completion when writing event listeners

Five new player events

Speaking of events, we added five player events we thought were missing. Those are (linked to their corresponding documentation):

• availableAudioTracksChange
• availableTextTracksChange
• availableVideoTracksChange
• availableAudioBitratesChange
• availableVideoBitratesChange

Changelog

Features

• languages/api: add preferredAudioTracks and preferredTextTracks player options
• languages/api: add setPreferredAudioTracks, getPreferredAudioTracks, setPreferredTextTracks and getPreferredTextTracks methods
• languages/api: add availableAudioTracksChange, availableTextTracksChange and availableVideoTracksChange events
• abr/api: add availableAudioBitratesChange and availableVideoBitratesChange events
• eme: allow playback of mixed encrypted and unencrypted contents on Chrome
• types: export the new IAudioTrackPreference and ITextTrackPreference types

Deprecated

• languages/api: deprecate the defaultAudioTrack loadVideo option in favor of the preferredAudioTracks player option.
• languages/api: deprecate the defaultTextTrack loadVideo option in favor of the preferredTextTracks player option.

Bug fixes

• dash: fix minimumUpdatePeriod management for DASH contents
• smooth: better prevent 412 HTTP errors for smooth streaming contents
• subtitles: ensure subtitles are not visible in Firefox when disabling them in the "native" textTrack mode.
• errors: avoid sending multiple MEDIA_TIME_BEFORE_MANIFEST or MEDIA_TIME_AFTER_MANIFEST warnings instead of just one
• api: fix (deprecated) option hideNativeSubtitles

Other improvements

• errors: set a readable error message for every error and warnings thrown
• tools/mediaCapabilitiesProber: set logs about unimportant missing APIs as debug-level instead of warn-level
• types: provide type safety to addEventListener and removeEventListener

v3.10.3

Release v3.10.3 (2019-01-30)

Overview

This release brings multiple minor fixes:

• dash: fix getMinimumPosition API for live contents
• webvtt: default classes are now supported. Multiple webvtt-related fixes have also been brought.
• smooth: we are much more tolerant on the ISOBMFF segments downloaded
• subtitles: fix bug which could prevent some subtitles from being removed (e.g. when disabling them)
• abr/buffers: fix a remaining delay in quality changes happening in rare situations (like when updating the maxVideoBirate very quickly multiple times)
• a lot of other minor fixes (see the Changelog below)

We also continued our efforts on improving unit test coverage by going from a code coverage of 22% in the v3.10.2 to 33.6% now. As written in our previous release, we still target a code coverage as close to 100% as possible to improve our confidence on the new code we release.

fix getMinimumPosition for DASH contents

In the v3.10.1, we improved the code which calculates the minimum position of a manifest. However when doing so we misused an attribute of an MPD, availabilityStartTime.

This little error made the getMinimumPosition API return inexact value when the availabilityStartTime was not set to the unix epoch (1970-01-01 00h00m00s). This API is often used to detect where a user can seek in the current content.

This same issue could also lead the player to send multiple MEDIA_TIME_BEFORE_MANIFEST warnings when it shouldn't be the case.

To prevent the same issue to happening again, new tests have been added with the concerned situation.

WebVTT improvements

We now support default WebVTT classes. These classes (which are text colours and background text colours) can be applied to cue elements on WebVTT, without the need to redeclare the associated styles in the subtitle file.

We also brought several minor fixes (described in the Changelog at the bottom of this release note), which should improve the support of more sophisticated WebVTT :

• If several style blocks define styles for the same class or tag, all styles are now considered (not only the last), and so applied on the HTML element.
• If a cue was concerned by both global and class styles, there was a mismatch between the applied styles and the concerned classes/tags. This was leading to the inconsistent visual aspect of HTML subtitles. This is not happening anymore.
• Before, we removed whitespaces from declared CSS. This was leading to badly formatted styles (to bottom became tobottom). We don't replace whitespaces anymore and apply parsed CSS as it is in the WebVTT.

With those improvements, we also took the opportunity to add unit tests of the webvtt-to-html parser, to fully cover this part of the code.

Smooth segment tolerance

We previously had a very rigid management of ISOBMFF (.mp4) segments when using the "smooth" transport type. Segments which had some metadata in another order than what was expected were often rejected.

To improve our flexibility with such contents, we updated our logic to make much less assumption about how the segments should look like. The player should now handle any segment as long as it is a correctly formed ISOBMFF media (i.e. not incoherent and not missing crucial informations).

...And more

We brought a lot of other minor fixes in that release. This is most notably due to our improvements in testing-related matters. Because it's a good thing, we plan to continue our efforts towards unit test coverage and integration tests.

You can read the Changelog for more information on the corresponding fixes.

Changelog

Bug fixes

• dash/api: fix getMinimumPosition for MPDs with an availabilityStartTime superior to unix epoch
• smooth: be more tolerant on downloaded segments (accept ISOBMFF with boxes in any order)
• buffers/abr: fix issue infrequently leading to a delay in quality changes
• buffers: improve synchronisation to the SourceBuffer's buffer to avoid cases where the same segment could be downloaded multiple times
• subtitles: fix bug in the clean-up logic of subtitles in the "html" texttrack mode that would lead to removed subtitles still being displayed
• compat/subtitles: work-around firefox issue in the "native" texttrack mode to ensure track cues are removed when the content is stopped
• subtitles/webvtt: support default classes in the WebVTT specification
• subtitles/webvtt: multiple styles for the same element are now merged into one (instead of considering only the last one)
• subtitles/webvtt: fix styling issues when both styles applied globally and styles applied on a selector are defined
• subtitles/webvtt: do not remove whitespaces in styles to keep a sane formatting for some complex values

Other improvements

• dash: warn through logs when fields are not in the expected format
• drm: throw more explicative error messages when DRM are not supported in the current target
• dash/smooth: get more precize duration from ISOBMFF by better handling the default duration taken from the tfhd box
• tests: continue unit test coverage improvements (from 22% in the v3.10.2 to 33.6%)
• demo: fix initial text-track selection

v3.10.2

Release v3.10.2 (2019-01-08)

Overview

This release mainly fixes two issues:

• One in our manifest refreshing logic that prevented some MPDs/Manifests to be refreshed.
  To be exact (and technical), this issue mainly impacted DASH dynamic content in a SegmentTimeline indexing scheme without SegmentTemplate.

  As it is not the first time we had an issue in this area of the code, and as it is sensitive enough, we also decided to double our efforts on unit testing.

• The second, that we tried to fix already in the v3.10.1 release is a better workaround to an Edge/Playready issue with initialization data: Some contents with DRMs could not be played on the Edge Browser.

Manifest-refreshing bug

Some Manifests were never refreshed (mainly DASH contents, but also Smooth ones in some specific use-cases) due to an unfortunate mix-up made in the v3.10.1 release.

We also improved on the interval at which some DASH MPD were refreshed. It should now happen less often.

DRM issue on Edge

The work-around we brought to a IE11/Edge issue with encrypted contents in the v3.10.1 did not seem to provide good enough results with our test contents.

We now adopted another strategy, which is to move CENC PSSH boxes at the end of the initialization data.

Simply put:

• previously we made two tries on IE11/Edge: one with the problematic data, the second without (only called if the first failed)
• now we directly put the problematic data at the end on the first try

This new method provided better results with our test contents. Do not hesitate to open an issue if you still experience KEY_GENERATE_ERROR errors with encrypted contents on IE11/Edge.

Jest and unit testing

To limit regressions like the one we fixed in this release, we decided to put more and more of our time on tests.

Multiple months ago, we reinforced our end-to-end tests which automatically launch contents, perform some manipulation on them (change the speed, seek everywhere) and check that everything is ok.

If those tests definitely helps us to ship new releases confidently, we still had specific areas of our code that was vulnerable. One of those was live contents, for which end-to-end tests are difficult to write as those evolve over time.

For those issues, we tried to implement a reliable unit testing strategy for the v3.10.1. However, we went into multiple problems: the tools we used at the time were not adapted. After taking different paths, we decided to rely on Jest running in a Node.js environment for our unit tests.

This choice was mainly motivated by the fact that it was the less troublesome tool to use with our specific situation (TypeScript code + TypeScript tests, globally defined variables, coverage reports, high necessity of dependency injection).

We're now happy to announce that the unit test coverage of our code went just from a (minuscule) 13% in the v3.10.1 to a (less minuscule) 22% in the v3.10.2, and that only in a few days! We concentrated our efforts on sensitive parts of our codebase for now but we definitely want to approach as much as possible 100%.

For now however, at least 10% more coverage for each release seems to be a doable objective.

Changelog

Bug fixes

• dash/smooth: fix manifest updates for some DASH contents (SegmentTimeline without SegmentTemplate) and for some Smooth usages
• compat/drm: adopt a new strategy for malfunctioning CENC PSSH on Edge by moving them at the end of the initialization data
• dash/smooth: update deprecated Manifest.adaptations property when updating the manifest

Other improvements

• dash: refresh the MPD less often
• dash/smooth: improve precision of getMaximumPosition when the Manifest is updated
• tests: use the Jest library for unit tests
• tests: add a lot of unit tests to sensitive code (from a coverage of 13% in the v3.10.1 to 22% in the v3.10.2)
• npm: reduce size of the npm package

v3.10.1

Release 3.10.1 (2019-01-03)

Overview

The v3.10.1 fixes minor issues:

• adaptive: fix an issue which could lead our adaptive logic to be less performant
• drm: fix issue with Edge and IE11 where encrypted content could not be played
• dash: become more tolerant on what DASH MPD we accept
• dash/smooth: throw a clearer MANIFEST_PARSE_ERROR when the MPD/Manifest given propose an audio or video track with no supported codec

Behind the hood, it also embarks a cleaner code architecture - which will help us to bring future improvements (improved adaptive streaming, xlinks in onResolve mode...).

adaptive: fix non-urgent switches issue

In the v3.9.0 release, we brought support to non-urgent quality switches. The difference between an "urgent" and a "non-urgent" quality switch is that:

• an urgent switch will interrupt any download of the previous quality and begin to download the new one
• a non-urgent one will wait before the previous quality finishes its download before truly switching the quality

However, we had a bug in this logic. If multiple switches were triggered while an old quality did not have time to finish to download - which is the case if at least the first one was non-urgent - only the first quality switch would then be taken into account (instead of the last one).
This behavior would then continue and the result would be a lag in quality switches.

This is now fixed.

DRM/EME: Fixed issue with Edge/IE11

An issue localized somewhere between the Edge and IE11 browser and the PlayReady CDM prevented the RxPlayer to play some encrypted content.

On some contents containing a CENC (for Common ENCryption) PSSH, which simply put, is a part of an MP4 file containing encryption-related informations, the browser would reject those informations leading us to stop the content and emit an EncryptedMediaError.

The CENC PSSH in itself was well-formed and should have worked with any browser. With that in consideration, we decided to adopt a safe strategy:
For now, if encrypted informations which contains such metadata is not accepted by IE11 or Edge, we will retry without that data. If it fails again, the usual EncryptedMediaError error will be thrown.

DASH: MPD tolerance improved

We accept now much more DASH's MPD than in the previous thanks to the following improvements:

• In SegmentTimeline-based MPD, we now support S nodes which have their r ("repeat") attributes set to -1 (which means, repeat indefinitely)
• In SegmentTimeline-based MPD again, we also now infer the time of the first S node if it was not declared as its t attribute
• we now better calculate the minimum time we can seek to in an MPD

DASH/Smooth: throw better error when no audio or video codecs are supported

After downloading a DASH/Smooth MPD/Manifest, we usually filter out media with a codec not supported in the current browser.

We can arrive in a case where the MPD/Manifest announce video and audio tracks, but one of those have none of their codecs supported. As a player, we face now two choices:

• we could play the content without audio or video
• we could throw to warn the user that this content is not supported

Although the first case could look like the better solution, real-life cases made us prefer the second one, as such contents are not intended to be shown without audio or video.

Previously, the fatal error sent was very cryptic (about not being able to read "length of undefined"). Now, a proper MANIFEST_PARSE_ERROR with a descriptive message is sent instead.

Code architecture refresh

For those interested in our code architecture, we also refreshed our code and updated our modules to be easier to follow:

• the Stream is now renamed the Init, as its main role is to initialize and start every modules necessary to play a content. The name is of course short for "initialization".

• the net directory has been renamed transports, its role being to define a layer where streaming protocol-specific loading and parsing takes place (and not just for internet request as the previous name could indicate)

• the complex buffer directory has been renamed buffers and separated into clear sub-modules:

  • The PeriodBufferManager has been renamed the BufferOchestrator: its role is to create the right PeriodBuffers at the right time and to react to their events.
  • The PeriodBuffer is now clearly defined in its own directory (it was previously included in the PeriodBufferManager). Its role is to create the right AdaptationBuffer depending on track choices.

• multiple "somethingManager" have been completely renamed to better communicate what their role are. For example the MediaErrorManager became throwOnMediaError and the SpeedManager was renamed updatePlaybackRate.

The code architecture documentation has been properly updated.

Changelog

Bug fixes

• abr: always consider the last quality estimation
• drm: work-arround Edge bug where the browser does not accept a valid CENC PSSH (DRM-related information in an ISOBMFF)
• dash: handle S nodes (segments) with an @r attribute at -1 in an MPD
• dash: handle SegmentTimeline which have as a first S node (segment) an undefined @t attribute in an MPD
• dash: Representation.index.getLastPosition() for SegmentBase-based DASH Representations now returns the end of the last segment (it returned the start of the last segment before)
• dash/smooth: throw better error (MANIFEST_PARSE_ERROR) if none of the audio or video tracks of a content can be played (e.g. none have supported codecs)

Other improvements

• manifest: better infer the minimum time of a Manifest
• code: refresh code architecture (rename and move modules, remove some dependencies...)
• tests: add coverage reports for both unit and "integration" tests, to check where tests are lacking and better pin down our hot-spots
• tests: add appveyor countinous integration service for unit tests

v3.10.0

Release 3.10.0 (2018-12-11)

Overview

The v3.10.0 brings a lot of features and improvements:

• dash: the player now handle DASH' XLinks in "onLoad" resolution mode
• dash: adaptation-set-switching is now available
• compatibility: we improved the API to allow a cleaner management of browsers restrictive autoplay policies
• compatibility: we fixed many other compatibility issues and inconsistencies
• and more

DASH: XLink management for the "onLoad" resolution mode

XLink is a specification allowing to refer to external links in a given XML document. In the context of DASH, it can be used to define a single or multiple Periods not directly in the Manifest, but via another external ressource.

DASH' XLinks can come in two flavors:

• in an "onLoad" resolution mode: the corresponding link is loaded as soon as the Manifest is loaded

• in a "onRequest" resolution mode: the corresponding link is only loaded when we need it.

For the moment, only the onLoad flavor is handled, but onRequest support should come very soon in one of our next release.

DASH: adaptation-set-switching

The RxPlayer already handle advanced DASH features such as multiple media licenses for different media qualities.

This comes with several drawbacks however, such as the obligation to divide such qualities into separate DASH AdaptationSets, which the player precedently handled as different unrelated tracks. To allow seamless switching between those, we had to support a specific DASH feature called adaptation-set-switching.

As managing this advanced feature could complexify a lot our API, we decided to provide a straightforward implementation: "switchable" AdaptationSet having similar characteristics are now merged into a single RxPlayer's Adaptation.

This means that the RxPlayer definition of an Adaptation is slightly different than a DASH AdaptationSet. To clarify that difference, we decided to add a new documentation page.

Better autoplay policies management

Due to browser's policies a play action can be completely blocked by the browser. This is often done as a mechanism to prevent a video from being played without any user interaction.

To alert users when a call to play failed, we decided to bring two new features:

• a "MEDIA_ERR_METADATA_NOT_LOADED" warning will be sent when a play call is blocked by the browser. This is documented in the errors documentation
• play now returns a Promise, which mirrors the same Promise coming from the browser.

Compatibility improvements

As with the last releases, we continue towards improving our compatibility across all browsers:

• we added a new warning: "MEDIA_ERR_METADATA_NOT_LOADED", triggered when we're unable to load the current content. For the moment, this problem has only been seen on the Samsung mobile browser, when playing a content in directfile mode. This error is documented here.

• we re-defined when our LOADED state should be set, to be sure it is the same definition across all browsers. Until now, the state could arrive too soon on Firefox leading sometimes to a SEEKING or PAUSED state without any interaction.

• we fixed an issue we had with Smooth Content on Edge, which prevented some contents to be played with that browser

• we fixed an issue we had with the MediaCapabilitiesProber on Safari

• we provide an implementation of Promise for browsers not supporting it

Deprecating NetworkError "xhr" property

To prepare the management of CMAF low-latency and other advanced features, we decided to deprecate the xhr property, as found in a NetworkError.

This is because those new features might lead us to use the fetch API instead of an XMLHttpRequest, which is necessary in the current NetworkError API.

Changelog

Features

• dash: Manage xlinks in "onLoad" resolution model
• dash: Implement AdaptationSet switching by merging similar and switchable AdaptationSet into a single track
• compat: add MEDIA_ERR_METADATA_NOT_LOADED warning, triggered when the browser has issues with loading the initial data (only seen on the Samsung mobile browser in directfile mode)
• compat: add MEDIA_ERR_PLAY_NOT_ALLOWED warning, triggered when the application tries to play but the current browser doesn't allow it (often due to autoplay policy)
• api: the play API now returns a Promise, mirroring the original browser's play API

Deprecated

• api: The xhr property from a NetworkError is now deprecated

Bug fixes

• compat/smooth: fix fatal error BUFFER_APPEND_ERROR happening on some HSS contents with Edge
• dash/smooth: never refresh the manifest if its content is not dynamic
• dash/smooth: use new URL if the initial manifest request is redirected (again :/ - thanks @fnatte)
• api: do not go out of the LOADING state if the metadata could not be fetched (even if the browser tells us otherwise) - to work around Samsung Browser bug
• api: avoid going out of the LOADED state until the initial seek is done and metadata is fetched
• compat: use Promise ponyfill to improve IE11 compatibility with the MediaCapabilitiesProber and some EME functionalities
• api: translate most IETF language tags into corresponding ISO639-3 codes for the normalizedLanguage property - given from APIs such as getAvailableAudioTracks
• tools: fix mediaCapabilitiesProber.getCompatibleDRMConfigurations experimental tool on Safari
• api: filter out duplicates in getAvailableVideoBitrates and getAvailableAudioBitrates

Other improvements

• dash: better infer unknown Period durations
• dash: better manage overlapping Periods by giving more importance to the last chronological one
• memory: clean-up Adaptation and Representation informations on Periods which are not considered anymore
• log: warn through our logs every time a warning event is sent by the API
• demo: authorize DRMs in IE11 or Safari when in HTTP in the demo page
• demo: fix time indication for non-live contents

v3.9.3

Release 3.9.3 (2018-11-23)

Overview

The v3.9.3 fixes minor compatibility issues and continue our efforts toward reinforcing our automated tests.

Compatibility issues with IE11

There were two compatibility issues that could arise mainly with Internet Explorer 11:

• some code in our adaptive logic used called Object.values, which is not defined in that browser (as well as in old webkit versions which we use internally)
• the mediaCapabilitiesProber.getCompatibleDRMConfigurations called Array.prototype.find, which is not available in IE11 as well

Thankfully, most of our users seem to use polyfills which allow to completely avoid those issues.

We could use polyfills in the Rx-player but we voluntarly choose not to. This is because as a library, we avoid doing any side-effect that could conflict with another codebase (for example, our polyfill could overwrite yours, which could have more features).

As this is not the first time we used an API not available in IE11, we now added an automated check in our validation process which alerts us when such API call is written in our code.

This should avoid most issues of the same type in the future.

Compatibility issue with Safari

A very specific compatibility issue was found on Safari, where a modification we did on the MediaKeys object could provoke issues when using another DRM-aware media player.

This side-effect was written as part of a legacy code to improve our compatibility with older browsers.
Since then, monkey-patching has been a banned practice in the player, again to make sure our library does not conflict with your codebase.

By the way, the RxPlayer should now be (finally) completely free of such patches 🎉

EME optimization on Edge

We have an EME (DRM)-related optimization in the RxPlayer, which allows the player to re-use created key sessions.
This allows to load an encrypted content much faster when that content was already loaded before.

However, our previous logic did not allow the Edge browser to profit from that optimization, as we had a really conservative way to authorize it (basically, it was forbidden because IE11 could not profit from it).

We now became confident enough to allow this optimization on Edge.

Automated tests reinforcement

After the HSS issue which triggered the v3.9.2 release (about not accepting empty tracks), we became a lot more realist of our ability to completely avoid or at least detect in advance regressions.

Our current validation policy involves running automated tests and manual "shallow" checks. Unfortunately, we do not have the ressources necessary to manually check every edge case (nor do we think that this would be efficient).

That's why we are currently putting a lot of effort towards automated tests. Those are mainly validating the behavior of the library as a whole and its effect on a page as we believe that such tests are especially adapted to a media-player library.

We now automatically check for that HSS regression (as well as other, older ones). We will from now on try to do the same thing for most encountered issues in the future ("most" as many are only reproducible on specific browsers for which it's hard to launch tests from) and for new features.

Changelog

Bug fixes

• compat: fix undefined Object.values function issue happening in some older browsers (mainly encountered in IE11 and old webkit versions)
• compat: remove side-effects relative to DRM on Safari
• tools: fix issue about an undefined Array.prototype.find method in some older browsers when calling mediaCapabilitiesProber.getCompatibleDRMConfigurations (mainly encountered in IE11)

Other improvements

• eme: activate MediaKeys caching on Edge
• compat: add in our validation process a ban of methods and functions unavailable in older browsers
• tests/smooth: reinforce our Smooth Streaming integration tests

v3.9.2

Release 3.9.2 (2018-11-14)

Overview

This (very small) release fixes a bug introduced in the v3.9.1.
In this version, the player threw if a smooth Manifest proposed an audio, video or text track without any segment (an empty track).

We fixed that issue by being more resilient in that case: empty tracks are now correctly managed (even if switching to them has no utility).

As this is a playback-stopping issue, and as this case is encountered by some of our users, we decided to directly ship a release with only this fix.

We're sorry for the inconvenience, we will write a corresponding automated test in the following release to make sure this type of issue cannot happen again.

Changelog

Bug fixes

• smooth: authorize empty tracks ("StreamIndex") in Smooth manifests

v3.9.1

Release 3.9.1 (2018-11-13)

Overview

This release fix issues regarding the manifest-refreshing logic for both Smooth and DASH:

• for smooth contents, the player could stall indefinitely when playing a live content close to the live edge and switching a text, audio or video track

• for dash contents with a minimumUpdatePeriod attribute and a customManifestLoader argument given to loadVideo, the manifest could be refreshed too often

To lower the memory usage when playing Smooth live contents for a long time, we also now clean-up regularly the informations we have on segments becoming unreachable.

Infinite rebuffering issue with Smooth live contents

The main fix concerns Smooth contents, where the player could stall indefinitely when playing live contents.

It was due to two issues in our Smooth Manifest refreshing logic:

• we overwrote the previous segment informations we had when refreshing the manifest
• we had a time-conversion error which prevented emergency Manifest updates to happen

This could mostly be experienced when switching to another audio track in specific situations (live content, close to the live edge...), those two issues could combine and lead ultimately to a player staying in a rebuffering state.

This release fixes both of these issues.

Changelog

Bug fixes

• smooth: fix issue preventing emergency manifest updates
• dash: fix timeout for minimumUpdatePeriod in cases where the time at which the manifest was last requested is not known (like when setting a customManifestLoader argument)

Other improvements

• smooth: keep supplementary segment informations when updating the manifest
• smooth: when updating segment informations, perform garbage-collection of those concerning unreachable segments

v3.9.0

Release 3.9.0 (2018-11-08)

Overview

The v3.9.0 brings some new features and continue our serie of improvements made on the adaptive side.
Most notably, it brings:

• management of the minimumUpdatePeriod attribute for DASH contents
• seamless codec-switching for browsers supporting the changeType API
• a more intelligent bitrate-switching algorithm, which can decide to let the current segment requests to be finished before switching

As an enjoyable side-note, this release contains three outside contributions:

• @fnatte worked on the initial minimumUpdatePeriod feature and on a TypeScript typing bug.
• @necccc worked on reducing the size of our npm package (which is now divided by three!)

Thanks again to both of them.

minimumUpdatePeriod

minimumUpdatePeriod is an attribute found in DASH MPDs which indicates an interval at which the manifest should automatically be refreshed.

The RxPlayer previously refreshed the manifest only when it needed it (this usually means when available segments it needs were not yet declared in the last downloaded manifest), which is fine in most cases.

Now, we also consider the minimumUpdatePeriod to decide when to refresh it.
This allows more complex usecases where the manifest can change unexpectedly over time (e.g. an evolving timeshift window).

Codec-switching thanks to the changeType API

The changeType API allows us to seamlessly transition from one codec to another.

In the RxPlayer, we now detect when the content is switching to a new codec and call changeType if this API is available.
Please note however that this API is very new (at the moment, it is only in Chrome 70+ and Firefox 63+).

adaptive improvements

We worked a lot on our adaptive streaming algorithm lately, which is the part of the code deciding which video or audio quality should be downloaded depending on the user's situation (such as its network bandwidth).

This is what we brought in the v3.9.0:

Bitrate switching urgency

We added a notion of "urgent" changes of video or audio bitrates.

Simply put, if a change is urgent, pending segment downloads relative to the old bitrate will be canceled, and segment downloads relative to the new bitrate will start immediately.
If a change is not urgent however, we wait for the current segment request(s) to finish before switching to the new bitrate.

Previously, only the urgent mode was available, which can be seen as more "costly" than the "not urgent" mode, because it means that we might throw some already-downloaded bytes.
The urgent mode has its own advantages though, it allows the player to adapt to the bandwidth more rapidly and can help to avoid rebuffering when the bandwidth fall down.

At the end, using both modes depending on the situation seems to be the best of both worlds. This is what we do now.

Raise the bitrate estimation frequency

We now perform new bitrate estimations much more often (each time we have a new bandwidth metric - usually after each request) than before (where it was at a regular interval and important user events).

This allows to react to new network conditions faster, most notably at the beginning of the content.

Fix priority updates

Segment priorities is an advanced fetching optimization. How it works can be simplified as such: we assign to each wanted media segment a "priority" depending on its distance with the current position (closer segments have a higher priority).
Every requests with the same priority can run at the same time, while those with a lower-priority wait for their turn.

This feature allows a great flexibility. Thanks to it, we can allocate more bandwidth to closer segments (to avoid rebuffering) and still optimize the bandwidth usage when we're considering distant segments (we can for example download an audio segment beginning in 25 seconds at the same time than a video segment beginning in 20 seconds).

As playback conditions evolve over time (for example, when the position in the content changes), those priorities can also need to be updated over time.
Previously, an issue prevented priority updates to be functionnal, this should now be completely fixed.

Memory tests

In our previous release (the v3.8.1), we fixed a memory leak we had for some time.
Because the RxPlayer targets devices with relatively important memory constraints (such as set-top boxes), this was a pretty big issue for us.

As a first step, we decided to add memory tests, specifically ensuring that the RxPlayer's memory consumption stays at an acceptable level. For now, only a single memory test is written, checking the memory usage after loading a video 1000 times. More should come in the future.

Changelog

Features

• dash: consider minimumUpdatePeriod attribute in MPDs
• buffer: add codec-switching for browsers supporting the SourceBuffer.prototype.changeType API
• dash/smooth: accept and parse segments with a "stpp.ttml.im1t" codec (TTML IMSC1 in MP4)

Bug fixes

• smooth: fix calculations of the initial time, duration and minimum position for HSS VOD contents not starting at a '0' time
• buffer: fix priority updates for segment requests
• dash: calculate VOD duration from the last period if undefined in the MPD's root
• dash: remove possibility of obtaining two periods with the same id
• typings: make manualBitrateSwitchingMode loadVideo option an optional TypeScript typing (thanks @fnatte again!)

Other improvements

• abr: do not always cancel pending requests when switching to a new bitrate
• abr: re-estimate the bandwidth immediately after each request
• buffer: remove automatic garbage-collection of the "image" source-buffer (its rules should be more complex than those in place)
• tools/mediaCapabilitiesProber: Make getCompatibleDRMConfigurations work under IE11 and old webkit versions
• tools/mediaCapabilitiesProber: Add a multitude of bug fixes to the experimental mediaCapabilitiesProber
• package: divide by more than 2 the size of our package published in npm (thanks @necccc)
• tests: add memory tests to detect memory leaks
• demo: add 'favicon' to the demo page

v3.8.1

Release 3.8.1 (2018-10-17)

Overview

The v3.8.1 fixes some issues and delivers some improvements on the adaptive side:

• fix memory-leak in adaptive logic
• set the right video quality faster on the first loadVideo
• perform better bandwidth estimation when downloading from misconfigured servers
• avoid re-attaching the optional serverCertificate at each quality switch for encrypted contents

Memory leak in adaptive logic

We found out that a callback performing some computations useful for adaptive streaming was never cleared, even when the content was stopped.
This dates back from some time (v3.5.2) and was due to a still ongoing issue with RxJS, the main library we use.

As this callback only performed relatively simple computations without interacting much with the rest of the code, the only problem was that the memory and CPU usage could be too high after loading too many contents.

This issue is now completely fixed.

Better video quality faster on first loadVideo

We currently are improving our adaptive algorithm, which chose the best quality possible depending on the bandwidth.

Before all those improvements are released, we bring here a few which mainly improve the speed with which the right quality is set on the first loadVideo call.
If you want more details, we did some experiments and found out that we could profit from lowering two values:

• the minimum number of bytes to download before we perform the first bandwidth estimation
• a value dictating whether better quality content should be downloaded to replace some lower-quality content already buffered.
  Basically here, we replace more aggressively the current buffer if it means a better quality will be shown instead.

Those modifications should mostly have an effect when the quality raises and thus should not have a big impact on the frequency of rebuffering.

Better bandwidth estimation when downloading from misconfigured servers

We previously relied on the "Content-Length" header to know the size of downloaded segments, which we use to estimate the bandwidth.
We found out that some misconfigured servers sometimes send a wrong "Content-Length", often when we do byte-range requests.

To be more resilient, we decided to directly rely on the length in bytes of the response (the downloaded segments) instead.

Avoid setting the serverCertificate at each quality switching

Note: This only affects you if you set a serverCertificate when playing an encrypted content.

Due to evolutions regarding key rotation and multi-key contents, we made some changes on encrypted contents which led to a server certicate being set at each quality switch (instead of a single time).
Although that behavior causes no problem when decrypting the content, this is unnecessary and lead to pointless warning events triggered with the code "LICENSE_SERVER_CERTIFICATE_ERROR".

We fixed that by going back to the previous behavior, the certificate is now only set once at the beginning of the playback.

Changelog

Bug fixes

• abr: fix memory leak in ABR Management
• eme: avoid re-attaching a server certificate at each encrypted event

Other improvements

• buffer: lower the "paddings" applied to the video buffer when raising the quality
• abr: when pratical, avoid relying on the "Content-Length" header to protect against miscalculations when downloading from misconfigured servers
• abr: lower the minimum number of bytes we wait to download before we evaluate the bandwidth
• abr: use performance.now instead of Date.now for better precision
• module: move express from the dependencies to the devDependencies
• demo: fix standalone demo and add possibility to launch it via HTTPS