Sold on SSAI
Anatomy of ad insertion Insertion markers: adverts are rarely hard-coded into a programme’s source video. Instead, the video includes markers that indicate where advertising can be placed. A special splicing marker is inserted into the compressed video information to signal the start and stop points for an ad break, based on a standard called SCTE 35. These markers are designed to be preserved through each successive step in the video processing workflow and enable frame-accurate splicing between video stream sources and ad material. Adaptive Bitrate (ABR) Streaming: ABR divides actual video stream into a series of short segments described by a distinct manifest file. Each segment is complete in itself and made available in a range of bit rates to create different segment file sizes. The consumer’s video player’s actions are driven by interpretation of the manifest file and the relationship of available video delivery bandwidth to the bit rates of the video segments. The power of this approach comes from the additional information that can be included in the manifest file, opening the possibility for playing alternative video segments at the insertion markers – and without breaking the integrity of the video rendering. Ad decisioning: the video stream’s insertion markers become the triggers to not only insert ad content, but evaluate what content should be inserted. This evaluation role is designated to a service external to the video processing architecture, known as an Ad Decision Server (ADS). The ad insertion marker initiates a protocol exchange defined by a standard known as video ad serving template (VAST). This is complemented by the video multiple ad playlist (VMAP), and the video player ad-serving interface definition (VPAID) protocol. These ad serving protocols are all maintained and published by the Interactive Advertising Bureau (IAB). When an insertion mark is detected in the stream, available client information is sent to the ADS to determine which ad to insert. Parameters used for ad selection could be as basic as the location of the requesting device, determined by its IP address, or could be far more detailed and personalised if the viewer happens to be signed in on a client device or has prior tracked web activity. The ADS responds with the ad information and with tracking beacons for reporting ad impressions. Cloud DVR and Trick Play: audiences expect advanced features from OTT providers, including time-shifted, start-over and catch-up TV. This offers advertisers prolonged content availability and opportunities to refresh targeted advertising so ads remain relevant. An ad for a promotion that ends on a specific day of the month, for example, runs the risk of becoming irrelevant. It is important that video operators have the ability to replace this specific ad when the new month starts, to ensure relevance and to continue generating revenue. Delivery reporting: the business end of digital advertising depends upon counting ‘impressions’, discrete consumer views reported from the client to the player. If there is no way to positively confirm that an advertisement has been played on a specific device, then no money is due from the advertiser to the service provider. In fact, the more detail that can be collected on the viewing profile of a given advert, the more potential value the impression will command. Reporting mechanisms depend on beacons generated in the video playback process that indicate partial or completed viewing of the advert. The triggers for the beacons are part of the data inserted into the stream by the ADS. The beacon process is designed to be transparent to actual video viewing. CSAI to SSAI Initial implementations of targeted advertising were built substantially around client player functionality. This is client-side ad insertion (CSAI). Incentives to adopt this approach were the increasing sophistication of client video players, the scalability of the solution and the potential for enhanced interactivity. More recently, video services have shifted their focus to added functionality in server-side subsystems – often cloud-based. The impact of this change on advertising is a new consideration of the merits of server-side ad insertion (SSAI). Unlike the CSAI model, in SSAI the call to the ADS is done upstream of the CDN and delivery to the client. The ADS call is triggered by the same ad insertion markers, but these markers are detected by the server-side video pipeline. SSAI processing creates a single, packaged stream that contains program and advertising content deliverable to clients, with each client seeing a personalised manifest file. This format simplifies the requirements of the player at the target device, which enables lighter-weight apps and reduced demands on web players. This, in turn, means a service can be deployed faster because there is no need to develop and maintain player technology for each and every platform and operating system. Typically for SSAI, it becomes the responsibility of the video service to create the reporting and metrics on delivered advertising. There are some nuances to this in individual implementations, but overall the approach can prove less vulnerable to ad blocking. SSAI workflow Amazon Web Services provides support for complete ad insertion workflows. For SSAI, AWS Elemental processes content for delivery in a mezzanine format. At this stage, the source video should have the SCTE 35 ad insertion markers added by the source content provider embedded in the feed. If it does not, these insertion markers can be programmatically inserted at this stage by AWS Elemental using an API interface. The compressed mezzanine stream is sent to AWS Elemental MediaLive, which compresses the live video to the adaptive bitrate streams designed to play back on client devices. MediaLive uses ad cue markers to ensure the output streams have manifests that retain the start and end of the potential ad breaks. MediaLive uses the ad cue markers to put an instantaneous decoder refresh (IDR) frame into the encoded output after the ad break is complete, so audiences get a broadcast-like experience when streams switch between ad and primary content. The ABR-encoded streams and the manifest with ad markers are published to AWS Elemental MediaPackage, a just-in-time packaging and origination service that prepares video for delivery over the internet. AWS Elemental MediaPackage creates a templated manifest for the personalisation and monetisation service, AWS Elemental MediaTailor. These templated manifests include discontinuity tags at the start of ad breaks to identify start and duration of the potential insertion. AWS Elemental MediaTailor is then brought into the workflow as the origin point for the personalised manifests, receiving targeted information from a client device at each ad break, which it uses to make a request to an ADS. The ADS responds with the ad selection for that particular viewer at that time, as well as information tracking how impressions will be measured and reported for that ad insertion. The ADS response includes a reference to a high-quality mezzanine version of the ad that MediaTailor can use as a source to transcode to ABR segments that match the format, resolution and bit rate of the viewer’s primary content. This ensures audiences don’t see any jarring transitions in quality or aspect ratio when switching to and from ad content. Pointers to the compressed ad content are stitched into the final manifest file. Even though the ad segments are not originated from AWS Elemental MediaPackage, like the primary content stream, they are delivered using the same CDN host names. MediaTailor ensures the manifest contains both content and ad video references that are structured in the same way and play back without buffering discontinuities. Reporting ad impressions is a vital part of monetisation. AWS Elemental MediaTailor offers server-side ad impression reporting by default, using Amazon CloudWatch logs and Amazon metrics to determine impressions. An API enables clients to determine where ad breaks occur and supports client-side reporting, as well as any advanced playback features, such as ad timer countdowns or disabling scrubbing for ads with on-demand content. Scaling up With its cloud-based video-streaming platform, powered by AWS and AWS Elemental, Amazon Prime Video streamed 11 NFL games to a total of 18.4 million football fans in 224 countries and territories across the globe during the 2017 NFL regular season. Fans watched the games via the Amazon Prime Video app on more than 600 types of TVs, mobile devices, game consoles, set-top boxes and connected devices. The average-minute audience (AMA) watching games for at least 30 seconds was more than 310,000, with those viewers watching an average of 63 minutes per game. Amazon Prime Video offered its own live commentary in three languages and streamed live commentary from the broadcaster in US English. Amazon Prime Video used MediaTailor to insert ads in real time, based on which region viewers were in. Amazon Video also used Amazon Kinesis as part of its infrastructure to collect quality-of-service metrics from devices worldwide. MediaTailor surfaced ad-viewing data to Amazon Video systems, which then reported the data to advertising partners. After a successful experience streaming NFL games, Amazon Prime Video streamed the inaugural Next Generation ATP Finals in November 2017 and recently launched CBS All Access, which gives Amazon Prime Video subscribers access to hundreds of live local channels across the US. BA Winston, global head of digital video playback and delivery for Amazon Video says: “We have a lot of confidence in the AWS Cloud and AWS Elemental, and we look forward to using these technologies to broaden our reach in the future.” Targeted advertising offers huge benefits over static advertising with a cost per thousand impressions valued many times greater than static advertisement. CSAI and SSAI have been deployed successfully, but the potential for SSAI to improve QoE and mitigate blocking issues makes it an attractive alternative to prior technologies.]]>
