v3.12.0

Release v3.12.0 (2019-04-10)

Overview

This new release brings multiple features:

• dash: add support of some UTCTiming elements, to ensure the clients' clocks are all synchronized to the real live time
• smooth: add aggressiveMode to the loadVideo transportOptions to request live segments closer to the live edge
• dash/smooth: update manifestLoader API to allow more complex use cases (URL redirection, more precize manifest polling...) when using an external Manifest loader.
• dash/smooth: define a referenceDateTime transportOption to set a custom reference starting time for live contents

UTCTiming support

The RxPlayer now supports some UTCTiming elements, which allows to fetch an accurate timing for DASH contents.

This is especially useful when a dynamic MPD rely just on a static SegmentTemplate to announce its segments. In that case, an unsynchronized client could fetch segments too much in the future or in the past, or just not be aligned with other clients, depending on its local clock settings.

For the moment, only UTCTiming elements with the following schemeIdUri are supported:

• urn:mpeg:dash:utc:http-iso:2014: which triggers an http request to the linked server to fetch the clock.
  The request will only be done if the player absolutely needs it. That is, if both:

  • there's no other, more direct, way to get that timing
  • the MPD absolutely needs to have a synchronized clock (example: live contents without a single SegmentTimeline element).

  As such, we only perform a request if that's absolutely needed.

• urn:mpeg:dash:utc:direct:2014: which contains directly the time informations

Other schemes are not supported, like urn:mpeg:dash:utc:http-head:2014 or those based on ntp, for simplicity reasons. As the former is still easily doable, do not hesitate to open an issue if its support is important to you.

Smooth aggressive mode

We now added an aggressiveMode property to the loadVideo transportOptions.

This allows to put back an optimization we had on previous RxPlayer versions for live contents, where we would infer which future segments will be available to finally request them before being even sure they had time to be generated.
That way, you will be able to have segments much more closer to the "live edge" of the content you watch.

The problem to that approach, which is also the reason why we choose to disable that optimization by default, is that you risk to have much more segment requests in error.
That is because requests for segments which did not had time to generate usually returns an HTTP 412 error which will trigger a NetworkError.

Depending on your other settings (especially the networkConfig loadVideo options), those errors might just be sent as warnings and the corresponding requests be retried. Another concept to keep in mind, is that that new behavior risks to pollute your cache depending on your caching strategy, as the first request from a client has a much higher chance to get an error response.

This option is documented here in the loadVideo options documentation.

referenceDateTime

The referenceDateTime was previously an undocumented smooth feature, exposed through the loadVideo transportOptions.

It allows to set a starting reference date, as a unix timestamp in seconds, for live contents.

For example let's imagine that a new live channel announce a time relative to its starting time, the 2019-04-10 at 00:00am (Video or audio segments will start with the time set at 0 at that time).
If we play segments for the 2019-04-10 at 00:01am (so one minute after the reference date), the RxPlayer will see a position announcing just 60s.

To be able to translate that back to the real live time (which it can use in various API, such as the getWallClockTime method), we will need an offset of some sort to add to that 60 time. That's the role of the referenceDateTime.
In our previous example, the referenceDateTime will be equal to new Date(2019-04-10) / 1000.

This new option is available for DASH and smooth contents. It is only used if we are in a live content, and the Manifest provide no way to infer that reference date (example: availabilityStartTime for DASH contents).

This option is documented here in the loadVideo options documentation.

Improved manifestLoader plugin

The manifestLoader is a property allowing users to provide their own logic for Manifest/MPD request. This has for example been used for Peer-to-Peer integration.

Our previous specification of that property was fairly simple.
However, we since added multiple new features to the RxPlayer and supplementary information related to the manifest request may be now used, such as:

• Managing HTTP redirection, as the manifest request has possibly been redirected.
• Advanced manifest/segment requests strategies, who exploit manifest sending and receiving time.

That's the reason why we now handle three new optional properties (url, sendingTime and receivingTime) from the manifestLoader response.

This is documented here in the plugins documentation.

Deploy demos and docs from our previous versions

To improve documentation and testing for legacy versions, we now store the demo and documentation page from our previous versions.

To refer to them, we created two new pages:

• Demo page by version
• Documentation pages by version

Both of those links have also been added to the README.md.

Logo

At last, we finally have a logo!

We had many logo propositions and as such it was very hard to choose. We thus first decided to postpone that choice, for an indefinite time!

After some months, we finally have done an internal vote and that is the logo that was chosen!
Many thanks to people sending us logos and to people voting on the one you prefer.

It has been added to the demo page and to the README.md.

Changelog

Features

• dash: add UTCTiming support
• smooth: add aggressiveMode transportOption to requests segments in advance
• dash/smooth: add referenceDateTime transportOption to set a default reference time for live contents

Bug fixes

• buffer: work around firefox bug leading to infinite rebuffering when seeking many times in a content

Other improvements

• dash/smooth: add optional url, sendingTime and receivingTime properties in the response given by manifestLoader transportOption
• misc: deploy documentation pages and demos from our previous versions
• misc: add new RxPlayer logo to README.md and the demo

v3.11.1

Release v3.11.1 (2019-03-11)

Overview

The publish process of the previous release (v3.11.0) had an error which led to our npm package missing some files.
This was problematic when importing some features individually through the minimal version of the player.

This release just re-publish the rx-player and update the player version, without adding any other modifications.

To avoid this kind of error to happen again, all tagged/announced (on github) release of the rx-player from now will have their corresponding published npm package tested first.

Changelog

Bug fixes

• npm: publish package again. An error in the previous release led to some files missing on npm

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