v3.8.0

Release 3.8.0 (2018-10-11)

Overview

This release comes with multiple new features:

• you can now provide a callback to loadVideo to prevent some Representations (i.e. media qualities) from being played (can be useful when you know a device won't be able to play such media quality).

• the new manualBitrateSwitchingMode loadVideo option allows for more direct quality switches

• we now provide directly a warning when the current position is out of the bounds of what is available in the manifest

representationFilter API

DASH and Smooth contents are often constituted of multiple video and audio qualities. This allows for example adaptive streaming, where a lower video quality could lead to less buffering and thus a better user experience.

In some advanced use-cases you might want to prevent some of those qualities from being played. One of those use-cases is when you know in advance that a particular quality won't be decodable by the current device.

To answer that need, we added representationFilter, a new user-provided callback to the transportOptions you can provide to loadVideo.

For more informations on it, you can find the transportOptions documentation here and more specifically the representationFilter documentation here.

Manual bitrate switching modes

Previously, when you updated the current video or audio quality manually through respectively the setVideoBitrate and setAudioBitrate APIs, you wouldn't see the quality switch right away: You would actually see the previous quality being played for some amount of time and then progressively the new quality taking its place.

This was because those APIs didn't "flush" the previous buffers: the previous quality stays here and is replaced progressively as you continue to play.

That seamless switch allows a smooth transition, but depending on your player implementation you might want to provide the quality switch directly if a user ask for it (e.g. like YouTube does when you set a particular video resolution from their player interface).
To let you choose what behavior you want, we added a new loadVideo option called manualBitrateSwitchingMode. By default, it stays at the old "seamless" behavior, but you can switch to "direct" to profit from a more direct switch.

Documentation on manualBitrateSwitchingMode is available here.

Warnings when the current position is out of the bounds of the manifest

We added two warnings:

• when the position is before the first time declared in the manifest

• when the position is after the last time currently declared in the manifest

Those two warnings have respectively the MEDIA_TIME_BEFORE_MANIFEST and MEDIA_TIME_AFTER_MANIFEST.

They are mostly useful when you play live contents.

For example, live contents often don't have an unlimited buffer depth, meaning that you won't be able to seek in the past indefinitely.
As such, if your position is too far behind, you can be in a situation where the player will buffer indefinitely. This is how you might want to workaround this problem:

player.addEventListener("warning", (warning) => {
  if (warning.code === "MEDIA_TIME_BEFORE_MANIFEST") {
    // seek and play 5 seconds after the current minimum position
    const minimumPosition = player.getMinimumPosition();
    player.seekTo(minimumPosition + 5);
    player.play();
  }
});

Those warnings were added to the errors and warnings documentation.

Automatic garbage collection of subtitles and thumbnails

Subtitles and thumbnails buffers are entirely managed by the RxPlayer, without the help of the browser (as opposed to audio and video buffers).

As we have much less informations on the memory available than the browser does, we won't be able to clear them a little when the user's computer is low on memory.

Because of this, we now regularly clean those two buffers 5 hours behind and ahead of the current position.
This is a minor move to avoid memory problems when the user is playing a content for very extended amount of time.

These 5 hours values can be seen and updated in the config (it is now called MAXIMUM_MAX_BUFFER_AHEAD and MAXIMUM_MAX_BUFFER_BEHIND in there).

Changelog

Features

• api/dash/smooth: add representationFilter API to prevent Representations (i.e. media qualities) from being played
• api/buffer: add manualBitrateSwitchingMode option to allow a direct representation switch when calling setVideoBitrate and setAudioBitrate
• api/buffer: emit a MEDIA_TIME_BEFORE_MANIFEST warning when the wanted time is before what is announced in the manifest
• api/buffer: emit a MEDIA_TIME_AFTER_MANIFEST warning when the wanted time is after what is announced in the manifest

Bug fixes

• remove export of undeclared ICompatVTTCue from modular build

Other improvements

• buffer: to avoid taking too much memory, regularly clean-up text and image buffer 5 hours ahead/behind the current position (customizable)
• demo: add HTTPS capabilities on local full demo
• rxjs: update rxjs to 6.3.3
• typescript: update typescript to 3.1.2

v3.7.0

Release 3.7.0 (2018-09-21)

Overview

This release mainly brings improvements for DRM (EME) matters:

• it improves license expiration management
• it adds the possibility to skip license updates
• it replaces the experimental tool mediaCapabilitiesProber.isDRMSupported by the more useful mediaCapabilitiesProber.getCompatibleDRMConfigurations

It also brings multiple minor bug fixes:

• DASH: We now consider multiple Role nodes for an AdaptationSet
• Smooth: we fixed some minor URL parsing bugs (note: some legacy behavior has been deprecated see the Deprecated Smooth Behavior chapter for more information)
• TypeScript: we fixed some problems of missing interfaces people where having when type-checking our library
• API: we fixed some minor state bugs

Last but not least, we have now a new demo page that manage encrypted contents.
We also added a LOT of integration tests.

DRM: expiration management

In previous versions, managing license expiration was really hard for the following reason: we stopped with an error as soon as a currently-used license expired.
License renewal was still possible, but it had to be done before it was expired.

For our current use-cases, expiration management becomes much more important. This is why we chosed to improve this situation for this release.

This issue was REALLY easy to fix, the problem was that just doing so would break our current API. Now, applications which do not manage license expiration might be blocked infinitely in a rebuffering situation where previously, they would have just stopped and displayed an error screen (which, arguably, might be preferable).

Due to that situation, we chosed to introduce a new possible property in keySystems (the loadVideo option): a boolean called throwOnlicenseExpiration.
It is set to true by default to ensure compatibility with our previous API but you can set it to false explicitely to continue playback even when a license is expired (you can still be notified about expiration through a warning with a "KEY_STATUS_CHANGE_ERROR" code or the optional onKeyStatusesChange callback - also from keySystems).
Then, the usual getLicense callback (keySystems) should be enough to perform renewal requests.

The throwOnLicenseExpiration property is documented here.

DRM: avoiding license updates

License updates are done through the rx-player via two user-provided callbacks:

• getLicense: triggered every time the content decryption module (or CDM) of the browser send us a message, usually to request a license
• onKeyStatusesChange: optional callback triggered every time the status of a current decrypting key changes

Both can return a license or a promise resolving with a license, which will then be passed to the underlying CDM.

The problem with that approach is that you might not want to update the license each time a message is sent by the CDM or each time the status of a key updates.

To allow users to "skip" license updates, we added the possiblity to return null or a promise resolving with null to both of these callbacks.

We updated accordingly the documentation on the keySystems option.

getCompatibleDRMConfigurations experimental tool

In the v3.5.0, we added the mediaCapabilitiesProber experimental tool which included a isDRMSupported function, to test which key systems were supported in the current browser.

After feedbacks from users, we found out that this API was not very useful.
As a result, we replaced it by a more complete getCompatibleDRMConfigurations function and we are now waiting for your feedbacks on it.

The status of this API is still possible to evolve, as we're still trying to find out your needs on encryption-related tooling.

You can find documentation on the mediaCapabilities in the corresponding documentation page.

Deprecated Smooth Behavior

Previously, we authorized ".isml", ".ism" and ".wsx" URL when loading a Smooth streaming content due to some legacy use-cases.

We deprecated that behaviour to incite people to set the Manifest URL directly.

Changelog

Features

• eme: add throwOnLicenseExpiration boolean to keySystems (loadVideo option) to allow better expiration management
• eme: in the getLicense property of keySystems (loadVideo option), it is now possible to resolve with null to avoid a license update.
• eme: in the onKeyStatusesChange property of keySystems (loadVideo option), it is now possible to resolve with null to avoid a license update.
• tools: replace experimental tool mediaCapabilitiesProber.isDRMSupported by the more useful mediaCapabilitiesProber.getCompatibleDRMConfigurations

Deprecated

• smooth: giving a WSX URL instead of the Manifest URL for a smooth content is now deprecated.
• smooth: giving a publishing point definition URL (.isml) instead of the Manifest URL for a smooth content is now deprecated.
• smooth: giving a Smooth Streaming server manifest URL (.ism) instead of the Manifest URL for a smooth content is now deprecated.

Bug fixes

• api: switch state to "ENDED" if seeking to the end while the player is in the "LOADED" state.
• api: switch state to "SEEKING" if seeking in the content while the player is in the "LOADED" state.
• dash: consider multiple Role nodes for an AdaptationSet.
• typescript: fix typings error when an application build us without the skipLibCheck TypeScript option enabled.
• smooth: fix Manifest URL generation when a ".ism" or a ".isml" URL is given.
• doc: document deprecation of the adaptations property returned from a Manifest object (as returned from the getManifest method).

Other improvements

• doc: add quick start tutorial.
• doc: add player states documentation.
• demo: add possibility to play encrypted contents.
• demo: update demo page.
• tests: consolidate our integration tests.

v3.6.1

Release 3.6.1 (2018-09-03)

Overview

The v3.6.1 is a minor release fixing several bugs:

• Directfile: in directfile mode, the player state never switched to LOADED (this was also visible in our demo page, where the "loading" spinner never disappeared even when the video played).
  As this bug is not a little one and should normally be easy to catch, we began to add some integration tests related to the directfile mode.
  Thanks to @fnatte for finding and fixing this issue!

• EME: the keySystems option closeSessionsOnStop did not work properly.
  This was due to the fact that when stopping a content, every MediaKeySessions were first removed from the cache and THEN we called another function which only closed the ones that were still in the cache. In all evidence, no MediaKeySession were thus closed each time.
  We now removed that double-check (and renamed the concerned function), as it made not much sense.

• TypeScript: our typescript typings, exported through rx-player/types, were not compatible with typescript 3.0 "project references" because it was a .ts file not indicated in our typescript root directory. It is now a .js and a d.ts file which seems to work for any situation.

• DASH: In DASH, AdaptationSets containing a Role node set as "main" were merged with the other ones in the same situation as long as they were in the same type. After closer inpection of the DASH-IF guidelines, it seems that this should only be done for video AdaptationSets (where we previously applied it to text and audio adaptations as well).

Changelog

Bug fixes

• directfile: send LOADED event again for directfile contents - thanks @fnatte
• dash: don't merge "main" AdaptationSet if they are not of a video type
• eme: fix bug which prevented the closeSessionsOnStop keySystem option to work properly
• typescript: export types compatible with project references

Other improvements

• directfile/tests: add basic directfile integration tests
• build: update to Babel 7
• rxjs: update to RxJS 6.3.1

v3.6.0

Release 3.6.0 (2018-08-24)

Overview

The v3.6.0 in a few words:

• we now manage video track switching (through the same kind of APIs than for audio and text track switching)
• we handle WEBM containers for audio and video in DASH streaming
• we added some TypeScript types to our API.
• we now emit a warning event if autoPlay is blocked by the browser
• we fixed some issues with TTML parsing
• we deprecated (very) minor APIs
• we improved the architecture documentation (and improved the code organization in the same occasion).

Video track switching

It is now possible to switch between multiple video tracks like it is already possible with audio and text tracks.

For this, we created three new methods:

• getAvailableVideoTracks method to retrieve every video tracks in the current Period
• getVideoTrack method to get the active video track
• setVideoTrack method to switch the video track

And one new event:

• videoTrackChange event to know when a video track has been switched

But there's a catch. To do that, we had to add a little trick:

In certain conditions (basically when the browser is already decoding another video track), we have to completely reload the content to be able to replace the video track. Because the interaction with the video element is more limited when it reloads (you cannot seek, play/pause, or get and set video, audio or text tracks) we decided to add a new state to our API: "RELOADING". During this new state, it is recommended to prevent the user to interact with the current content (exactly like when in the "LOADING" state). The content goes directly from "RELOADING" to "PLAY" or "PAUSE" when reloaded (depending if the content was playing just before).

As this state only appears with new APIs, this is not considered a breaking change, but this is a new state you will have to handle if you update the video track.

TypeScript types

We now export some TypeScript types from rx-player/types. This is mostly complex objects accepted by our API, to simplify the writing of a TypeScript application which use the RxPlayer.

You can have all infos about the type exported in the related documentation.

WEBM contents parsing

The RxPlayer sometimes need to parse container files (like ".mp4" or ".webm" files) to be able to obtain some informations about the available segments.
Previously, the player could not load some DASH contents which provided WEBM files. This is because we didn't handle at all this format.

We now should handle those files perfectly.

Warning event when autoplay is blocked

Some browsers (most notably Chrome or Safari) have an autoplay policy where they try to block video from playing automatically.
We previously just silently stayed in a "LOADED" state when that happened.

Now, we still stay at a "LOADED" state but we also send a "warning" event containing a "MEDIA_ERROR" with the code: "MEDIA_ERR_BLOCKED_AUTOPLAY".

This warning is documented here

Deprecated APIs

We deprecated multiple APIs. Mostly because they were considered more confusing than useful.
Those APIs are:

• the method isFullscreen
• the method setFullscreen
• the method exitFullscreen
• the method getNativeTextTrack
• the event fullscreenChange
• the event nativeTextTrackChange

Those should still work as long as we stay in a release numbered as v3.x.x.
To obtain more informations on why we deprecated those APIs and how to replace them, you can go to the related documentation.

Other little improvements

We added several other little fixes.

Most notably in ttml text track parsing where we fixed two issues:

• we now display forbidden characters (such as ">") that were previously simply ignored in a "native" textTrackMode (they were displayed as expected in an "html" mode).
• we now process xml:space even if it is not defined at the top level (as we should!).

We also updated our code architecture documentation a little. Don't hesitate to take a look if you have interests on the innards of the RxPlayer!

Changelog

features

• api: add video track switching
• dash: add webm support
• api: Emit warning if autoPlay is blocked on the current browser
• api: add getAvailableVideoTracks method to retrieve every video tracks
• api: add getVideoTrack method to get the active video track
• api: add setVideoTrack method to switch the video track
• api: add videoTrackChange event to know when a video track has been switched
• api: add RELOADING event for cases where the player needs to reload (such as during a video track switch)

Deprecated

• api: the method isFullscreen has been deprecated
• api: the method setFullscreen has been deprecated
• api: the method exitFullscreen has been deprecated
• api: the method getNativeTextTrack has been deprecated
• api: the event fullscreenChange has been deprecated
• api: the event nativeTextTrackChange has been deprecated

bug fixes

• ttml: display forbidden characters (such as ">") in a "native" textTrackMode
• ttml: process xml:space even if it is not defined at the top level
• buffer: perform a better clean-up of previous media in a SourceBuffer when switching audio or text track

Other improvements

• types: export and document main typings used internally such as ILoadVideoOptions (the loadVideo argument)
• misc: log every fatal errors
• misc: remove dumb npm inclusion as a project dependency
• doc: improve architecture documentation

v3.5.2

Release 3.5.2 (2018-08-06)

Overview

This new release improves several different core features:

• we added TypeScript typings, at last!

• presentationTimeOffset in DASH is now correctly and completely managed. This is most useful when playing multi-period contents.

• we better manage bitrate-selection when the available bandwidth suddenly fall

• multiple bug fixes have been added

TypeScript typings

Now, as long as you rely on the npm registry, you should automatically have typings with the rx-player 🎉.

This was an asked feature for a long time. The project is in TypeScript, so typings should be easy to generate, right?

However, due to the way our project was built, we didn't succeed to correctly add them before. We didn't want to update our build scripts either, as it would in most case bring breaking changes and regressions.

Fortunately, the v3.5.0 release brought minimal builds with feature switching, which rely on another build of the player. This allows us to generate the typings for this build, which we then can re-use even for the old, legacy, builds.

As it's the first time we expose the types of our API, it's possible that you encounter issue with too-restrictive types. We will consider those cases like regular bugs. You're more than welcome to open issues when you see them.

presentationTimeOffset

We realized in the v3.5.0 release that the way we managed the presentationTimeOffset of DASH MPD was off: it provoked more problems than it resolved. That was why we decided to ""fix"" this issue by deactivating temporarily any code related to it.

After some documentation-reading and some code-reading+reverse-engineering of other players (I plead guilty, but we all do that, really!), we were finally ready to correctly implement this feature.

To quickly explain the role of this attribute, it is often associated with multi-period MPDs (we can have it for MPDs with a single Period for specific usecases, but that's pretty rare). What it does is telling the player it should add an offset to the media file when playing it.

If you want to know more about it, we added some documentation on it.

Artificial bitrate limitation in smooth steaming

Some legacy code we overlooked in the Smooth Streaming implementation was limiting as a default the minimum possible bitrate to 190kbps. This was wanted a long time ago for some reasons that we do not know (and the culprit is not here anymore!).

We realized that this limit was not only not needed, but was even problematic for most people we work with. We thus decided to completely remove it.

tl;dr: You can now play any bitrate you want with Smooth streaming.

Adaptive-bitrate mechanisms

We encountered several challenges with adaptive streaming these last months. The world cup was one of the main reason why (on this subject - quick spoiler: we won 🇫🇷 ).

Due to that issue, we concentrated our efforts on bitrate selection. More precisely, on the way we handle cases where the bandwith suddenly falls. Our new logic is more agressive than the previous one on that subject, and should detect and limit buffering a lot more than before.

And other...

Two minor bug fixes have also been added:

• we previously didn't play live DASH streams without video. We now can.
• in DASH again, the way we parsed "main" Adaptations was imperfect, and we could filter out some of them. This is now fixed

We also switched to Typescript v3.0.1.

Changelog

Bug fixes

• dash: Manage presentationTimeOffset completely (allow advanced multi-period configurations)
• dash: Fix Adaptations bug when the first DASH adaptation was a "main" one
• smooth: Remove the limitation of a minimum bitrate in Smooth Streaming
• dash: Fix condition which prevented to play audio-only live DASH streams

Other improvements

• typescript: add typescript declaration files
• abr: update ABR mechanisms when the estimated bandtwidth fall suddenly
• api: warn in the log when the browser reject a wanted autoplay
• drm: Add keyId information to the internal Manifest structure
• typescript: update typescript to v3.0.1

v3.5.1

Release 3.5.1 (2018-07-12)

Overview

This release fix bugs, including one which was brought by version v3.5.0.

Bug Fixes

• parsers: fix segment time computing on template index:
  Segment time, for template segments only, was miscalculated, resulting in :

  • Wrong segment media URL (404 HTTP error for requested segments)
  • Segment bookkeeper being misled on segment times, against buffer informations

• abr: get concerned request in starvation mode:
  In starvation mode, current pending request was never retrieved. Without knowing if request takes too much time, ABR couldn't evaluate an "emergency" situation, resulting in bitrate decreasing too slowly.

v3.5.0

Release 3.5.0 (2018-07-03)

Overview

This new release brings several new tools for you.

Minimal Build with feature switching

You can now easily import only the features you want to reduce the file size.

For example, you can only import DASH streaming without SMOOTH or EME, if you don't need to play either HSS or encrypted contents.

This is done by importing a minimal version and then adding only the features you want, from a defined set of features. All of this is documented here.

A new tool: the MediaCapabilitiesProber

We added a new mediaCapabilitiesProber tool, which allows you to know which DRM, codecs, HDCP version or colorspace is managed currently in your browser.

This tool is still anotated as "experimental", which just means that its API can change on any new version based on your feedbacks (don't be afraid, those changes will be documented in the release note). We will "stabilize" it only once everybody seems happy with our API!

This is documented here.

switched to RxJS 6: no interference with your RxJS library

We also switched to RxJS 6. This ensure that our RxJS version does not interfer with a possible RxJS version you implemented on your application.

DASH: better "main" adaptation management

We now always play the "main" adaptation first and merge them when there is multiple one of them, based on the DASH-IF 4.1 guidelines.

This is most of all used for what we call "Multiple Key Single Content" (multiple licenses on the same content) that we fully support.

Better, smaller default builds

Our default builds (in the dist folder, or imported via import RxPlayer from "rx-player") are now much smaller and more lisible for a better debugging experience.

For even decreasing the size though, you're advised to use the minimal build with feature switching instead (as advertised above).

Many other little improvements

For notable new features and bug fixes we also have in this release:

• a new static property for the RxPlayer, version (it's coming late, we know!)
• a WebVTT fix for the "native" textTrackMode
• a fix concerning DASH' presentationTimeOffset property, which could lead to wrong segments being requested
• an improved demo page (better fullscreen mode and time indication on the progress bar)

Changelog

Added

• tools: add mediaCapabilitiesProber tool as an experimental tool
• builds: add minimal import with feature selection (allowing cleaner feature switching or lazy-loading)
• dash: allow multiple "main" adaptation
• api: add static version property to the RxPlayer API

Bug fixes

• vtt: fix line setting for vtt tracks in "native" textTrackMode
• dash: always play "main" adaptation first
• misc: don't interfere with a client's RxJS implementation by switching to RxJS 6
• dash: presentationTimeOffset doesn't have an influence on requested segment anymore
• smooth/dash: throw a "MANIFEST_PARSE_ERROR" if no audio and video adaptations/StreamIndex are available in the current content

Other improvements

• builds: Reduce size of the builds
• builds: use uglifyJS instead of Closure-compiler
• builds: update to typescript 2.9
• rxjs: update to RxJS version 6 (v6.2.1)
• code: set complete URL in segment's media property
• demo: add time indicator on the progress bar
• demo: update fullscreen mode to also display the text track element
• misc: moved demo server scripts to the respective demo directories
• misc: moved manifest parsers to the src/parsers directory
• misc: moved scripts from ./tools to ./scripts
• misc: moved webpack configs to the root of the project

v3.4.1

Release 3.4.1 (2018-05-31)

Overview

This release brings multiple bug fixes.

End of Stream errors

Particularly on Chrome, a fatal error could be thrown on certain conditions as the buffer reached the end. This was observed:

• When seeking multiple times just before the end of the content
• When the content finished to download as the tab was hidden (only in Chrome)

Those Bugs have been fixed.

Manifest/MPD redirection management

Contents for which the Manifest/MPD request was redirected (through HTTP 3xx codes) still used the original (non-redirected) URL as a base to request segments.

This is now fixed.

Please bear in mind however that this fix uses an API (namely XMLHttpRequest.prototype.responseURL) that do not exist on older browser (and particularly IE11).
On those browsers, the previous behavior will still be active.

WebVTT / SRT subtitles parsing

The WebVTT and SRT parsers are much more resilient.
For example, they won't throw anymore when an unknown block is encountered (such block will simply be ignored).

They also better manage styling spans (e.g. <b>, <i> or <u> xml tags). Those can now encompass multiple lines.

Other minor bug fixes

We also brought several other fixes:

• While updating our build system (webpack), we forgot to update some settings when building for production.

  As a result, final builds still had their log level set to "INFO" instead of "NONE" by default.
  Also, some development-only code was still present (which are mostly runtime-checks which should pass anyway).

  Now every settings is back as it was before.

• getAvailableTextTracks and getAvailableAudioTracks returned null by default despite the API documentation saying that it always returns an array. Now it returns an array by default as the documentation says.

• Some of our development dependencies were in the dependencies property of our package.json file. They were mostly new dependencies to generate or documentation. Those have been moved back to devDependencies where they belong.

Changelog

Bug fixes

• buffer: fix several bugs happening when calling endOfStream to announce the end of the current content. Especially prevalent on Chrome.
• net: use redirected URL as a base for further requests when the manifest request led to a HTTP redirect.
• vtt/srt: ignore silently (do not throw) when an unknown block has been detected in a vtt or srt file
• vtt/srt: support styling spans (like b, i and u XML tags) spanning multiple lines
• api: getAvailableTextTracks and getAvailableAudioTracks now always return an array (and never null) as anounced in the API documentation
• api: set default log level to "NONE" instead of "INFO"
• misc: remove development-only code from the non-minified code

Other improvements

• misc: move some dev dependencies from dependencies to devDependencies in package.json

Minor note

The CHANGELOG.md file states that this release was done on the 29, and not on the 31 as it should be.

This is a forgotten edit which happened because this release went through multiple testing phases. This date will be updated on the next release. Sorry for the confusion.

v3.4.0

Release 3.4.0 (2018-05-17)

Overview

This release adds multiple encryption-related features:

• The possibility to play contents which rely on several licenses
• The possibility to create multiple player instances all playing encrypted contents (before, only 1 player with encrypted content was authorized)

It also brings minor fixes:

• To avoid wasting ressources infinitely, we limit the max number of encryption session (called MediaKeySession) to 50 by default (EME_MAX_SIMULTANEOUS_MEDIA_KEY_SESSIONS in ./src/config.ts). After that limit is reached, the oldest session will be automatically closed when new sessions are created.

• Text buffers were not properly cleaned when subtitles are deactivated. This is now the case.

• We do not perform automatic seek when a discontinuity is spotted on text or image buffers anymore. We only do that for audio and video buffers.

Last but not least, our documentation files are now automatically translated into an easier-to-navigate HTML documentation. You can find it here.
Note that the previous documentation will still always be available in this repo.

Added

• eme: allow multiple licenses per content
• eme: allow different MediaKeys to be attached on multiple media elements

Bug fixes

• eme: limit simultaneous loaded MediaKeySession to 50 by default (configurable)
• source-buffer: clean properly the text SourceBuffer on deactivation
• buffer: perform discontinuity seeks only for native source buffers

Other improvements

• doc: generate documentation pages
• misc: add sonarqube quality pass
• code: set a clearer private state for the API
• tools: update to webpack v4.8.3
• tools: update to typescript v2.8.3

v3.3.2

Release 3.3.2 (2018-04-17)

Overview

This release mainly stabilizes the RxPlayer by bringing several minor bug fixes.
It can be seen as a stable milestone before new coming features.

This release also brings a non-negligeable improvement to the way we schedule segment downloads, to lower eventual seeking, loading and re-buffering time. If you're interested by technical details about this improvement, you can read the corresponding PR.

Bug Fixes

• api: emit SEEKING state instead of BUFFERING when the user seeks to an unbuffered part just after resuming playback
• api: work around bug found in old versions of Chrome where the ENDED state would never be triggered at the end of the stream
• api/language: fix bug where an audio or text language would not be switched to on certain conditions in live contents
• smooth: fix frequent manifest refreshing happening immediately when changing audio/text language
• eme/error: fix reason string and error message for KEY_STATUS_CHANGE_ERROR

Other improvements

• buffer: update download queue immediately when seeking to an already-buffered part, to always prioritize needed segments
• buffer: schedule segments per level of priority to lower some buffering/seeking/loading time
• demo: fix "Big Buck Bunny WEBM"'s URL