Performance tuning

Guide sections

• Use an optimised player build
• Best practices for scoring high at Google Lighthouse audio tool with Radiant Media Player
• Live & DVR streaming
• hls.js specific optimisations
• Media preloading
• ABR/buffer tuning

Radiant Media Player is automatically optimised based on input player settings. This article describes some best practices and advanced performance tuning options.

Use an optimised player build

Since Radiant Media Player 5 we provide optimised builds that pre-pack common features and reduce the network/processing cost to load the player into a web page. We recommend using the build that best match your needs. Available builds are listed here.

Best practices for scoring high at Google Lighthouse audio tool with Radiant Media Player

Displaying media content on a web page can be taxing for the viewer device (CPU, battery, network ...). Optimising performance is key to keeping your viewers happy. To achieve high performance with Radiant Media Player we have released guidelines for scoring high at Google Lighthouse audio tool, through player CSS preloading and async player embedding.

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:

• 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.