Recently Apple and Google started (or are about to start) actively blocking autoplay with audio in their browsers. We encourage you to read the following articles for a better understanding of the situation:
From the Chromium Projects Autoplay article: "Use autoplay sparingly. Autoplay can be a powerful engagement tool, but it can also annoy users if undesired sound is played or they perceive unnecessary resource usage (e.g. data, battery) as the result of unwanted video playback."
In the near future we expect autoplay with audio to become unavailable on the majority of devices and thus for people still looking to use autoplay we recommend switching to a unified muted autoplay approach for both mobile and desktop as soon as possible. This technique is being effectively used by numerous sites and social networks including Facebook, Twitter & more.
To deal with those new autoplay policies and starting with Radiant Media Player 4.5 we have implemented promise-based autoplay support which will help to adhere to those new autoplay policies.
Autoplay (or autostart) allows media content or pre-roll advertisement to start without the need for a user interaction - most of the time autoplay happens when page loads.
Radiant Media Player provides support for autoplay of media content or pre-roll advertisement with live, DVR & on-demand streaming. Autoplay works with all supported streaming protocols (HLS, DASH or progressive download). Autoplay of outstream video ad is also supported. On modern mobile devices autoplay with audio is not available but muted autoplay can be used.
As explained above and due to new autoplay policies being rolled out into major browsers (as of end of 2017) we generally recommend using a unified muted autoplay approach - this is for both mobile and desktop devices. This
can be achieved by setting
muted player settings to true. Autoplay with audio may still be available in some desktop browsers but it is likely to be increasingly blocked.
Note that while we do our best to insure that autoplay is available on a wide range of devices, user/browser settings or mobile device modes could cause autoplay (even muted autoplay) to be actively blocked. For example with the release of macOS Safari 11 Apple has started blocking autoplay of media content with audio by default forcing publishers to adopt muted autoplay or to disable autoplay all together for this browser.
The below player settings can help fine tuning your autoplay set up.
An example of implementation with video ads can be found here.
With the release of iOS 10 and Chrome 53 on Android muted autoplay of HTML5 video has been introduced on mobile devices. Previously it was not possible to autoplay video content on iOS & Android browsers even muted. Radiant Media Player has supported muted autoplay for content since the release of iOS 10 and Chrome 53 for Android browsers. With the release of Google IMA SDK 3.164.0 we have also added muted autoplay support for video ads (version 4.0.19) on mobile devices. Muted autoplay of video ads is also possible with our VAST parser rmp-vast. Autoplay with sound (e.g. not muted) is still not possible on iOS or Android browsers as of July 2017 and we do not expect this to change in the near future.
Our testing shows that muted autoplay of preroll video ads or video content works well in latest Safari & Chrome for iOS 10+ and latest Chrome & Firefox for Android 4.3+. Browsers like Samsung Internet or Opera for Android do not seem to currently provide support for muted autoplay and as such those browsers are unlikely to support this feature.
Low power mode on iOS 11+
According to our testing when an iOS 11+ device is in low power mode autoplay even muted is forbidden by the OS. This does not apply to iOS 10 and below. Radiant Media Player will properly handle autoplay requests when low power mode is engaged in iOS 11+ by providing a play button to initiate playback (a user interaction will be needed in such case as autoplay would have failed).
Data saver mode on Chrome for Android
When data saver mode is enabled on Chrome for Android autoplay even muted is forbidden by the OS. Note that this only applies to non-https web pages so on an https site (which should be the norm by now) autoplay won't be affected by data saver mode (meaning that muted autoplay will work as usual). It is to be noted that this restriction is expected to be lifted when Chrome 64 becomes publicly available (around January 2018).
Command the player to autoplay content when init method is called. This works for media content and video ads. On modern mobile devices muted autoplay is supported for media content and video ads. Default: false.
In latest mobile browsers muted autoplay of content/pre-roll ad is supported. When both
mutedAutoplayOnMobile are set to true the player will use muted autoplay on mobile browsers. Setting mutedAutoplayOnMobile to false while autoplay is set to true will cause the player to only autoplay on desktop browsers. Default:
With the release of macOS Safari 11 Apple started blocking autoplay of media content with audio by default. It is still possible to use, to some extend, muted autoplay (assuming a user has not set "Never Auto-Play" in her/his Safari preference).
autoplay is set to true and
mutedAutoplayOnMacosSafari11Plus is also set to true the player will use muted autoplay on macOS Safari 11+ whenever possible. Default: true.
When using the setSrc API method this setting allows to control the behaviour of player after
srcchanged event has fired. When set to true this setting will cause content to autoplay just after
srcchanged event. When
set to false the player will remain in a pause state after
srcchanged event. Default: true. When set to true this setting will only have effect after player has been initialised either through a valid user interaction or successful
autoplay request. This setting is also compatible with playlist/related but when
srcChangeAutoplay is set to false the
relatedUpNextAutoplay settings are automatically set to false.
Setting added with version 4.5.11
This method returns a
Boolean. It must be queried when the
ready event fires to be relevant. If true is returned the player was started due to
autoplay setting set to true (this applies to both autoplay with audio and muted autoplay - the player decides which autoplay mode it can use based on device capabilities - if autoplay is available). If false is returned the player
was not started due to autoplay and will require an explicit interaction to start, for example a click/touch on the play/pause button or a call to the API play method. Note that this method does not state if autoplay was successful (user/device/plugin
settings may block autoplay), it just reflects how the player was initially started.
null is returned in case the value is not available.
This API event will fire when autoplay is requested and causes player to successfully start content or pre-roll ad.
This API event will fire when autoplay is requested but fails to automatically start content or pre-roll ad. This generally means the targeted device has blocked autoplay or that content could not be fetched from server.