As the demand for video streaming escalates, so does the cost associated with maintaining and delivering high-quality content to viewers. Broadcasters, OTT Platforms, and any industry streaming video over the Internet are actively seeking robust monetization strategies to sustain and expand their businesses. While Subscription Video On Demand (SVOD) and Transactional Video On Demand (TVOD) models meet the needs of certain companies, the Advertising Video On Demand (AVOD) model has emerged as the go-to choice for growth without burdening subscribers with high additional costs. AVOD allows content providers to engage a wider audience by offering free or lower-cost access to their video libraries while being subsidized by advertisements. Ad Insertion is then the key technical component to enable this, and two options are available to implement this model successfully: Server-Side Ad Insertion (SSAI) and Client-Side Ad Insertion (CSAI).
In this blog, we will focus on SSAI, how it works, the use cases and challenges for specific workflows and devices, and the different factors that come into play when implementing it.
What is Server-Side Ad Insertion (SSAI)?
To begin exploring the topic, let’s delve into what SSAI is and its benefits. The technology enables ads to be directly delivered within the streaming protocol, seamlessly stitching them into the video stream on the server side just before making it available to viewers. The advantages of this approach include:
- Bypassing ad-blockers – This ensures ads reach viewers
- Smoother integration – Transition from content to ad is more natural
- Improved viewer experience – less buffering and interruptions during playback
- Increased ad revenue – Advertisers are able to stream better-targeted ads to specific user bases
- Flexibility – Ads can be adjusted in real-time, engaging viewers with more personalized ads that meet their interests
A diagram showing how SSAI works
How is it applied to HLS and DASH streams?
As adaptive bitrate (ABR) streaming is the standard for every platform streaming over the internet, SSAI needs to work in the context of two popular video streaming protocols – Dynamic Adaptive Streaming over HTTP (DASH) and HTTP Live Streaming (HLS). While both protocols use fragmented mp4 (ISO BMFF) or transport stream (TS) segments to deliver video content over HTTP to viewers, some protocol differences make the SSAI implementation different for each.
The Dash Implementation
In DASH, SSAI is usually implemented using Media Presentation Description (MPD) Periods. The concept of Periods enables the boundaries between periods in the stream timeline to contain different streaming properties (like codecs, encryption, different adaptations, etc.). When the stream manifest is requested, the ad server in the background resolves ads be delivered within the content and creates MPD Periods at specific advertising time slots. These Periods then contain already chunked ads with their metadata stitched to the original MPD manifest before it is delivered to the viewer’s device.
The HLS Implementation
In HLS, SSAI is often integrated using EXT-X-DISCONTINUITY tags which are present in media playlists. This concept is similar to Periods in DASH, but the main difference is that discontinuities across different playlists (like audio and video) do not have to be aligned. This approach may involve splitting the segmented video stream into smaller segments and splicing them at the appropriate point to insert the ad (the same is valid for DASH). Depending on development expertise and protocol preference, it may require more complex implementations, especially for live scenarios.
A diagram showing the setup of SSAI in DASH and HLS streams
Ads may be injected into both DASH and HLS manifests only into single Periods or playlists without discontinuities, but this approach presents another set of difficulties. The ad segments need to follow the same encoding for adaptation profiles and time synchronization as the main content, which can be challenging when ads need to be inserted in variable time slots or live streams. Also, if the content is encrypted or DRM (Digital Rights Management) protected, the ads must be encrypted using the same encryption schema, which might not be feasible on a large scale. Another problem is client-side tracking requiring specific metadata like EMSG in a container format or Events and Timed Metadata inside the manifest.
Common SSAI use cases and their challenges
SSAI alongside DRM
SSAI is often required to work all along the DRM systems. DRM systems like Widevine, Fairplay, or PlayReady typically use common encryption algorithms to protect the content and require viewers to obtain a license or key to access it. This prevents piracy and other unauthorized access or distribution of the content.
As mentioned above, ads are often delivered separately from the video content and may not be encrypted, so they are placed into separate DASH Periods or HLS discontinuities to be correctly played back on target devices.
A diagram showing SSAI stitched within a DASH stream that is encrypted with DRM
Handling the transition from unprotected to encrypted content may also be challenging on the client side. For example, many steps must be done on MSE and EME API when integrating with javascript clients, like recreating SourceBuffers or waiting for license requests.
In addition to encryption, DRM can also control the distribution and access to ads. This can help prevent unauthorized sharing or reuse of ad content and ensure that the ads are only shown to authorized viewers. By working together, SSAI and DRM can help protect digital video content and ensure it is monetized effectively.
Utilizing SSAI in live streaming
In live streaming, SSAI is a powerful way to deliver targeted and personalized ads to viewers. When implemented, it can reduce latency during the transition between the content and the advertisement during playback. It can also enable dynamic ad scheduling, allowing the platform to change the ads due to inventory or campaign requirements. However, one of the main SSAI challenges is the need to handle segment timestamps carefully to ensure that the ads are inserted at the appropriate point in the video stream. This is because live video streams are constantly changing, and the timing of each segment can vary based on factors such as network latency and processing time.
In order to handle segment timestamps in live streaming, SSAI systems typically use so-called boundary detection. This involves analyzing the incoming video stream to detect critical points or boundaries between segments and then using this information to insert ads at the appropriate moment. In boundary detection, the SSAI system monitors the video stream for changes in the keyframe or scene, which usually indicate the start or end of a segment. The system then uses this information to determine the timing and duration of each segment and to insert ads accordingly. This process requires careful synchronization between the video stream and the ad server to ensure that the ads are inserted at the right time and do not interfere with the viewer’s experience.
A diagram that shows SSAI stitched within a live stream
Due to the considerable complexity of boundary detection, when SSAI is present in the live stream, the main content segments typically have large presentation timestamps (PTS). However, segmented ads present in DASH Periods or HLS discontinuities for dedicated ad slots usually have PTS starting from 0. This may present issues to be handled on the player side as making timestamp continuous is challenging and might introduce some buffering issues.
One last complication to handle in HLS is the effect of splitting the last and first segments of the content stream where the ad is being placed. This often presents issues with the alignment of buffered ranges and may cause playback stalls if not handled correctly.
SSAI in streams viewed on Smart TVs
Delivering SSAI-enabled streams on Smart TVs has its benefits with specific challenges that must be faced, and there are multiple reasons for that. Most smart TV platforms are based on a browser-like environment running JavaScript. LG WebOS, Samsung Tizen, and other smart TV operating systems are exposing native player APIs that are, by their specifications, capable of playing adaptive streams in DASH or HLS. This sounds promising, but unfortunately, streams containing SSAI often do not work, and there is also an absence of proper logs to figure out what is wrong. These native players also do not give much control over how the stream is played back, like managing buffering and controlling ABR algorithms.
The benefit is that most of these platforms also support media source extensions (MSE) and encrypted media extensions (EME) API to manage video streaming using JavaScript, so players supporting SSAI in browsers should work. However, the issue with Smart TVs is the lack of standardization across different platforms. Each Smart TV manufacturer may implement different versions of protocols and specifications of APIs for handling streaming. This often brings various technical limitations to the platform environment, leading to issues supporting different devices. One issue is rollovers in segment timestamps which are common in many live streams, or possible changes in properties of the ad and content segments like encoding parameters, codec, encryption (DRM) transitions, etc. Another issue with SSAI on Smart TVs is the potential for buffering or latency. Smart TVs often have limited processing power and memory, making it difficult to handle ad transitions and provide stable buffering.
Addressing these issues, platforms looking to support these devices and have SSAI-enabled streams playing on them need to put in a lot of effort and perform a lot of black-box testing to figure out the best integration for their streaming workflow. Working closely with Smart TV manufacturers is often required to ensure the ad insertion process is standardized and optimized for their platform. This is why when deploying on different smart TVs and devices in general, it is crucial to consider the unique challenges of supporting them and the steps it takes to optimize the viewing experience for users.
SSAI workflow and third-party providers
Implementing SSAI is usually very complex, which is why many platforms outsource the technical integrations to third-party providers that are running their own SSAI services and are capable of delivering ads into a prepared manifest. There are various providers to choose from like:
- Google Ads Manager DAI (Dynamic ad insertion)
- MediaTailor provided by (Amazon Web Services)
- Yospace
- Broadpeak
The architecture of how SSAI providers integrate with the whole streaming delivery pipeline is a very interesting topic, and we plan to go into further depth on it in a future blog post. In the meantime, we recommend reading our SSAI and Adblocking blog that focuses more on this if you want to learn more.
Playing SSAI-enabled streams with the Bitmovin Player
The Bitmovin Player is designed to work seamlessly with server-side ad insertion solutions. It allows for the dynamic insertion of ads into video streams, ensuring a smooth playback experience for viewers. The Player supports ad stitching, seamlessly blending the ads with the video content during playback. This helps maintain a continuous and uninterrupted viewing experience.
The Bitmovin Player is also pre-integrated with Bitmovin’s Analytics and the Open Measurement Interface Definition (OMID) with its dedicated SDK. This helps give you actionable insights related to your audience and quality of experience metrics while tracking ad events. This data can help you adjust and set where your SSAI ads are utilized since you’ll know your most popular content, where/when viewers are watching it, and how your content and ads perform when streamed, ensuring a smooth viewing experience. Ultimately this will help you optimize your monetization strategy and maximize your business’ potential. To see SSAI in action, check out the Bitmovin player SSAI demo page.
In case there are any device limitations supporting SSAI streams, Bitmovin Player is also compatible with CSAI (Client-side ad insertion) solutions like VAST (Video Ad Serving Template) and VMAP (Video Multiple Ad Playlist) standards produced by IAB (Interactive Advertising Bureau). For more on Bitmovin’s CSAI support, we will be writing up a dedicated blog about it soon, but in the meantime, you can see how it works with our Player by trying our CSAI demo.
Stitching it up
From what we’ve listed above, Server-Side Ad Insertion (SSAI) provides several advantages, including bypassing ad blockers, seamless ad integration, enhanced viewer experience, increased ad revenue, and content security with DRM systems. However, implementing SSAI in streaming workflows for specific devices can be complex due to platform differences and technical limitations. Apart from platforms doing it themselves, Player options like Bitmovin’s can help streamline the process, enabling effective ad monetization and a smooth viewing experience, enhanced with OMID and Analytics integrations for effective workflow optimization. Overall, SSAI remains a potent tool for content providers to monetize their video streaming workflows and maximize revenue potential.
If you’d like to see how Bitmovin’s solution stack can benefit your streaming workflow – sign up for our 30-day free trial.
