Radiant Media Player

HLS streaming documentation

HLS support in Radiant Media Player

Our HLS to HTML5 video implementation relies on media source extensions (MSE) support and fallback to native HLS to HTML5 video (iOS, Mac OS Safari, older Android) where media source extensions is not available. For older Desktop devices (mainly Internet Explorer 11 on Windows 7) our HLS to Flash fallback can provide playback support with a restricted set of features (see our Flash support page).

Our HLS MSE implementation is based on hls.js.

Supported HLS features

  • Playback of H.264/AAC or H.264/MP3 content in .ts fragments
  • Playback of H.264/AAC in fmp4 fragments (fragmented MP4 container) BETA
  • Live, DVR and on-demand video streaming
  • Optimized adaptive bitrate streaming with automatic or manual bitrate selection
  • Multiple-audio tracks
  • AES-128/SAMPLE-AES decryption
  • ID3 tags
  • WebVTT & CEA 608/708 captions
  • Program-date-time
  • Discontinuities
  • Resilience to errors
  • Redundant/Failover Playlists
  • Audio-only: AAC container or MPEG Audio container (MPEG-1/2 Audio Layer III)
  • App-store compliant HLS streams playback (see hlsJSAppleAppStoreCompliance setting below for compliance notes)

Generally available features like video ads, JavaScript API or playback rate changes are also supported with HLS to Radiant Media Player.

Supported M3U8 tags

  • #EXTM3U
  • #EXT-X-STREAM-INF (adaptive streaming)
  • #EXT-X-ENDLIST (Live playlist)
  • #EXT-X-MAP
  • #EXT-X-KEY

Supported environments

See our compatibility table for a list of environments where HLS streaming is supported with Radiant Media Player.

Best practices

As a rule of thumb Radiant Media Player should work with any-standard compliant HLS provider. In order to provide better cross-device support for HLS streaming to Radiant Media Player we provide the following recommendations:

  • You must set up your streaming server to return proper CORS settings permitting GET requests
  • Content should be with H.264 video and AAC audio (recommended). Content with H.264 video and MP3 audio (MPEG-1/2 Audio Layer III Elementary Stream) can be rendered through the hlsWithMp3Audio setting
  • For H.264 encoded content H.264 Main profile provides best coverage - H.264 Level 5+ (this is for 4K content) encoded content may cause playback issue on older devices
  • Have the same video/audio codec for each rendition of the HLS stream.
  • Have the same audio sampling rate and number of audio channels for each rendition of the HLS stream
  • .ts segments should be 10 seconds length

Player code example

In this example we use a multicodec, multilingual on-demand DASH stream:

<!-- Include Radiant Media Player JavaScript file in your <body> or <head> -->
<script src="https://cdn.radiantmediatechs.com/rmp/4.2.7/js/rmp.min.js" 
<!-- Set up your wrapper div with its unique id -->
<div id="rmpPlayer"></div>
<!-- Set up player configuration options -->
var bitrates = {
  hls: 'https://dqwp3xzzbfhtw.cloudfront.net/vod/smil:bbb.smil/playlist.m3u8',
  // For older desktop devices to support HTML5 video playback we may provide an MP4 progressive download fallback
  // Otherwise the player may fallback to HLS to Flash on those older devices
  mp4: [
var settings = {
  licenseKey: 'your-license-key',
  bitrates: bitrates,  
  delayToFade: 3000,
  width: 640,
  height: 360,
  poster: 'https://www.radiantmediaplayer.com/images/poster-rmp-showcase.jpg'
// Reference to the wrapper div (unique id)
var elementID = 'rmpPlayer';
// Create an object based on RadiantMP constructor
var rmp = new RadiantMP(elementID);
// Initialization ... test your page and done!

Native HLS support notes

On iOS & Mac OS Safari and on older Android devices (Android before version 5), we display HLS to HTML5 video using native device support (this is where media source extensions is not available or not reliable enough). On those devices some limitations may apply:

  • DVR navigation is not supported - DVR streams are treated as simple live streams
  • Manual bitrate switching is not supported - the player uses adaptive bitrate streaming in auto mode and the adaptation logic is left to the browser
  • ID3 tags & program-date-time are managed internally and may not be accessible through our API
  • In iOS fullscreen mode the player will be displayed using the native iOS player (QuickTime-based)

HLS player settings

hlsJSMaxBufferLength: Number

Maximum buffer length in seconds. The player will try to reach and never exceed this value for its buffer. Default: 60.

hlsJSAbrDefaultBandwidthEstimate: Number

Default bandwidth estimate in bits/second prior to collecting fragment bandwidth samples. Default: 500000.

hlsJSCapLevelToPlayerSize: Boolean

This setting limits bitrates usable in auto-quality by the stage dimensions (width & height). Default: false. If set to true, width and height (defined in m3u8 playlist) will be compared with the actual player width and height and only the best match will be used as the maximum available bitrate. This setting is ignored in manual mode so all levels can be selected manually.

hlsJSStopDownloadWhilePaused: Boolean

When set to true this setting will cause the player to stop downloading HLS fragments while it is in a paused or stopped state. This can help to preserve bandwidth. Default: false.
Setting added with version 4.0.23

hlsJSStartLevel: Number
Defines the preferred initial bitrate when playback starts. Default: -1.
  • 0: first level appearing in manifest will be used as start level
  • n: where n is an integer will cause the player to select the nth level at startup. Note that index starts at 0 - so if you have a playlist with 4 levels and you want to start with the 3rd appearing level, n should be 2.
  • -1: automatic start level selection, playback will start from level matching download bandwidth (determined from download of first segment).
Best practice: when hlsJSStartLevel is set to -1, your HLS 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 appearing in your HLS manifest. As such the player will base its initial bandwidth calculation based on this level and this should provide optimal performance.
hlsJSEnableCEACaptions: Boolean
This setting indicates to the player whether or not to parse and display CEA 608/708 captions when detected in an HLS feed. Default: true.
hlsJSLiveSyncDuration: Number
Edge of live delay, expressed in seconds. Default: 30. A value too low (inferior to ~3 segment durations) is likely to cause playback stalls.
hlsJSMinAutoBitrate: Number
Set the minimum value (in bps) that should be used by the automatic level selection algorithm. Default: 0. Example hlsJSMinAutoBitrate: 500000 means that the player - while in auto mode - will pick the best matching level that has a bitrate above or equal to 500000 bps (500 kbps).
hlsJSAppleAppStoreCompliance: Boolean
For App-store compliant HLS video streams which include an audio-only rendition this setting should be set to true to insure proper playback across devices. Default: false.
hlsJSDefaultAudioCodec: String
If audio codec is not signaled in variant manifest, or if only a stream manifest is provided, the player will try to guess audio codec by parsing audio sampling rate in ADTS header. If sampling rate is less or equal than 22050 Hz, then the player assumes it is HE-AAC, otherwise it assumes it is AAC-LC. This could result in bad guess, leading to audio decode error, ending up in media error. It is possible to hint default audio codec to the player by setting hlsJSDefaultAudioCodec to:
  • 'mp4a.40.2': AAC-LC
  • 'mp4a.40.5': HE-AAC
  • 'auto': the player auto-guesses. This is the default.
hlsJSXhrWithCredentials: Boolean
This setting indicates to the player whether or not cross-site Access-Control requests should be made using credentials such as cookies, authorization headers or TLS client certificates. Setting withCredentials has no effect on same-site requests. Default: false.
hlsJSXhrSetup: Function
This setting allows to pass a custom XMLHttpRequest setup to the player (including passing custom HTTP headers). This custom XMLHttpRequest setup will be used for all HLS playlist/chunk requests. This only applies to HLS for MSE where playlist/chunk are retrieved with XMLHttpRequest (i.e. not for Flash or native HLS on Apple devices). Following is an example of using this feature. Note this is just an example - you will need to adapt this to your own set up for a working solution.
function xhrSetup(xhr) {
  if (xhr) {
    // passing custom headers
    xhr.setRequestHeader('X-File-Name', 'rmp-file');
    // passing cookies withCredentials
    xhr.withCredentials = true;
// Then we set our player settings
var settings = {
  licenseKey: 'your-license-key',
  bitrates: {
    hls: 'your-hls-url'
  width: 640,
  height: 360,
  debug: true,
  hlsJSXhrSetup: xhrSetup
hlsWithMp3Audio: Boolean

When set to true the player will provide support for HLS video with H.264/MP3 in MPEG-2 TS container or HLS audio-only in MPEG Audio container (MPEG-1/2 Audio Layer III audio only streams). Note that Microsoft-based browsers (MS Edge or IE 11) do not currently support audio-only HLS in MPEG Audio container so an MP3 progressive download fallback is recommended to support those browsers. Default: false.

hlsFragLoadingMaxRetry: Number

Maximum number of load retries for HLS fragments (when network/IO error detected). Default: 6.
Setting added with version 4.2.1

hlsManifestLoadingMaxRetry: Number

Maximum number of load retries for HLS manifest (when network/IO error detected). Default: 2.
Setting added with version 4.2.1

hlsLevelLoadingMaxRetry: Number

Maximum number of load retries for HLS levels (when network/IO error detected). Default: 4.
Setting added with version 4.2.1

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