v3.3.1

Release 3.3.1 (2018-03-13)

Overview

This release only fix minor bugs. Most of which were brought with the v3.2.0 release (as it provided pretty big features such as multi-period support, perfect frame-accuracy on most browsers and end of stream detection).

It also corrects some issues developpers could have when working with the repository on Windows.

Bug Fixes

• misc: fix missing browser API on IE11:
  This bug prevented to launch the RxPlayer when the Array.prototype.find API was either not provided by the browser or not polyfilled by the client code. This happened only in specific conditions in IE11.

• buffer: end correctly streams which experienced a custom sourcebuffer (text/image) crash:
  Custom source buffers crashes (for example subtitles parsing errors) happening in a given content would lead to the impossibility to end the content (it would keep buffering at the end). This is also fixed.

Other improvements

• tools: support development on windows:
  As most of our developments are either on Linux, macOS or on Windows' WSL, we never bothered to manage specificities of the Windows platform regarding the development environment, namely the way it declares environment variables.
  This is now fixed and development on windows should now be supported.

v3.3.0

Release 3.3.0 (2018-03-05)

Overview

This release mainly brings the possibility to play contents natively decodable by the browser. This includes - depending on the browser - MP4 files, WEBM files or even HLS playlists (for Safari on macOS or any browser on IOS).

This mode is called the "directfile" mode and is documented in the loadVideo options page. Please be aware however that in that mode, multiple APIs won't have any effect. This is documented in the documentation of each concerned method, option or event.

Added

• api: add directfile API to allow the playback of files natively managed by the browser

Bug Fixes

• api: fix player state when seeking after the video ended
• text/api: fix getTextTrack API which could return the current audio track instead
• text: clean-up custom HTML text track SourceBuffer's buffered when the text track is disabled

v3.2.0

Release 3.2.0 (2018-02-23)

Overview

This release comes after more than 2 months of PoCs, brainstorms and development to provide a strong basis for playing DASH manifest with multiple periods smoothly, even if they rely on completely different bitrates or adaptations. We're still working on other improvements, so expect more on this subject in the coming months.

We also greatly improved the way the player detects the end of the stream - the previous behavior could lead to the last frames not being played. That's a problem as we're today supporting frame-accurate playback on some of our implementations.

This allowed us to add the stopAtEnd constructor option, true by default for legacy-support, which can be set to false to avoid completely un-loading the content as it ends.

At last, we also added manifestLoader to the transportOptions of a loadVideo call. This allows implementers to plug their own manifest-loading logic.

Multiple minor bug fixes have also been added.

Added

• dash: Handle multi-periods DASH manifests
• api: add periodChange event
• api: add stopAtEnd option to the constructor, to deactivate automatic content un-loading when it ends
• api: add manifestLoader to the transportOptions of a loadVideo call

Bug Fixes

• stream: call endOfStream for better end detection and to allow the Chrome browser to display the last frames of a video
• buffer: always play the last possible milliseconds of a content (removed END_OF_PLAY config attribute)
• eme: workaround a bug found on Chrome where setting a keySystems option in loadVideo would always throw on HTTP (not HTTPS) pages.
• vtt: fix WebVTT parsing when the last line of a WebVTT file is not a new line
• dash: ignore availabilityStartTime settings for a static MPD
• buffer: ignore segments for a duration inferior to the MINIMUM_SEGMENT_SIZE (200ms by default) to avoid infinite re-downloading

Other improvements

• update RxJS to v5.5.6
• update TypeScript to v2.7.2

v3.1.0

Release 3.1.0 (2018-01-30)

Overview

This release brings multiple features and fixes:

• it adds the networkConfig option to loadVideo. With it, you can have more control over CDN error management. You can find more infos on this option here.
• it adds closeSessionsOnStop to the keySystems loadVideo option. With it, you can force MediaKeySession to be closed as a content stops. More informations on the keySystems documentation.
• it fixes a bug we had with DASH MPD based on SegmentList indexing scheme
• it manages Smooth Manifest of static (VOD) content not starting at a 0 timestamp

Added

• api: add networkConfig to loadVideo options
• eme: add closeSessionsOnStop to the keySystems loadVideo option

Bug fixes

• dash: fix Range request ranges for representations based on a SegmentList index
• smooth: allows smooth Manifests for non-live contents to begin at a timestamp != 0

v3.0.7

Release 3.0.7 (2018-01-19)

Overview

This release fix a single bug, which led to the impossibility to play encrypted content on the Internet Explorer 11 browser.

This was due to a single character typo.

Bug Fixes

• eme: fix bug which prevented to play encrypted contents on IE11

v3.0.6

Release 3.0.6 (2018-01-11)

Overview

This release brings multiple bug fixes.

The most important one could lead to multiple video or audio segments being downloaded at the same time (as a player, what you actually want to do is to load the nearest segment first to avoid excessive re-bufferings).

Bug Fixes

• buffer: fix issue which could led to multiple video or audio segments being downloaded at the same time
• dash/text: support MPD AdaptationSet with a "caption" Role as text Adaptations
• dash/text: remove offset set for subtitles on live contents, which led to unsynchronized subtitles
• dash: fix issue which could lead to segments being re-downloaded too much in a SegmentTemplate scheme

Other improvements

• demo: set "html" textTrackMode by default to have a better stylization of closed captions.

v3.0.5

Release 3.0.5 (2017-12-11)

Bug Fixes

This release comes with only one bug fix:

• eme: consider unknown errors (e.g. errors coming from the user of the library) as fatal eme errors

Explanation

We introduced an unwanted change of behavior in the release v3.0.1 (as we switched to TypeScript) where we considered errors originating from user-provided callbacks as non-fatal in our EME workflow.

This led to an infinite "LOADING" state in most cases where the license could not be fetched.
This is because this error was encountered most-often in the getLicense callback, which is written by the users of our library.

This behavior has been corrected. Now we consider unknown errors as fatal errors, which causes the rx-player to emit an EME-related error and switch to a STOPPED state, like before the v3.0.1.

v3.0.4

Release 3.0.4 (2017-12-05)

Overview

This release mainly patches some minor issues we had with webvtt text tracks parsing.

Bug Fixes

text/webvtt: authorize header options without parsing them

More specifically, this fix allows the presence of header metadata at the top of a webVTT file.

Despite not being defined in the webvtt w3c spec, multiple vtt files use some kind of headers options after the first line. One example of that behavior would be the X-TIMESTAMP-MAP metadata header defined in the HLS draft.

Example:

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:1080000,LOCAL:00:00:00.000

1
00:00:46.440 --> 00:00:48.480
Some subtitles

To truely separate the header from the content of a WEBVTT file, the first "empty" line is now considered, instead of the second line.

text/webvtt: authorize timestamps without hours

The webvtt w3c spec authorizes timestamps without hours (just minutes, seconds and milliseconds). A bug on the rx-player side led those subtitles to be ignored.

Other improvements

• misc: remove multiple unneeded assertions in DEV mode
• misc: update DEV mode default debug level from DEBUG to INFO

v3.0.3

Release 3.0.3 (2017-11-24)

Overview

This release mainly patches a minor issue we had with ttml text tracks, where a "tts:x" style set directly as an attribute of a Node would not be parsed correctly (and thus not be considered).

This mostly affected TTML subtitles in HTML textTrackMode.

This release also provides a better workaround for Typescript's issue 20104. Now all build scripts are usable again 🎉.

Bug Fixes

• text/ttml: apply correctly a style if directly set on an attribute
• eme: load new video even if the last EME clean-up failed

Other improvements

• misc: set better work arround for typescript issue 20104 to make building npm scripts usable again
• tools: update the update-version npm script
• demo: npm run start and npm run standalone now build the rx-player in the "development" environment
• tools: add more logs in DEBUG mode

v3.0.2

Release 3.0.2 (2017-11-17)

Overview

As it would be too good to be true to switch to TypeScript without any hiccups, we encountered a not-yet fixed TypeScript issue which prevented the Rx-Player to be launched in some browsers (most notably, in chrome), if the corresponding page was not in https 😢

This was not discovered during our tests as they either:

• have been made on localhost, where the issue is not present
• have been made on https pages

For now, the project cannot be built manually using any of the following npm scripts:

npm run build
npm run build:min
npm run build:watch

We might provide cleaner scripts to workaround this if that's a real issue for you. Sorry for the inconvenience.

More details on the issue

The corresponding typescript issue is documented here:
microsoft/TypeScript#20104

Here's why it was only triggered in certain cases, and why it slipped through the cracks in our tests:

Our player has what we call compatibility files which, when it does not find the right "experimental" APIs, tries its best to see if it can mock them.

The problematic part is thus only triggered in browsers where a MediaKeys implementation exists, but where navigator.requestMediaKeySystemAccess does not. It was only triggered on distant http pages for Chrome because in that particular case, the browser deactivate some EME-related APIs, among which navigator.requestMediaKeySystemAccess.

We will make sure to also tests this case for future release!