Releases: canalplus/rx-player
v2.3.2
Release 2.3.2 (2017-07-25)
Overview
This release updates the EME workflow to support more devices, mainly chromebooks.
Bug Fixes
- eme: update EME workflow to improve support (especially chromebooks)
New EME workflow
Previously the player strictly followed the W3C proposed recommendation and as such, we waited for the setMediaKeys
promise (API on the video element) to be resolved before any MediaKeySession API was called. This led to a deadlock on chromebook devices (only when the video and audio robustnesses were set to HW_SECURE_ALL
) and thus the content never started.
Now, we do not wait for the setMediaKeys
promise to be resolved to call generateRequest
and whatnot. This was tested on all major browsers with no problem.
v2.3.1
Release 2.3.1 (2017-07-10)
Overview
This release only improves the "bookeeping" logic of downloaded segments. The previous logic could lead to re-downloading multiple times the same segments.
This unwanted behavior only showed itself on the release 2.3.0
, despite being there for a long time, because an old bug (which led to the player being stalled forever) prevented it. It was after fixing that bug and running tests that this behavior was witnessed.
Bug Fixes
- buffer: improve buffer ranges "bookeeping" logic to avoid re-downloading the same segments
v2.3.0
Release 2.3.0 (2017-07-07)
Overview
This release:
-
brings multiple memory management-related methods, initially for a better targetting of STB and other memory-restricted devices.
-
adds support for server certificates. Now required with widevine under Chrome.
-
adds an undocumented API (for now?) to precize custom EME robustnesses wanted for audio/video. We're still under reflexion of wether such API should be available and how it should be.
-
improve compatibility with older browser (still supporting MSE)
Added
- eme: add serverCertificate to loadVideo's keySystems argument
- buffer: add {set,get}MaxBufferAhead methods
- buffer: add {set,get}MaxBufferBehind methods
- buffer: add {set,get}WantedBufferAhead methods replacing the deprecated buffer size methods
- eme: add audioRobustnesses to loadVideo's keySystems argument (/!\ undocumented API - can break without official notice)
- eme: add videoRobustnesses to loadVideo's keySystems argument (/!\ undocumented API - can break without official notice)
Deprecated
- setVideoBufferSize has been deprecated in favor of setWantedBufferAhead
- getVideoBufferSize has been deprecated in favor of getWantedBufferAhead
- setAudioBufferSize has been deprecated in favor of setWantedBufferAhead
- getAudioBufferSize has been deprecated in favor of getWantedBufferAhead
Bug Fixes
- buffer: avoid some infinite re-buffering by re-calculating buffer ranges at every tick
- eme: add eme support for some legacy browser without video or audio capabilities
- general: add support for older browsers (which does not support array.prototype.{find,findIndex,includes})
- general: use Object.assign ponyfill instead of the previous polyfill to avoid malicious interferences with other codebases
v2.2.1
Release 2.2.1 (2017-06-27)
Overview
This release fixes the adaptive behavior of the player when the limitVideoWidth
option is not set / is set to true
:
- The maximum adaptive bitrate chosen didn't depend on the width of the video representation (whole point of the option!)
- The
setMaxVideoBitrate
method did not work as expected if any video representation had a "bigger" width than the video element in the page.
Bug fixes
- adaptive: fix width limitation bug. Impacted limitVideoWidth + setMaxVideoBitrate APIs
v2.2.0
Release 2.2.0 (2017-06-19)
Overview
This release:
-
updates the rxjs dependency to avoid a critical memory leak
-
adds a
maximumBufferPosition
property topositionUpdate
event, to keep track of the difference between the current position and the maximum "playable" one. Useful to know if the user can currently be considered close to the "live edge" or not in a UI. This was previously the role ofliveGap
incurrentTimeChange
events, which is used inpositionUpdate
events to describe the difference with the "real" live edge. More infos in the documentation. -
Go back to the previous meaning of
liveGap
incurrentTimeChange
events to keep API compatibility. Keep in mind however thatcurrentTimeChange
events are deprecated.
Added
- position: add maximumBufferPosition to the positionUpdate event's payload to replace the previous "liveGap" from currentTimeChange event
Bug fixes
- upgrade to rxjs 5.4.1 to escape from a memory leak
- position: "liveGap" from currentTimeChange event now means the difference to the maximum "bufferisable" position to keep compatibility with the old API
v2.1.3
Release 2.1.3 (2017-06-15)
Overview
This release fixes a bug with the timeFragment api (loadVideo
option), where timeFragment.start
was not considered.
Bug fixes
- api: fix timeFragment.start handling
v2.1.2
Release 2.1.2 (2017-06-14)
Overview
This release brings multiple bug fixes. The most notable bug it fixes led to the impossibility to play DRM-protected contents, following a (poorly-managed) RxJS version update.
To sum up this version:
-
DRM-protected contents are now perfectly playable
-
the "new"
seekTo
API (used with an object instead of a number) had some typos which led to weird behaviors. This has been fixed. -
the lowest video bitrate is now considered when the width of the video element is not sufficient
-
Some internal error management has been fixed
Bug fixes
- stream: the BUFFER_APPEND_ERROR error, happening when a
SourceBuffer.appendBuffer
failed for an unknown reason, is now a fatal error for audio/video segments - eme: fix rxjs timeout management which prevented from playing DRM-protected contents
- api: add securities to avoid useless errors to be thrown when the player already encounters an error
- position: fix a bug which prevented to seek at the beginning of the content with the new api
- position: fix typo which prevented to perform absolute seeks with the new api
- buffer: automatically seek if there is a discontinuity in a live stream
- adaptive: take the lowest bitrate (instead of the initial/default one) when the player is not displayed/too small
v2.1.1
Release 2.1.1 (2017-06-02)
Overview
This release mainly fixes bugs. Particularly one (missing rxjs imports), which lead to an error when RxJS was not imported into the code using the player.
To sum up this version:
-
It's now possible to perform a commonJS-style
require
on the build. Previously, it was needed to do something along the lines ofrequire("rx-player").default
. -
missing rxjs imports were added
-
a bug, preventing to play a content if the video element's width was 0 / was too small, has been fixed
-
manifest objects as returned by the API and the manifest used internally in our code is now the same, guaranteeing more fidelity from the API
-
integration tests have been added
Bug fixes
- hotfix: fixed rxjs imports
- hotfix: the player can now be imported through a commonjs require
- hotfix: the player could not play if the video element's width was too short
- manifest: segment id were not always the same on a segmentLoader and on the API calls.
- adaptive: setVideoBitrate now throw a more meaningful error if no content is playing
- adaptive: setAudioBitrate now throw a more meaningful error if no content is playing
- language: setSubtitle now throw a more meaningful error if no content is playing
- language: setLanguage now throw a more meaningful error if no content is playing
- language: isLanguageAvailable do not throw and return false if no content is playing
- language: isSubtitleAvailable do not throw and return false if no content is playing
Other features
- api: deprecated api now only warn once
- tests: integration tests have been added
- manifest: the manifest object and the management of its index has been refactored for future improvements
Multiple new API have been added. They generally replace in a more stable way now deprecated methods and options.
v2.1.0
Release 2.1.0 (2017-05-29)
Overview
This release adds new features, completely documents the API and fixes multiple bugs.
To keep improving the player, multiple API calls and options have been deprecated. That is, they still work for now but won't in the next major version. All of these are documented in the doc/deprecated.md file.
To sum up this version:
-
audio description (just for DASH) and closed caption (DASH+smooth) support has been added
-
live DASH contents are better handled.
SegmentTimeline
based contents should now be completely managed. (SegmentTemplate
without a SegmentTimeline still have a problem for now) -
new methods have been added to access the parsed manifest's information (
getSegments
,getCurrentRepresentations
,getCurrentAdaptations
) -
it is now possible to implement your own segment loader through the loadVideo's
segmentLoader
option. -
A powerful new
loadVideo
option to define the starting positionstartAt
has been added. It can be set relatively to the live edge or buffer depth of live contents -
new player options have been added to better control the adaptive logic (specifically the max authorized bitrate)
-
BIF
(image tracks) support for dash contents has been added.
Added
Audio description and closed captions support
It's now possible to switch specifically to audio description and closed captions tracks.
Those are now automatically detected following the DASH-IF and DVB-DASH specifications for DASH contents and the smooth streaming specification for smooth streaming contents.
To keep a compatibility with the old API (and to improve the naming overall), new API calls have been added:
- getAvailableAudioTracks
- getAvailableTextTracks
- getAudioTrack
- getTextTrack
- setAudioTrack
- setTextTrack
- disableTextTrack
New manifest-related API
Multiple manifest informations are now accessible through the API. The structure of a Manifest has been completely documented here.
This is what will be returned when you call the getManifest method.
Also new methods have been added:
segmentLoader option
A new loadVideo option, segmentLoader
, allows to define a specific segment downloader option. One of the main usecase is for P2P streaming. It is documented here.
New options for adaptive streaming
Two new player options to better control the strategy calcultating the maximum authorized video bitrate have been added:
startAt option
The timeFragment
has been deprecated to be replaced by the startAt
option. This option is much more powerful and is documented here.
BIF support for DASH contents
DASH contents can now have a image
track. This is detected in the DASH manifest if the following condition is respected:
- the adaptation/representation's mimeType is equal to
"application/bif"
The rest of the implementation is the same than for smooth streaming.
Other features
Multiple new API have been added. They generally replace in a more stable way now deprecated methods and options.
Deprecated
A large part of the API has been deprecated. Everything is documented here.
Bug fixes
This release comes with its lot of bug fixes. Most of it is related to dash and languages. You can consult the changelog for more infos.
What's next
The next important steps are:
- better adaptive management (take into account the buffer available when defining the bitrate)
- better player stability (ensure the player is never stalled indefinitely, better error management)
- better DASH support, live or onDemand (support SegmentTemplate live contents, better text track support)
Those will surely come with a new major release v3.0.0
.
v2.0.12
Release 2.0.12 (2017-05-12)
Overview
This release comes after a transition period during which the status of this repo was uncertain.
The code was however still maintained internally by Canal+ and what is merged here can be considered as a stable milestone.
About the version
We did not update much the version number here to keep a coherence with what we are based on internally. From this point onward, release numbers will follow a strict semantic versioning system, to help the ease with which people can continually integrate our player as a library.
What did change from the last version?
Because the project was managed internally with few people, we did not keep a formal changelog. You shouldn't however encounter breaking changes from the last version.
What's for now
From now on, regular fixes and improvements will regularly be added here.
The changelog will also be updated and breaking changes / improvements / bug fixes will be reported here.
Issues and pull requests will also be read and considered. Please bear in mind however that we do not have a lot of ressources for now, so a little delay may be encountered.
Some heavy refactoring work e.g. for ABR (adaptive bitrate) management is pending, so expect new releases in the coming months.
A rewrite of the documentation is also under progress.
Thanks.