Media preloading

Documentation sections

• Media preloading pros and cons
• Media preloading player settings
• Media preloading support notes
• Start-up time verification
• Player code example

Media preloading pros and cons

You probably have heard it somewhere: low start-up time is key to growing and keeping an audience. This is true, who wants to wait 10 seconds for content playback to start in 2018?

One way to achieve faster start-up time for your content is to enable media preloading in your player. This means that the player will start fetching content as soon as page loads (most of the time preloading is wanted at page load), more precisely with Radiant Media Player this happens when you call init method while using an appropriate preload value.

However enabling media preloading comes at a price for both you and your viewers:

• For your viewers: client-side bandwidth and resources (like battery & CPU) usage will be higher. This may also cause a slower page load.
• For you: your bandwidth cost will increase, which may become a concern with expansive services like cloud-streaming or CDN services.

By default in Radiant Media Player, media preloading is disabled ( preload setting set to 'none' - see next section). You should opt in a more permissive media preloading when needed based on your project requirements.

Media preloading player settings

preload: String

Radiant Media Player supports the HTML5 media preload attribute for MP4/WebM progressive download, hls.js, Shaka player, and native HLS (native HLS is mainly used for iOS/macOS Safari). Accepted values are 'none', 'metadata' and 'auto'.

• 'none': means no media preloading happens. Media loading starts upon a valid user interaction. This is default.
• 'metadata': means only a restricted chunk of content will be preloaded, generally to acquire information like duration, codec information and such.
• 'auto': means media content will be preloaded as much as possible until the player buffer is full. For MP4/WebM progressive download and native HLS, the browser is in charge of determining the player buffer length. For hls.js-based streaming maximum buffer length can be set with hlsJSMaxBufferLength (defaults to 30 seconds of content) and for Shaka player-based streaming with shakaStreamingBufferingGoal (defaults to 20 seconds of content)

Media preloading support notes

Media preloading is not always welcome by an OS/device. Typically on Chrome for Android media preloading is disabled by the OS when viewer is on a cellular network. Radiant Media Player enforces the following rules in order to follow best practices with media preloading:

• On mobile devices (except iPadOS) preload setting is always set to 'none'. This is to avoid unexpected data charge for your viewers.
• When autoplay is requested preload setting is always set to 'auto'.
• When using Apple FairPlay streaming preload setting is always set to 'auto'.
• When using media preloading with Shaka player or hls.js only the 'auto' and 'none' values are available for preload setting - 'metadata' value will behave like 'auto' value.

Start-up time verification

Radiant Media Player analytics API exposes a getStartUpTime method which can be used to track your average player start-up time for a given set up and content. This can be useful to best determine what preloading strategy works for you.

Player code example

<script src="https://cdn.radiantmediatechs.com/rmp/5.6.0/js/rmp.min.js"></script>
<div id="rmpPlayer"></div>
<script>
var src = {
  hls: 'https://your-hls-url.m3u8'
};
var settings = {
  licenseKey: 'your-license-key',
  src: src,
  width: 640,
  height: 360,
  // Here we enable preloading - in this case we use the 'auto' value
  preload: 'auto',
  contentMetadata: {
    poster: [
      'https://your-poster-url.jpg'
    ]
  }
};
var elementID = 'rmpPlayer';
var rmp = new RadiantMP(elementID);
rmp.init(settings);
</script>