A/B watermarking is a two-step watermarking process which is performed within the service provider’s facilities in the head-end or in the distribution network. Here, two variants, called A and B variants, of each streaming session are generated which receive a different watermark. These streams are then broken up into segments which are ultimately combined to form a single stream with a unique combination of A and B segments. This ensures that no two subscribers of an OTT service receive the same sequence.
Each video source is encoded twice and distributed simultaneously which means two sets of encoders and sufficient storage and origination resources are needed to accommodate the two streams. Due to this dual stream approach, A/B variant video watermarking is a resource-intensive process. It requires the two versions of the video to be stored on the origin server and then have them traverse the CDN caching infrastructure. By design, A/B watermarking limits the insertion pace of the WMID (watermark identifier) to one bit of information per chunk. This causes latency and may not be suitable for some application uses such as live transmission of DRM protected content.
Hence, playlist manipulation through the manifest is used to restore some caching capabilities of the video delivery network and achieve good scalability with A/B video watermarking. The serialized playlists are delivered to only declare segments that encode the watermark identifier of the recipient. While consuming the playlist, the client can only request variant segments that encode the WMID associated with them regardless of the network conditions. This approach allows the A and B versions of the video stream to be cached in the video delivery network.
A streaming server that hosts all the pre-computed variant segments serves the requested variants. The requests are hence not escalated to the origin server in case the desired segments are already present in cache, thereby reducing latency. This requires playlist entries that are not templated, but have segment granularity such as HLS or DASH. The segment URIs are obfuscated in order to prevent malicious users from accessing and manipulating a playlist. The central manifest manipulation component decides which segment is to be delivered.
