Loading a Content

The loadVideo method

The loadVideo method of the RxPlayer loads the content described in the argument.

This is the central method to use when you want to play a new content. Options available are described in the next chapters. Despite its name, this method can also load audio-only content.

Example

player.loadVideo({
  url: "http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_6s/Manifest.mpd",
  transport: "dash",
  autoPlay: true,
});

loadVideo options

loadVideo receives a single object in argument which can take several properties all defined here.

transport

type: string|undefined

The transport protocol used for this content. This property is mandatory.

Can be either:

• "dash" - for DASH contents.

  If you’re using the minimal build of the player, you will need to add at least either one of the following features to be able to play DASH contents:

  • the DASH feature (rely on a generally-sufficient JavaScript parser)

  • the DASH_WASM experimental feature (backed by a WebAssembly parser, more efficient when handling very large MPDs). More information in the DASH_WASM experimental feature documentation.

  • or both (which will use the latter only when available)

• "smooth" - for Microsoft Smooth Streaming contents

  If you’re using the minimal build of the player, you will need to add at least the SMOOTH feature to be able to play Smooth contents.

• "directfile" - for loading a video in DirectFile mode, which allows to directly play media files (example: .mp4 or .webm files) without using a transport protocol. With that option, you can even play HLS contents on multiple browsers (mainly safari and iOS browsers).

  If you’re using the minimal build of the player, you will need to add at least the DIRECTFILE feature to be able to play those contents.

• "metaplaylist" for MetaPlaylist streams, which are a concatenation of multiple smooth and DASH contents

  If you’re using the minimal build of the player, you will need to add at least the METAPLAYLIST experimental feature to be able to play those contents.

• "local" for local manifests, which allows to play downloaded DASH, Smooth or MetaPlaylist contents (when offline for example).

  If you’re using the minimal build of the player, you will need to add at least the LOCAL_MANIFEST experimental feature to be able to play those contents.

Example:

// play some dash content
rxPlayer.loadVideo({
  transport: "dash",
  url: "https://www.example.com/dash.mpd",
});

url

type: string|undefined

For Smooth, DASH or MetaPlaylist contents, the URL to the Manifest (or equivalent)

For DirectFile mode contents, the URL of the content (the supported contents depends on the current browser).

This property is mandatory unless either:

• a manifestLoader option is defined, in which case that callback will be called instead any time we want to load the Manifest.

• an initialManifest option is defined, in which case it as the first version of the Manifest. Note however that if the Manifest needs to be refreshed and no url nor manifestLoader has been set, the RxPlayer will most likely fail and stop playback.

Example:

// play some dash content
rxPlayer.loadVideo({
  url: "https://www.example.com/dash.mpd",
  transport: "dash",
});

keySystems

type: Array.<Object>|undefined

keySystems allows to define every options relative to the encryption of the wanted content.

This property is mandatory if the content relies on DRM and needs to be decrypted but unnecessary if the content is not encrypted.

As keySystems options are numerous, they are described in its own documentation page, Decryption Options.

autoPlay

type: Boolean|undefined

defaults: false

If set to true, the video will play immediately after being loaded.

startAt

type: Object|undefined

startAt allows to define a starting position in the played content whether it is a live content or not.

This option is only defining the starting position, not the beginning of the content. The user will then be able to navigate anywhere in the content through the seekTo API.

If defined, this property must be an object containing a single key. This key can be either:

• position (Number): The starting position, in seconds.

• wallClockTime (Number|Date): The starting wall-clock time (re-scaled position from Manifest information to obtain a timestamp on live contents), in seconds. Useful to use the type of time returned by the getWallClockTime API for live contents. If a Date object is given, it will automatically be converted into seconds.

• fromFirstPosition (Number): relative position from the minimum possible one, in seconds. That is:

  • for dynamic (live) contents, from the beginning of the buffer depth (as defined by the Manifest).
  • for non-dynamic (vod) contents, from the position 0 (this option should be equivalent to position)

• fromLastPosition (Number): relative position from the maximum possible one, in seconds. Should be a negative number:

  • for dynamic (e.g. live) contents, it is the difference between the starting position and the currently last possible position, as defined by the manifest.
  • for VoD contents, it is the difference between the starting position and the end position of the content.

• percentage (Number): percentage of the wanted position. 0 being the minimum position possible (0 for static content, buffer depth for dynamic contents) and 100 being the maximum position possible (duration for VoD content, last currently possible position for dynamic contents).

If the value set is inferior to the minimum possible position, the minimum possible position will be used instead. If it is superior to the maximum possible position, the maximum will be used instead as well.

More information on how the initial position is chosen can be found in the specific documentation page on this subject.

Notes for dynamic contents

For dynamic contents, startAt could work not as expected:

• Depending on the type of Manifest, it will be more or less precize to guess the current last position of the content. This will mostly affect the fromLastPosition option.

• If the Manifest does not allow to go far enough in the past (not enough buffer, server-side) to respect the position wanted, the maximum buffer depth will be used as a starting time instead.

• If the Manifest does not allow to go far enough in the future to respect the position wanted, the current last available position will be used to define the starting time instead.

If startAt is not set on live contents, the time suggested by the Manifest will be considered. If it is also not set, the initial position will be based on the real live edge.

Example

// using position
player.loadVideo({
  // ...
  startAt: {
    position: 10, // start at position == 10 (in seconds)
  },
});

// using wall-clock time
player.loadVideo({
  // ...
  startAt: {
    wallClockTime: Date.now() / 1000 - 60, // 1 minute before what's broadcasted
    // now
  },
});

// using fromFirstPosition
player.loadVideo({
  // ...
  startAt: {
    fromFirstPosition: 30, // 30 seconds after the beginning of the buffer
  },
});

// using fromLastPosition
player.loadVideo({
  // ...
  startAt: {
    fromLastPosition: -60, // 1 minute before the end
  },
});

requestConfig

type: Object

defaults: {}

Configuration linked to Manifest and segment requests. This object can take the following properties (all are optional):

• segment (object|undefined): If set, segment-specific request configuration. That object can contain any of the following properties:

  • maxRetry (number|undefined): Maximum number of times a segment request will be retried when an error happen - only on some condition [1].

    Those retry will be done with a progressive delay, to avoid overloading a CDN. When this count is reached, the player will stop and throw a fatal error.

    Defaults to 4.

  • timeout (number|undefined): Timeout, in milliseconds, after which segment requests are aborted and, depending on other options, retried.

    To set to -1 for no timeout.

    undefined (the default) will lead to a default, large, timeout being used.

• manifest (object|undefined): If set, manifest-specific request configuration. That object can contain any of the following properties:

  • maxRetry (number|undefined): Maximum number of times a Manifest request will be retried when a request error happen - only on some condition [1]. Defaults to 4.

    Those retry will be done with a progressive delay, to avoid overloading a CDN. When this count is reached, the player will stop and throw a fatal error.

    Defaults to 4.

  • timeout (number|undefined): Timeout, in milliseconds, after which manifest requests are aborted and, depending on other options, retried.

    To set to -1 for no timeout.

    undefined (the default) will lead to a default, large, timeout being used.

[1] To retry a request, one of the following condition should be met:

• The request failed because of a 404 HTTP code

• The request failed because of an HTTP code in the 500 family

• The request failed because of a timeout

• the request failed because of an unknown request error (might be a parsing/interface error)

textTrackMode

type: string|undefined

defaults: "native"

This option allows to specify how the text tracks should be displayed.

There is two possible values:

• "native"
• "html"

In the default "native" mode, a <track> element will be created on the video and the subtitles will be displayed by it, with a minimal style. There is no action on your side, the subtitles will be correctly displayed at the right time.

In "html" mode, the text tracks will be displayed on a specific HTML element. This mode allows us to do much more stylisation, such as the one defined by TTML styling attributes or SAMI’s CSS. It is particularly useful to correctly manage complex closed captions (with multiple colors, positionning etc.). With this mode, you will need to provide a wrapper HTML element with the textTrackElement option.

All text track formats supported in "native" mode also work in "html" mode.

More infos on supported text tracks can be found in the text track documentation.

textTrackElement

type: HTMLElement|undefined

textTrackElement is only required and used if you provided a "html" textTrackMode.

This property will be the element on which text tracks will be set, as child elements, at the right time. We expect that this element is the exact same size than the media element it applies to (this allows us to properly place the subtitles position without polling where the video is in your UI). You can however re-size or update the style of it as you wish, to better suit your UI needs.

minimumManifestUpdateInterval

type: number|undefined

Set the minimum time, in milliseconds, we have to wait between Manifest updates.

A Manifest may need to be updated in regular intervals (e.g. many DASH dynamic contents depend on that behavior).

The frequency at which we normally update a Manifest depends on multiple factors: the information taken from the Manifest, the transport chosen or the current playback conditions. You might want to use minimumManifestUpdateInterval to limit that frequency to a minimum.

This option is principally useful on some embedded devices where resources are scarce. The request and data decompression done at each Manifest update might be too heavy for some and reducing the interval at which they are done might help.

Please note however than reducing that frequency can raise the chance of rebuffering, as we might be aware of newly generated segments later than we would be without that option.

Example:

rxPlayer.loadVideo({
  // ...
  minimumManifestUpdateInterval: 5000, // Perform Manifest updates at most
                                       // every 5 seconds
  },
});

initialManifest

type: number|undefined

Manifest that will be initially used (before any potential Manifest refresh).

Some applications pre-load the Manifest to parse some information from it before calling loadVideo. As in that case the Manifest has already been loaded, an application can optimize content loading time by giving to the RxPlayer that already-loaded Manifest so the latter can avoid doing another request for it.

The format accepted for that option depends on the current chosen transport:

• for "dash" and "smooth" contents either a string (of the whole Manifest’s xml data) or a corresponding Document format is accepted.

• for "metaplaylist", either a string (for the whole JSON) or the corresponding JS Object is accepted.

• for "local", only the corresponding local Manifest as a JS object is accepted.

Note that using this option could have implications for live contents. Depending on the content, the initial playing position and maximum position could be calculated based on that option’s value.

In a case where the corresponding Manifest request was performed long before the loadVideo call, the RxPlayer could be for example initially playing far from the real live edge. Because of that, it is recommended to only set that options for live/dynamic contents if its request was done immediately before the loadVideo call.

manifestUpdateUrl

type: string|undefined

Set a custom Manifest URL for Manifest updates. This URL can point to another version of the Manifest with a shorter timeshift window, to lighten the CPU, memory and bandwidth impact of Manifest updates.

Example:

rxPlayer.loadVideo({
  transport: "dash",
  url: "https://example.com/full-content.mpd",
  manifestUpdateUrl: "https://example.com/content-with-shorter-window.mpd",
});

When the RxPlayer plays a live content, it may have to refresh frequently the Manifest to be aware of where to find new media segments. It generally uses the regular Manifest URL when doing so, meaning that the information about the whole content is downloaded again.

This is generally not a problem though: The Manifest is generally short enough meaning that this process won’t waste much bandwidth memory or parsing time. However, we found that for huge Manifests (multiple MB uncompressed), this behavior could be a problem on some low-end devices (some set-top-boxes, chromecasts) where slowdowns can be observed when Manifest refresh are taking place.

The manifestUpdateUrl will thus allow an application to provide a second URL, specifically used for Manifest updates, which can represent the same content with a shorter timeshift window (e.g. using only 5 minutes of timeshift window instead of 10 hours for the full Manifest). The content will keep its original timeshift window and the RxPlayer will be able to get information about new segments at a lower cost.

representationFilter

type: Function|undefined

Allows to filter out Representations (i.e. media qualities) from the Manifest to avoid playing them.

rxPlayer.loadVideo({
  // ...
  representationFilter(representation, infos) {
    // Filter function
  },
});

segmentLoader

type: Function|undefined

Defines a custom segment loader for when you want to perform the requests yourself.

rxPlayer.loadVideo({
  // ...
  segmentLoader(infos, callbacks) {
    // logic to download a segment
  },
});

More info on it can be found here.

manifestLoader

type: Function|undefined

Defines a custom Manifest loader (allows to set a custom logic for the Manifest request).

rxPlayer.loadVideo({
  // ...
  manifestLoader(url, callbacks) {
    // logic to fetch the Manifest
  },
});

More info on it can be found here.

onCodecSwitch

type: string|undefined

defaults: "continue"

Behavior taken by the player when switching to either an audio or video track which has a codec “incompatible” with the previous one (for example going from avc, a.k.a h264 to hevc, a.k.a. h265).

This switch can either after the user switches from one track to another or after encountering a new Period in some transport technologies (concept existing for DASH, “local” and MetaPlaylist contents).

Can be set to one of those two values:

• "continue": try to have a seamless transition between both codecs. This behavior works on most modern browsers but might lead to problems like infinite buffering and decoding errors on older browsers and peculiar platforms. This is the default behavior.

• "reload": When switching from one codec to another - incompatible - one, the RxPlayer will “reload” the content: the player will go into the "RELOADING" state for a small amount of time, during which the video will disappear and many APIs will become unavailable, before playing the track with the new codec. That behavior has the advantage of working on any platform but disadvantage of having a visible transition when those type of codec switches happen.

  Use it if you have issues with codec switching on some platforms.

  More information about the "RELOADING" state can be found in the player states documentation.

defaultAudioTrackSwitchingMode

type: string|undefined

defaults: "seamless"

Behavior taken by the player by default when switching to a different audio track, for example through the setAudioTrack method.

Note that this is only a default value which can be changed at any setAudioTrack call, through its switchingMode optional property.

Those are the possible values for that option:

• "seamless": The transition between the old audio track and the new one happens seamlessly, without interruption. This is the default behavior.

  As an inconvenient, you might have at worst a few seconds in the previous audio track before the new one can be heard.

• "direct": The player will try to switch to the new audio track as soon as possible, which might lead to a brief interruption and rebuffering period (where the RxPlayer is in the BUFFERING state) while it is doing so.

• "reload" The player will directly switch to the new audio track (like direct) but may reload the media to do so. During this reloading step, there might be a black screen instead of the video and the RxPlayer might go into the RELOADING state temporarily.

  Although it provides a more aggressive transition than the "direct" mode (because it goes through a reloading step with a black screen), the "reload" mode might be preferable in specific situations where "direct" is seen to have compatibility issues.

  We observed such issues with some contents and devices combinations, if you observe issues such as losing the audio or video glitches just after changing the audio track while the "direct" mode is used, you may want to use the "reload" mode instead.

  More information about the "RELOADING" state can be found in the player states documentation.

lowLatencyMode

type: Boolean|undefined

defaults: false

Allow to play DASH low-latency contents (with Chunk-encoded and chunk-transferred CMAF segments) with a low latency efficiently.

In the some rare browsers who do not support the fetch API (like IE11 or the BlackBerry browser), we might be more prone to rebuffering in that mode the first few seconds. If you want to have a better experience on those browsers, you might want to begin to play further from the live edge in those cases through the startAt option.

More information on playing low-latency DASH contents can be found in the corresponding documentation page.

enableFastSwitching

type: boolean|undefined

defaults: true

Enable (when set to true and by default) or disable (when set to false) the “fast-switching” feature.

“Fast-switching” is an optimization which allows the RxPlayer to replace low-quality segments (i.e. with a low bitrate) with higher-quality segments (higher bitrate) in the buffer in some situations.

This is used for example to obtain a faster quality transition when the user’s network bandwidth raise up: instead of pushing the new high-quality segments at the end of the current buffer, we push them much sooner - “on top” of already pushed low-quality segments - so the user can quickly see the better quality.

In most cases, this is a feature you want. On some rare devices however, replacing segments is poorly supported. We’ve for example seen on a few devices that old replaced segments were still decoded (and not the new better-quality segments that should have replaced them). On other devices, replacing segments resulted in visible small decoding issues.

Setting enableFastSwitching to false thus allows to disable the fast-switching behavior. Note that it is - sadly - difficult to know when you need to disable it. In the great majority of cases, enabling fast-switching (the default behavior) won’t lead to any problem. So we advise to only disable it when you suspect that segment replacement when the quality raises is at the source of some issues you’re having (in which case it will help to see if that’s really the case).

It is also warning to add that setting enableFastSwitching to false only disable the fast-switching feature and not all the logic where the RxPlayer is replacing segments it already pushed to the buffer. Forbiding the RxPlayer to replace segments altogether is today not possible and would even break playback in some situations: when multi-Period DASH contents have overlapping segments, when the browser garbage-collect partially a segment…

checkMediaSegmentIntegrity

type: Function|undefined

If set to true, the RxPlayer will retry a media segment request if that segment seems corrupted.

If not set or set to false, the RxPlayer might interrupt playback in the same situation.

You can set this option if you suspect the CDN providing your contents to sometimes send you incomplete/corrupted segments.

Example:

rxPlayer.loadVideo({
  // ...
  checkMediaSegmentIntegrity: true,
});

serverSyncInfos

type: Function|undefined

Allows to provide a time synchronization mechanism between the client and the server.

This value is mainly useful for live DASH contents based on a SegmentTemplate scheme without SegmentTimeline elements as those rely on having a synchronized clock on the client side.

The serverSyncInfos object contains two keys:

• serverTimestamp (number): Unix timestamp of the server at a given point in time, in milliseconds.

• clientTime (number): Value of the performance.now() API at the time the serverTimestamp value was true. Please note that if your page contains multiple worker, the performance.now() call should be done on the same worker than the one in which loadVideo is called.

  The `performance.now()` API is used here because it is the main API to obtain a monotically increasing clock on the client-side.

Example:

const timeResponse = await fetch(timeServerURL);
const clientTime = performance.now();
const serverTimestamp = await timeResponse.text();
const serverSyncInfos = { serverTimestamp, clientTime };
rxPlayer.loadVideo({
  // ...
  serverSyncInfos,
});

If indicated, we will ignore any time indication on the MPD and only consider serverSyncInfos to calculate the time on the server side.

This value is also very useful for low-latency contents, as some of them do not indicate any server’s time, relying on the client one instead.

Note that there is a risk of us losing synchronization when leap seconds are added/substracted to unix time. However we consider those situations rare enough (and the effect should be relatively weak) to let this as is for the moment. For a complete explanation, you can look at the corresponding chapter of the low-latency documentation.

referenceDateTime

type: Function|undefined

Only useful for live contents. This is the default amount of time, in seconds, to add as an offset to a given media content’s time, to obtain the real live time.

For example, if the media has it’s 0 time corresponding to the 30th of January 2010 at midnight, you can set the referenceDateTime to new Date(2010-01-30) / 1000. This value is useful to communicate back to you the “live time”, for example through the getWallClockTime method.

This will only be taken into account for live contents, and if the Manifest / MPD does not already contain an offset (example: an “availabilityStartTime” attribute in a DASH MPD).

Example:

rxPlayer.loadVideo({
  // ...
  referenceDateTime: new Date(2015 - 05 - 29) / 1000,
});