v3.16.1
Release v3.16.1 (2019-10-03)
Overview
This release includes bug fixes and improvements:
- For DASH contents: we continued to improve multi-Period support
- For MetaPlaylist contents: we improved transition between contents
- For Smooth contents: we now request the right URL when a
{CustomAttributes}
token is declared in the Manifest - we avoid many left case of segment re-downloading (e.g. when there is a time
difference between the real segment and what is deduced from the Manifest) - we fixed some small issues which arised after a "RELOADING" state
DASH Multi-Period and MetaPlaylist improvements
Note about the RxPlayer management of DASH's Periods and MetaPlaylist's contents
A DASH's MPD can contain multiple Period
elements. Each of those allow to declare which content to play for a given period of time. They allow complex use-cases such as being able to play multiple concatenated contents - each with their own languages and/or qualities - as a single content.
This is very close to the MetaPlaylist concept of contents
(if you're not familiar with what a MetaPlaylist is, it's a feature we recently introduced, documented here).
Because both concepts are very close, they are coalesced into one single concept by the RxPlayer, which we also called Period
. In consequence most improvements declared here impact DASH's Period
s as well as MetaPlaylist's contents
.
Now let's go into the actual improvements.
Fixed multi-Period MPD update
First the most important bug fix: we fixed problems we had with MPD updates.
When a multi-Period MPD was refreshed, it could lead in some cases to the player infinitely re-buffering. This actually happened when Period were added/removed and is due to a bad logic on our part. That bad logic was present since we implemented multi-Period management in the RxPlayer.
Thankfully, our new logic is fully tested and should even be able to handle worst-case scenarios that weren't possible before, like Period introduced in-between other Periods.
Handling of discontinuities between Periods
As a second improvements, we now also better handle discontinuities between DASH's Periods and MetaPlaylist contents.
When Periods/contents are not contiguous, the RxPlayer will automatically detect it when reaching that discontinuity and automatically seek to skip it.
Fix of various problems during Period transitions
Lastly, we realized that an improvement we introduced in the v3.15.1
, namely the usage of append windows
, could lead to all sort of problems in different browsers:
- some segments could be re-downloaded infinitely
- decoding glitches
- infinite rebuffering
Append windows basically allow to "cut" a segment at certain point in time. For example, a segment beginning at the second 499
could instead be made to begin at the second 500
by using them.
In the RxPlayer, they were used to improve multi-Period transitions, as a Period could start or finish in a middle of a segment.
However, things were not so ideal. We found out that cutting that way a segment could lead to browsers removing even more data than needed and other issues. As a compromise, we now are a little more loose to those append windows by adding some hundreds of milliseconds to them as a security.
Browser support is now much better.
Re-thinking of how we choose which segments to download
Choosing which media segments to download is one of the main role of the RxPlayer.
Before this release, here's how it went down in the RxPlayer:
- The player calculate from the Manifest which segments it might need are available. This is usually done by asking segments from the current position to another date several seconds/minutes after that position.
- It then looks at the segments already buffered.
- The segments obtained through step 1 are each compared to those obtained through step 2. If we find that we already buffered a segment or the same segments but in a better quality, we filter it out.
- We put all those segments in a download queue.
That logic worked well in most cases, but did poorly for some specific contents. For example, when a large enough "drift" was present between what a Manifest announces to be a segment's start time and its actual start time when buffered, we could be inclined to think that the segment have been garbage collected. As such, it would be re-downloaded.
To avoid those cases, we first kept everything that way and just added logic to specifically improve the tolerance of those drifts.
However what worked for one content failed for another, we quickly saw that we had to refactor that logic.
The new logic is now as follow:
- We take the segments already buffered
- We remove from those the segments we do not want anymore (often those of poor quality compared to what we can currently download, or those that are garbage collected)
- We now have a list of buffered segments, with possible "holes", which we will want to fill in
- We calculate from the Manifest the segments that are available
- From those, we remove those that are either already downloaded or who are not overlapping any of the "holes" in the buffer
- we put all of those segments in a download queue
This new logic has small subtleties which make it much easier to reason about: Before we wanted to know which individual segment was already downloaded to filter them out, now we look for filling in holes in the buffer.
We also found this new solution to work with much more case. We now notice significantly less cases of segment re-downloading for contents with a high drift.
Generating URLs in the demo
We introduced in the v3.15.1
the possibility to store contents locally in the demo.
This was to allow demo users to store their custom contents' configuration.
We now also introduce the possibility to easily share those custom and stored contents by allowing demo users to easily generate an URL for them.
This can be done by clicking on the link button, which appear only for custom and local contents.
As a bonus, those URLs were especially made to be:
- readable: you shoud be able to see what the content is just by looking a the URL
- "copy-pastable": URLs included in that URL (such as a Manifest URL) are not escaped
- compact enough to be easily shareable by emails
We hope that this new demo feature will allow to improve debugging of the RxPlayer and/or the content themselves by facilitating the exchange of configurations.
CHANGELOG
Bug fixes
- dash: update timeshiftBufferDepth considered when refreshing the MPD
- dash: fix infinite rebuffering issue when refreshing a Multi-Period MPD with the oldest Periods removed
- api: go to
"SEEKING"
state instead of"BUFFERING"
when seeking while the player is in the "BUFFERING" state - api: Avoid reinitializing the video, audio and text track choice after a
"RELOADING"
state - api: When going back to a Period on which
disableTextTracks
was called, keep the text track disabled even if differentpreferredTextTracks
are set - smooth: Replace
{CustomAttributes}
token in a segment URL - dash: load the last segment of a Period when it is declared in a SegmentTemplate (with no SegmentTimeline) and when its end is exactly equal to the end of the Period
Other improvements
- dash/metaplaylist: be more tolerant with the appendWindows set as the previous behavior could lead to infinite rebuffering and segments re-downloading
- dash/metaplaylist/smooth: Better handle discontinuities in a VoD content
- dash/metaplaylist: Handle discontinuities between DASH Periods and between MetaPlaylist contents
- dash/smooth: Avoid requesting multiple time the last segment when the duration given in the Manifest are inexact
- smooth: Skip without throwing Manifest's StreamIndex with an unrecognized type
- dash: Improve prediction of when to update a dynamic MPD with xlinks
- dash: Be more tolerant of differences between a segment's time anounced by the Manifest and the reality to avoid multiple cases of segment re-downloading
- dash: Guess initialization range for segments defined in a SegmentBase without an Initialization element
- dash: Throw better error when a sidx with a reference_type
1
is encountered - api: Throw a better error when setting a
preferredAudioTracks
orpreferredTextTracks
value in the wrong format - demo: Allow to export and share demo links with custom contents
- demo: Fix video track switching in the demo page
- demo: Fix spinner not hiding when playing on very specific conditions