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.

Only use what you need to!

Radiant Media Player offers many possibilities thanks to the many features it supports. However, the more you enable features or query the player API the more it may affect global execution time. As such you should be mindful as to what player features you are enabling and how you are using the player API.

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.6.31/js/rmp.min.js or self-hosted on your server. It is light and runs fast but depending on your player configuration 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.6.31/css/rmp-s1.min.css or self-hosted on your server.
  • DASH: the player uses Shaka player to render DASH content - the Shaka player build is optimised to only encompass the DASH features the player needs (shaka-player.compiled.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.6.31/dash/shaka-player.compiled.js 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 (selected through player setting hlsEngine) where Media Source Extensions are available. 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. It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.6.31/hls/hls.min.js or self-hosted on your server.
  • Video ads - enabled with the ads setting set to true - the VAST parser can be selected with the adParser setting:
    • Google IMA: When using Google IMA to render video ads 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 VAST parser rmp-vast (rmp-vast.min.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.6.31/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.6.31/three/three.min.js or self-hosted on your server.
  • VTT captions: when captions are rendered through the ccFiles player setting, the player will load vtt.js (vtt.min.js). It can be loaded from our cloud at https://cdn.radiantmediatechs.com/rmp/4.6.31/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, Vivaldi). 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.6.31/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.6.31/flash/rmp.swf and https://cdn.radiantmediatechs.com/rmp/4.6.31/flash/flashlsOSMF.swf or self-hosted.

For a guide on self-hosting player files go here.

Pre-loading/bundling dependencies

Depending on your use-case you may want to preload or bundle your JavaScript or CSS files in your application. This can help reduce network requests and global readiness time. If you go down that road note that player dependencies must be fully loaded before Radiant Media Player core library (rmp.min.js). When bundled, rmp.min.js must come after all player dependencies. The player will not request those dependencies if they are already available. You can obtain the download-able player dependencies in our back-end through the self-hosted package. Examples:

Preloading CSS (add to your <head> before rmp.min.js):

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

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

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

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

Google hosted libraries (Google IMA, Google Cast, Google analytics) must be loaded from Google servers, otherwise they may not function as expected. As such they cannot be bundled into a larger file.

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.

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.