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