Skip to content

v3.17.1
Compare
Choose a tag to compare
@peaBerberian peaBerberian released this 20 Dec 16:37
v3.17.1
e8a9306
This commit was signed with the committer’s verified signature. The key has expired.
peaBerberian Paul Berberian
GPG key ID: 2EB79512E0216466
Expired
Learn about vigilant mode.

Release v3.17.1 (2019-12-20)

Overview

The v3.17.1 is a small release containing minor bug fixes:

  • we fixed an issue which affects mostly live DASH multi-period contents, when the MPD is refreshed

  • we fixed a subtitles issue which can arise when manual garbage collection is enabled through the maxBufferBehind or maxBufferAhead options

  • we fixed issues with Directfile playback on iPhones, iPads and iPods.

  • lastly, we added some demo improvements

Fixed issue with dynamic multi-Period MPD

DASH' Manifest, the MPD, has a concept called "Period" which basically allows to divide a content into multiple sub-contents, each having its own tracks and available qualities.

When playing a dynamic DASH content - typically a live stream - the RxPlayer might have to refresh the MPD to know about the new available segments.
When that happens - and when the MPD has multiple Periods - the player has many tasks to do behind the scene:

  • for Periods that it already knew about, it has to extract the new information obtained
  • for Periods that weren't known of previously (e.g. a new program), it has to add it to its internal representation of the MPD
  • for Periods that aren't here anymore (e.g. a program which is now too old, or which has been removed), it has to remove it from that same internal representation

Because the RxPlayer accounts for very rare cases, like Period inserted in-between previously known Periods, the logic behind MPD updates is easy to get wrong.

And that's exactly what happened! We detected a bug when some old Periods were removed which led toward the RxPlayer not updating later Periods, ultimately leading to an infinite rebuffering stream. The user could get out of this situation by seeking far away of the current position, but that was not an acceptable resolution of the issue!

Bugs in that area is not something that is new, and we already had a very similar issue resolved in the v3.16.1. We fixed that new one and added more unit tests on top of it for previously untested cases. We hope that this is the end of such bugs!

Less aggressive subtitles garbage collection

As the RxPlayer is present on memory-constrained devices, we had to include memory-related options and methods in our API.

More specifically options linked to media garbage collection. What we mean by that is the automatic removal of media segments which are either already played or considered too far ahead from the current position.
This is generally the job of the web browser, but we still found that logic insufficient on some devices.

This is the reason why we added the setMaxBufferAhead and setMaxBufferBehind methods, which set the amount of time in seconds the RxPlayer should keep in its buffer (removing everything else), in our v2.3.0 (in mid-2017!).

When looked upon in the API, those methods just announce that they are "removing buffer". What we really mean here is that the RxPlayer will be removing ALL type of media from its buffer: audio, video and subtitles.

Audio and video is for the most part handled by the browsers, the RxPlayer here just has to call a remove method with the right arguments and that's all.

For subtitles however, the situation is more complex:

  • Either we're on the default native textTrackMode where text tracks are handled by the browser, in which case there were no problem
  • Either we're on the more powerful html textTrackMode where text tracks is entirely handled by the RxPlayer.

When in that second situation, we had an issue if garbage collection was enabled.

Depending on multiple factors, such as the amount garbage collected, the size of the segments containing subtitles (basically the more garbage collection was aggressive and the longer the segments last the more "chance" you had to see the bug) and the actions of the users, the RxPlayer could decide to not replace garbage collected subtitles once they are needed again.

We fixed that issue in two ways:

  1. We're less aggressive when garbage collecting subtitles.
    Before, we removed all text cues as soon as it overlapped with the interval we had to clean, even when the amount of time it had to be displayed continued out of that interval. This could lead to the removal of subtitles that were in fact still useful. Now, we only remove those cues once they are entirely contained in that "cleanable interval".

  2. We now handle some forgotten edge cases when re-adding subtitles on top of garbage collected one.
    Basically, we could have to re-download a partially or totally garbage collected segment if we need it again. This action of adding again a segment on top of a partial one lead to a complex logic where the RxPlayer has to make a choice between either combine or replace both segments (there even can be more than two segments involved!).
    We mis-handled some cases, which meant that re-adding segments would in some cases not actually really add the corresponding cues to the buffer.

Directfile fixes on iOS, iPad and iPod

The directfile transport in the RxPlayer API allows to play contents which are natively understood by the web browser (like webm, mp4 but also HLS on apple's browsers) while still using the RxPlayer's API.

On such contents, the RxPlayer rely on specific browser behaviors and properties. Among them, we expect the browser to "preload" a media content even before the user has asked for it to "play".

Sadly, we found that this is not always the case on browsers that we can found on Apple mobile devices (iPhone, iPad and iPod).
This means that on those browsers, the RxPlayer could stay in a LOADING state indefinitely, until the play method is called. As this is not intuitive, we now switch to the LOADED state as soon as metadata (such as the media duration) have been obtained on those devices .
Please note that this means that a BUFFERING state (or even SEEKING, due to the initial seek) can be received just afterwards, as LOADED does not mean that data is available anymore here.

Possibility to set a custom key system in the demo

In the demo, we previously restricted the choice of key systems to either PlayReady, Widevine or Clearkey.

As demo users could need to specify more specific key systems, we now also allow them to specify one by hand (please note that the entire key system name - in reverse domain name form - is expected).

Changelog

Bug fixes

  • dash/metaplaylist: fix infinite rebuffering issue when refreshing multi-Period contents under specific conditions
  • buffer: be less aggressive when garbage collecting subtitles (if the maxBufferAhead/maxBufferBehind options are set) to avoid useful subtitles being removed
  • directfile/compat: for directfile contents, trigger directly the LOADED state on iOS/iPad/iPod browsers as those are not preloaded there

Other improvements

  • demo: display clickable "play" button on the video element when autoplay is blocked due to browser policies - to help users unlock the situation
  • demo: add "Other" key system to allow specifying a custom key system in the demo page
Assets 4
Loading