AWS for M&E Blog
Combining dynamic ad insertion and A/B watermarking
For video service providers, delivering a personalized ad experience with A/B forensic watermarking can create interoperability challenges because both require dynamic manipulation of the manifest used for playback. In this blog post, we explore this potential conflict and recommend a system architecture that delivers a personalized ad experience along with A/B watermarking so that you can maintain a high-quality viewing experience.
In the past, the technology used to process and deliver content for over-the-top (OTT) video streaming services was designed to support static, pre-configured video-on-demand (VOD) or linear content streams. The entire content delivery pipeline focused on hierarchical caching of the same common global video content, delivered in popular formats such as HLS or DASH, to all viewers and devices. This provided all viewers with the same cached content from the content delivery network (CDN), at the best quality and lowest latency, in a format consistent with the viewer’s device.
Today, everything has changed: video streaming services now deliver individualized and personalized video content to viewers. The two main types of personalized video streams are:
- Personalized advertisements—The dynamic server-side insertion of personalized ads based on variables such as the viewer’s location or profile.
- Forensic watermarking—The server-side insertion of an A/B forensic watermark used to identify the viewer’s identity for anti-piracy purposes and disrupt the stream when a leak is detected.
When delivering live and VOD content, today’s video streaming services need to manage the interoperability of these two features without diminishing the low latency that is typical of video delivery from the CDN, and without requiring specific integration with each device type and player.
Achieving this helps services to combine monetization capabilities with anti-piracy security protection, without degrading the user experience or adding client development.
The challenges of combining A/B Watermarking with dynamic ad insertion
Unfortunately, server-side watermarking—often referred to as A/B watermarking—and server-side ad insertion (SSAI) are prone to conflict.
To facilitate server-side watermarking, a video platform incorporates a watermark token. This token encodes the unique watermark ID (WMID) assigned to the household to the playback URL of the video asset requested. Because both the DASH and HLS protocol use relative URLs, the watermark token is naturally propagated in subsequent requests of the player to the CDN. This provides the CDN with the ability to enforce A/B sequencing logic without any client development. Depending on the WMID of the end-user requesting a video segment, the CDN delivers either variant A or variant B of the requested segment.
To facilitate dynamic ad insertion (DAI), the playback URLs of the ad and video segments are typically rewritten by a DAI manifest manipulator. Depending on the rewriting logic of the manifest manipulator, the DAI technology might discard the personalized watermark token and thereby negate the forensic watermarking capability.
In such a case, a service operator would face the unhappy dilemma of dropping either forensic watermarking or dynamic advertisements—one is a powerful tool for protecting your business; the other, a tool for growing it. This is not a choice any operator should need to make.
Baseline for an interoperable blueprint
The interoperability between A/B watermarking and DAI stems primarily from the ability of the video delivery system to successfully achieve two things:
- Handle session-specific elements present in requests coming from the client
- Piggyback these session-specific elements in rewritten manifests for video segments, but not for ads
The following illustration shows how such synergy can be achieved in a generic reference solution.
Figure 1: Achieving A/B watermarking and DAI interoperability illustrated. The different colors indicate that different technical stakeholders might oversee each individual component. For simplicity, the playlist acquisition is abstracted to a single transaction. In practice, there are several exchanges to obtain the primary and media playlists from the manifest manipulator.
Let’s walk through each step to see how interoperability can be achieved.
First, the client requests the playback URL for the desired asset from the video platform. If authorized, the video platform returns the requested URL that includes a watermark token. In the previous example, the watermark token wmk_token has been incorporated to the virtual path so that subsequent requests naturally contain the token given the relative addressing convention of the HLS and DASH protocols. Note that it is feasible to incorporate the watermark in another carrier, for example as a query parameter or header. Nevertheless, such alternatives require client integration or collaboration from other entities to preserve the watermark token throughout the playback session, which is not desirable in view of our goal to be client-agnostic.
The client then initiates the watermark and personalized advertisement session by requesting the playback URL from the CDN. The client can incorporate additional parameters in the request such as the user profile used by the DAI platform to personalize the ads delivered. The CDN is configured to strip the watermark token and redirect manifest/playlist requests to the manifest manipulator, as well as the ad segment requests. On the other hand, video segment requests are redirected to the origin. Having a CDN proxy facilitates a transparent failsafe mechanism. This means if the DAI manifest manipulator becomes unresponsive, the CDN might go directly to the origin to fetch the manifest/playlist to avoid the viewer seeing a black screen.
Because the watermark token is stripped at the CDN level, the DAI manifest manipulator remains completely unaware of its existence and operates as usual. When receiving a request for a playlist/manifest, it fetches the playlist/manifest from the origin. As shown in the previous diagram, the query is issued directly to the origin for the sake of simplicity. However, it is common practice to go back to the CDN to shield the origin from the potential of numerous requests. Ideally, the path to the origin is part of the incoming request to avoid static configurations of the DAI system. Ignoring primary playlist requests, the manifest manipulator then interacts with the DAI ad decision engine to obtain the recommended ads.
Finally, the manifest manipulator rewrites the playlist/manifest to incorporate the personalized ad segments. A fundamental interoperability assumption of this blueprint is that the manifest manipulator preserves the HLS/DASH relative URLs of the video segment. Alternate solutions exist for DAI systems that would rewrite full URLs. However, they require additional collaboration from either the manifest manipulator or the CDN to guarantee the propagation of the watermark token throughout the playback session.
Thanks to the preservation of the relative HLS/DASH addressing convention, when the client issues a request for a video segment, it propagates the watermark token assigned to this client. The edge can therefore apply the A/B sequencing logic to infer which A/B variant to deliver. As depicted in the previous illustration, this logic typically involves:
- Parsing the video segment filename to extract a segment number,
- Deriving which WMID bit is associated to the segment number,
- Looking up the value of this bit in the WMID present in the watermark token, and
- Delivering the A (resp. B) variant if it is a 0 (resp. 1).
For ad segments, the request does not contain the watermark token and is redirected by the CDN to the ad delivery platform. In the previous figure, the manifest manipulator is proxying the ad segment requests to collect information and collate ad impressions reports. Alternate architectures might go directly from the CDN to the ad delivery platform—for instance, when ad tracking and reporting is managed on the client side.
How AWS Elemental MediaTailor provides native support for A/B watermarking
A suite of services from Amazon Web Services (AWS) provides support for A/B watermarking. AWS Elemental MediaTailor (MediaTailor) is a managed manifest manipulator that performs server-side ad insertion. To begin with, a service operator creates a MediaTailor configuration that comprises the following parameters:
- A unique identifier (mt-config-id) that will be used to identify this specific MediaTailor configuration,
- The URL prefix (http://myorigin.com) where the DASH manifest of the HLS playlist for the video stream can be acquired, and
- The URL (http://myads.com) of the ad decision server.
Besides the definition of the different endpoints, MediaTailor configuration might include optional parameters to refine the expected behavior of the manifest manipulator. Of particular interest is the parameter ContentSegmentUrlPrefix: it provides the means to modify the default behavior of MediaTailor when rewriting the URLs of only the video segments in a playlist or manifest. This mechanism will prove hugely valuable in achieving interoperability with A/B watermarking.
In HLS, the first request to reach MediaTailor for a playback session is expected to be formatted as follows:
where hashed-account-id is the AWS account of the service provider and mt-config-id refers to the previous configuration. The parameter hls-subpath reflects the folder hierarchy at the origin. The query parameters prefixed by ads are intended for the DAI ad decision service. This template does not accommodate for any tampering prior to /v1/. This is why it is instrumental that the CDN strips the watermark token present in the URL to avoid impairing the behavior of MediaTailor.
The manipulated primary playlist returned by MediaTailor typically looks like the following:
The relative ../../../ prefix sandboxes the subsequent requests after the /v1/ element in the original query. If the watermark token is incorporated before this element, it will be naturally incorporated into subsequent requests. One can see that MediaTailor does not piggyback the query parameters that might have been present in the original query. That is why a session-id is dynamically created to store the ads prefixed query parameters, as well as the hls-subpath and other parameters that will be needed to reply to subsequent queries of this playback session.
The media playlist returned by MediaTailor looks like the following:
At first sight, the fact that MediaTailor rewrites absolute URLs seems to preclude interoperability with A/B watermarking because it does not propagate the watermark token. However, thanks to the parameter ContentSegmentUrlPrefix mentioned earlier, it is possible to modify the default behavior of MediaTailor. Setting this parameter to ../../../../../ (five directory levels) allows for keeping relative paths, thereby naturally propagating the watermark token present in the query.
For DASH, the mechanics of MediaTailor remain fairly the same, except that the parameter ContentSegmentUrlPrefix shall be set to ../../../../ (four directory levels) due to a slightly different sandboxing convention. It is also worth mentioning that MediaTailor may issue a redirect upon the first manifest query when it is responsible for ad tracking, often referred to as server-side ad beaconing.
This redirect response uses an absolute URL which in effect discards the watermark token for the remainder of the playback session if nothing is done. It is therefore necessary to change the behavior of the CDN edge to amend the location redirect URL prior to forwarding the response to the client. A simple way of achieving the propagation of the watermark token is to prefix the location redirect URL with as many ../ levels as required—for example 4 levels if dash-subpath is empty. For instance, in Amazon CloudFront—a CDN service built for high performance, security, and developer convenience—it can be achieved with a minimalistic viewer response CloudFront Function.
Synamedia EverGuard watermarking and AWS Elemental MediaTailor
Although AWS Elemental MediaTailor features a few static parameters, it provides mechanisms to propagate third-party session specific elements present in the URLs throughout the playback session. This capability is instrumental in facilitating interoperability with established A/B watermarking systems like Synamedia EverGuard.
Using the blueprint outlined above, the service operator can configure the components of the video delivery system to facilitate seamless propagation of the Synamedia watermark token within the video segment URLs of MediaTailor manipulated playlists/manifests.
Even with server-side ad insertion, each video segment URL requested by the client still includes the watermark token and can be sequenced as either an A or B segment, depending on the unique identifier present in the watermark token. The temporal sequence of watermarked video segments determines, for each user, the full WMID of that household, and is thus a critical element of any anti-piracy solution.
The blueprint described above illustrates yet another Synamedia-AWS synergy: MediaTailor for DAI manifest manipulation and Synamedia EverGuard for A/B Watermarking.
The best of all worlds
It is worth highlighting that this architecture is generic in that it does not require modifications to the client device or browser, nor does it depend on any CDN provider or DAI service vendor. This solution proves that it is feasible to achieve the best of all worlds:
- Preserving full monetization from personalized, dynamically inserted advertisements
- Facilitating premium anti-piracy security with A/B forensic watermarking from solutions like Synamedia EverGuard
- Maintaining a top-quality user experience when viewing personalized and protected linear and VOD video
CDN behavior with A/B watermarking is in the process of being standardized in the DASH-IF Content Protection and Security Task Force. Standardization is important so that there is a common method for propagating the watermark token throughout a playback session. In the meantime, this article described the challenges that standardization will overcome and proposed a proven architecture that Synamedia and AWS jointly developed and tested with great success.
To learn more about A/B watermarking or dynamic ad insertion, visit Synamedia EverGuard or AWS Elemental MediaTailor.