Radiant Media Player

Performance tuning

Guide sections

Radiant Media Player is automatically optimised based on input player settings. As such no extra step is required to get the most out of the player. This article describes some best practices and inner player workings and is oriented towards advanced users.

Pre-loading dependencies for faster player readiness and start-up time

By default the player automatically loads its required dependencies based on player settings after init method is called. This works great in most case-scenario, however you may want to consider adding those dependencies on page load before including Radiant Media Player core library for faster player readiness and start-up time. Those dependencies may also be bundled in larger application-level JavaScript or CSS files to reduce the number of network requests needed to run your application. Bundling those dependencies requires using self-hosting for player files. A list of player dependencies can be found here. Examples:

Preloading CSS (add to your <head> before rmp.min.js - replace s1 with s2, s3 or s4 for different skins):

<link id="rmp-dress-code" rel="stylesheet" type="text/css" href="https://cdn.radiantmediatechs.com/rmp/4.9.1/css/rmp-s1.min.css">

Note the id="rmp-dress-code" which is required for proper preloading of player CSS.

Preloading hls.js (add to your <head> or <body> but before rmp.min.js):

<script src="https://cdn.radiantmediatechs.com/rmp/4.9.1/hls/hls.min.js"></script>

Preloading Google IMA SDK (add to your <head> or <body> but before rmp.min.js):

<script src="https://imasdk.googleapis.com/js/sdkloader/ima3.js"></script>

An implementation example of pre-loading dependencies can be found here.

List of player dependencies

Radiant Media Player consists of a core JavaScript library: rmp.min.js. It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/js/rmp.min.js or self-hosted on your server. It is light and runs fast but depending on your player settings it will need to load one or more dependencies to execute the requested features. Those dependencies are loaded with JavaScript (using async loading to improve execution time whenever possible). Here is the list of those dependencies:

  • CSS: the player needs to load its CSS to shine. Each player skin has its own CSS file (rmp-s*.min.css). This is a required dependency. It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/css/rmp-s1.min.css or self-hosted on your server.
  • HLS: the player uses either hls.js (default - hls.min.js) or Shaka player (shaka-player.compiled.js) to render HLS content where Media Source Extensions are available. The HLS engine can be selected through the hlsEngine player setting. Where Media Source Extensions are not available (iOS & macOS Safari, older Android devices) the player uses native HLS to HTML5 video which does not requires any dependency to run. hls.js can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/hls/hls.min.js or self-hosted on your server.
  • DASH: the player uses Shaka player to render DASH content - Radiant Media Player uses a custom Shaka player build which only encompasses the DASH features the player needs (shaka-player.compiled.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/dash/shaka-player.compiled.js or self-hosted on your server.
  • Video ads: enabled with the ads setting set to true. Two VAST parsers are available with Radiant Media Player and can be selected with the adParser setting:
    • Google IMA: When using Google IMA to render video ads (this is default) the player needs to load the ima3.js library. Note that this library must be loaded from Google servers at https://imasdk.googleapis.com/js/sdkloader/ima3.js - it cannot be self-hosted.
    • rmp-vast: alternatively to Google IMA you may consider using our open-source VAST parser rmp-vast (rmp-vast.min.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/rmp-vast/rmp-vast.min.js or self-hosted on your server.
  • 360 video: enabled with the video360 setting. The player uses three.js (three.min.js) to render 360 video. It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/three/three.min.js or self-hosted on your server.
  • VTT captions: when captions are rendered through the ccFiles player setting and ccParser is set to 'vtt.js' (this is default), the player will load vtt.js (vtt.min.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/vtt/vtt.min.js or self-hosted on your server.
  • AirPlay: while AirPlay does not require to load any dependency to work on iOS or macOS Safari it should be noted that enabling AirPlay (which is default) is likely to cause extra CPU and thus battery usage, even if not actively used. It can be turn off with airplay setting set to false.
  • Google Cast: when googleCast setting is set to true (which is default) the player will need to load the Google Cast framework for browsers supporting Google Cast (Chrome). This library must be loaded from Google servers https://www.gstatic.com/cv/js/sender/v1/cast_sender.js?loadCastFramework=1 - it cannot be self-hosted. It can be turned off when using googleCast set to false.
  • Google Analytics: when setting gaTrackingId is used, the player will load the required Google Analytics library from Google servers https://www.google-analytics.com/analytics.js. This library must be loaded from Google servers - it cannot be self-hosted.
  • Flash: Flash support in Radiant Media Player is deprecated and limited to supporting HLS streaming on Internet Explorer 11 for Windows 7. When Flash is needed (e.g. all HTML5 rendering options have been depleted) the player will load the swfobject library to load and embed Radiant Media Player Flash fallback. It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/flash/swfobject.js or self-hosted on your server. Once swfobject.js is available it will load our Flash fallback (rmp.swf) and flashls (flashlsOSMF.swf). Those SWF files can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.9.1/flash/rmp.swf and https://cdn.radiantmediatechs.com/rmp/4.9.1/flash/flashlsOSMF.swf or self-hosted.

Visit our self-hosted player files documentation for more information.

Live & DVR streaming

By default the player does not auto-detect live or DVR streams, you must explicitly tell it to prepare for a live or DVR stream in your player settings. This will enable the live/DVR UI and optimisations to better deal with those kind of streams:

  • For live streams, use isLive set to true setting. See here for more information.
  • For DVR streams, use isLiveDvr set to true setting. See here for more information.
  • For low latency live/DVR streaming with HLS see here for tuning information.

hls.js specific optimisations

By default, Radiant Media Player uses hls.js to render HLS streaming on most devices. Various player settings and hls.js options are available but on a performance point of view you should want to review:

  • hlsJSLight: when set to true this setting allows the loading of a lighter and faster version of hls.js. However this lighter version does not support multi-audio or captions tracks, so before using this option make sure you do not need to support those features
  • hlsJSStartLevel: by default automatic start level selection is enabled, playback will start from level matching download bandwidth (determined from download of first segment). In order for this to best work with ABR HLS, your manifest should include a lower-end rendition (generally this should not exceed 500 kbps audio & video included) and this rendition should be the first listed in your HLS manifest. As such the player will base its initial bandwidth calculation based on this level and this should provide optimal performance.
  • hlsJSCapLevelToPlayerSize: by default, we limit bitrates usable in auto-quality depending on player size (width & height). This means that a window-player with a 640x360 size will not render a 1080p rendition if a 360p rendition is available when in auto mode (all renditions can be selected manually regardless of hlsJSCapLevelToPlayerSize and player size). In full-screen, where the player size is generally bigger, the player will have the option to use higher resolution/bitrate renditions assuming enough bandwidth is available. This is great because it helps you save bandwidth cost while still providing a good user experience. Indeed, one can see very little benefit in giving higher resolution/bitrate renditions to a window-player. This is also good news for lower-end devices or fluctuating network conditions as the player will require less CPU/bandwidth to render ABR streams. Note that this behaviour is also implemented by Apple with native HLS to HTML5 video on macOS Safari and we decided to enable this option by default as well.

Also make sure to comply with our HLS streaming best practices here.

Media preloading

Refer to our media preloading guide to learn how media preloading could help achieve faster start-up time.

ABR & buffer tuning

HLS & DASH are adaptive bitrate streaming technologies. Hence having a well-tuned ABR logic is paramount to insure a good user experience and reduce bandwidth cost. Radiant Media Player default ABR logic is tuned to work well in most common use-cases seen now-days. We also do expose ABR/buffer settings for both our hls.js and Shaka player implementations.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License.