Server side ad insertion (a.k.a. SSAI) is the notion of injecting advertisement materials in-stream through a server process, much like what the TV industry has been doing for a long time now. This can apply to live, on-demand or DVR content.
As such the ad, or the pod of consecutive ads, can be inserted into the actual content. With Radiant Media Player we support server side ad insertion with HLS and DASH. Radiant Media Player should work with any standard compliant server-side solution that offers ad insertion services. Please contact us if your set-up requires additional configuration.
Dynamic ad insertion (a.k.a. DAI) is the notion that the process of inserting ads with server side ad insertion should be up-to-date and relevant to the audience. For example, if we consider global content delivery you may want viewers from a specific country to view specific ads that are relevant to a local market. Also in terms of timing, you may want content that was recorded months or years ago to still display ads that are relevant to today's market. A dynamic ad insertion service can help you get server side inserted ads that are always relevant in terms of time & location.
Since Radiant Media Player 5.0.5, we support Google DAI solution through the HTML5 IMA DAI SDK. Visit our documentation on the subject to learn more.
At the end of the day it is up to you to decide what is best for your business - either server side ad insertion or client-side VAST ad insertion - you can do both with Radiant Media Player.
There are different approaches to server-driven ad insertion with HLS or DASH. In the next sections we will review most common use-cases: HLS with discontinuities and multi-period DASH.
You can use server side ad insertion with HLS and Radiant Media Player through the HLS
EXT-X-DISCONTINUITY tag. Each ad shall be represented by a discontinuity within the HLS stream. This is described on
Apple website here.
The player will properly handle
EXT-X-DISCONTINUITY and display the ad when indicated in a live or on-demand HLS stream.
To go further when an ad-related discontinuity starts we could want to display the player ad-dedicated user interface (or hide it when an ad-related discontinuity ends). When the ad UI is on viewers will be presented with a friendly ad user interface
and for on-demand HLS viewers will not be able to seek into the HLS stream in order to skip the ad. Currently this behaviour, if wanted, needs to be implemented through the player API
setAdUI methods. In
order to be notified of a discontinuity we can use the player event
hlsfragmentbeingplayedchanged. When this event fires we are able to query the player API
getHlsFragmentBeingPlayedData method and obtain the related URL for the fragment being played. As such we can test the pattern
of this fragment URL to know for sure when an ad-related discontinuity starts or ends.
But let us walk through a concrete example for a better understanding. A complete example using the above approach can be found here.
Similar to HLS discontinuities, DASH provides support for multi-period. A server side inserted ad could be represented by a period. If you submit to the player a DASH-compliant manifest which holds multiple periods data the player will parse those information and update content presented to the viewer accordingly. See our DASH streaming documentation for more information on the subject.