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.
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.0/css/rmp-s1.min.css">
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):
Preloading Google IMA SDK (add to your <head> or <body> but before rmp.min.js):
An implementation example of pre-loading dependencies can be found here.
https://cdn.radiantmediatechs.com/rmp/4.9.0/js/rmp.min.js or self-hosted on your server. It is light and runs fast but depending
https://cdn.radiantmediatechs.com/rmp/4.9.0/css/rmp-s1.min.cssor self-hosted on your server.
hlsEngineplayer 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.0/hls/hls.min.jsor self-hosted on your server.
https://cdn.radiantmediatechs.com/rmp/4.9.0/dash/shaka-player.compiled.jsor self-hosted on your server.
adssetting set to true. Two VAST parsers are available with Radiant Media Player and can be selected with the
https://imasdk.googleapis.com/js/sdkloader/ima3.js- it cannot be self-hosted.
https://cdn.radiantmediatechs.com/rmp/4.9.0/rmp-vast/rmp-vast.min.jsor self-hosted on your server.
video360setting. 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.0/three/three.min.jsor self-hosted on your server.
ccFilesplayer setting and
ccParseris 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.0/vtt/vtt.min.jsor self-hosted on your server.
airplaysetting set to false.
googleCastsetting 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
googleCastset to false.
gaTrackingIdis 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.
https://cdn.radiantmediatechs.com/rmp/4.9.0/flash/swfobject.jsor 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
Visit our self-hosted player files documentation for more information.
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:
isLiveset to true setting. See here for more information.
isLiveDvrset to true setting. See here for more information.
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.
Refer to our media preloading guide to learn how media preloading could help achieve faster start-up time.
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.