Meeting the Challenges of Video Advertising in an IP ABR Environment Consumers are demanding to watch TV when they want and on the device of their choice. To meet that challenge most pay TV operators globally are deploying some IP ABR (Internet Protocol Adaptive Bit Rate) solution to provide video to devices beyond traditional set top boxes (STBs). These new IP-based multiscreen video services keep the pay TV operators competitive by enabling them to extend TV services to new screens while delivering a high quality customer experience. They also have the opportunity to open up new revenue streams for the operator via additional live and time-shifted viewing. Extending video delivery to these new devices using IP ABR technology introduces new revenue opportunities; however this new advertising environment is not without challenges. This paper will detail key considerations for providing the full set of new advertising capabilities as part of these deployments. INTRODUCTION The Challenges Extending TV beyond the traditional STB and to new IP devices seems like a trivial matter at first blush. Just transcode the feed to a web friendly format and delivery it using your favorite HTTP or streaming server, right? When it comes monetizing that stream however, and extending the $70B US advertising industry to this new format, challenges arise. How do ecosystem participants get credit for the original linear ads that are aired? There will be different local ads in different markets and zones, how does the operator replicate those local ads in the stream? Transcoding separate streams for each zone would be cost prohibitive. Can the live TV feed be captured and available for look back, catch-up and on-demand viewing? If so, what happens to the ads? Online video is usually shorter form content monetized with only pre-roll ads. How are mid-roll ads enbled to support longer form TV programming? TV programming often has inventory carriage agreements in place. How are the ad splits between the service providers and content providers in those agreements enforced?
There are also technical hurdles as well. For example, live playout introduces tight timing and signaling requirements between the encoder and the packager, while time-shifted delivery may have a long gap between the encoding and packaging step. How is this accounted for? The Scope: Live, Time-Shifted, Place-Shifted A next gen architecture designed to deliver TV services to IP devices should also contemplate doing so in a fashion which enables viewers to watch TV either live as it airs or in a viewer controlled fashion i.e, catch-up, look-back, on-demand. This adds complexity in that the advertising models may change depending on the time-window in which the content was consumed. The table below shows typical advertising monetization strategies and their relationship to when content is consumed: Monetization Models When TV programming is watched Live Viewing Time Shifted Viewing Platform Traditional Broadcast Traditional schedulebased, batch mode selling and traffic the way $75B of ads are bought today n.a. IP ABR Replication of traditional, scheduled TV buy or dynamically inserted nonlinear (digital) addressable ads Replication of traditional scheduled TV buy for short period of time (e.g., 3 days); dynamically inserted non-linear (digital) addressable ads afterwards In order to extend reach of the ads delivered in traditional TV programming, the ad platform for IP ABR platforms needs to provide pay TV providers with two core capabilities: Replicate their existing traditional ads into the stream Serve up new, addressable ads into the stream The requirement to replicate existing traditional ads into a stream adds a lot of complexity that isn t found in typical broadband ad servers and systems. Because transcoding the stream in each zone is too cost prohibitive, this is most effectively done by transcoding just one stream then using Dynamic Ad Insertion (DAI) to replicate the original linear schedule in each ad zone or market. This means the IP ABR ad solution must apply existing legacy linear traffic instructions and translate them into instructions the transcoder/encoder and packager can understand. Furthermore, the Live Viewing scenario has tight timing requirements. All the decision steps must be accomplished in near real time. The time shifted column has more 2012 BlackArrow, Inc. 2
relaxed requirements, but advertisers benefit from these steps being done as close to the event as possible. In addition, IP ABR ad systems need to contemplate reusing the linear stream for time shifted TV purposes. Over the last decade, a number of countries have adjusted TV ad buys to go beyond live play to some window of time-shifted viewing that replicates the live ad schedule. In the US, for example, the window is 72 hours and called C3 (for the three days of time-shifted commercials that apply to the linear buy). This means that the ad payload and ads within a time-shifted program will change over time, and is best accomplished by using a sophisticated POIS system to dynamically control how the ad loads change over time and using DAI to insert the right ads. THE SOLUTION The BlackArrow and RGB Networks Solution To meet the challenges of extending TV to new IP ABR platforms, an advertising system must provide the following capabilities: Encoding/transcoding of live and time-shifted assets, with appropriate stream conditioning to ensure that ad and ABR-segment boundaries are aligned, Capture of ad break point metadata, Real time inventory policy management, Real time targeting information including potentially federating multiple sources to include asset, device, audience, geography, and other desired targeting dimensions, Real time data policy management, Real time ad decisions including potentially federating multiple ad servers, Creation of logical instructions for the packager that can include ad substitution, insertion, or deletion, Packaging these instructions for playout in multiple formats and bit rates, and Playout verification. The RGB Networks and BlackArrow integrated solution meets these requirements and provides everything necessary for a robust, dynamic, end-to-end network-centric solution that supports local and addressable advertising. 2012 BlackArrow, Inc. 3
Solution Architecture The figure below shows the logical components of the BlackArrow Advanced Advertising System and the RGB Networks AIM system and where they interoperate to insert ads in either live or time-shifted IP ABR TV programming. The RGB components handle all of the probing and processing of the physical assets that are necessary to playout a seamless and continuous stream of content and ads. This includes encoding/transcoding, packaging and manifest generation. The BlackArrow components handle the entire ad decisioning logic necessary for determining the ad payload and which ads to play. This includes determining ad payloads, inventory splits and carriage, ad policies and exclusions, and ad decisioning. The emerging CableLabs ESAM specification covers the integration between the physical and logical components. We ll consider this process in more detail below, in the rough order of event sequence. 2012 BlackArrow, Inc. 4
Encoding/Transcoding For delivering TV content through an IP ABR environment, all of the video sources both programs and ads, as well as on-demand files and/or live feeds need to be encoded into the proper formats for playout. There are a number of popular protocols today for IP ABR video delivery including Apple HTTP Live Streaming (HLS), MPEG s Dynamic Adaptive Streaming with HTTP (DASH), Microsoft Silverlight Smooth Streaming (SS) and Adobe HTTP Adaptive Streaming (HDS). The RGB portion of the solution is responsible for encoding/transcoding the video into the proper format for playout. Encoding assets for on-demand playback is relatively straightforward and not covered in detail here. The preparation of live streams for IP ABR delivery however, has added complexities that warrant further attention here. Specifically, the RGB encoder/transcoder will capture ad break points most local ad break data will be available through SCTE-35 markers and condition the content so that ad insertions at break points occur smoothly and with frame-accuracy. There is a lot of complexity here that has to happen in real-time, including: 1. Verifying whether the Placement Opportunity (PO) at the ad break will actually be used to insert an ad in or not. In some cases, an operator may choose to not insert an ad in a stream even if there is a SCTE 35 marker in the content. In that case, the content in the original feed will be passed through. 2. If an ad will be inserted into that Placement Opportunity, identifying meaningful information, such as the duration of the ad and ad insertion instructions, that will be used by downstream systems. 3. If an ad will be inserted into that Placement Opportunity, aligning the chunk boundaries of the program content with the ad boundaries and communicating that through manifest files to the player. Placement Opportunity Information Service Integration The first two steps above are carried out by the Placement Opportunity Information Service (POIS). The POIS is a key component of the BlackArrow system and it is used to determine whether or not the trigger should result in an ad placement, and if so, it will return a response that contains a signal ID and duration of the spot to the RGB encoder which will be used to condition the stream. The RGB encoder connects to the BlackArrow POIS via the ESAM Signal Confirmation and Conditioning API (SCC) interface. When a break point is signaled in the input stream, the encoder makes an ESAM request that verifies the validity of the break; the ESAM response can modify the break data, if necessary, to include expanded break information, such as: 2012 BlackArrow, Inc. 5
Global signal IDs used to identify ad opportunities across all down-stream systems Additional ad opportunities that occur at the same break point Suppression of the ad break, etc. The encoder/transcoder is also responsible for responding to and enforcing out-of-band blackout requests from the BlackArrow POIS by appropriately encoding the content and inserting new in-band metadata into the stream. This allows downstream components to validate if a blackout should be enforced. Aligning Boundaries After receiving information of a valid ad placement from the BlackArrow POIS, the RGB system needs to align chunk boundaries (step #3 above). To illustrate this process, simplified data flow for a live HLS stream is shown in the figure below. Different profile chunks are created at the output of the transcoder and these are referenced in the manifest file. As new chunks are available, the manifest file is updated to reference the latest-available chunks. In order to insert ads in this dataflow, a few things must happen: The chunk boundaries have to align with the ad boundaries. Chunk boundaries created by the transcoder must therefore be sensitive to both the ad start and the resumption of network programming at the end of the ads. The manifest files must be modified so that the references to chunks corresponding to ads are made to an HTTP ad server that can serve ad chunks. 2012 BlackArrow, Inc. 6
Packaging The packager must assemble the ad insertion instructions and associate any additional metadata with the media in order for the downstream components to make an ad decision. This may include translating logical references provided into physical references. The ESAM Manifest Confirmation and Conditioning API (MCC) covers this interface and this information flows from the BlackArrow POIS to the RGB packager. In particular, when the packager identifies an ad opportunity, it makes an ESAM call whose response allows the operator to tune the packager to include specific meta-data in its output. This allows the complete system to adapt to future client-signaling mechanisms without any modification to the packager. It also allows different operators to utilize custom signaling while using the same architecture and components. This signaling can trigger different viewing-measurement methods or other clientside behavior. The image to the right, from the CableLabs document Open Cable OC-SP-ESAM-API- D02-120702 Draft, illustrates a basic ESAM implementation. This should provide a decent high view of the interplay between the encoder /transcoder and the POIS as well as the packager (Fragmenter) and the POIS as described above. 2012 BlackArrow, Inc. 7
Ad Decisioning The next step in the process is the splicing of the actual ad into the stream. As noted above, this may include either the replication of the same ads that aired in the program on TV or it may include entirely new and different ads, depending on the monetization strategy. The BlackArrow and RGB solutions support both cases, enabling operators to extend their linear ad sales to new platforms but then switch out the ads for new ones when the originals are outside of their valid window. In either case, the process is the same. The RGB system makes an ad request call to the BlackArrow ADS via SCTE 130 to retrieve an ad. Certain information will be passed up in the request to aid the decisioning. For example, the information from the POIS that was packaged into the stream is sent up to the ADS and is used to help drive the decision of whether to reproduce the original linear ads or insert new ads. A device ID will be passed up so the system can do a subscriber information service look up to determine the appropriate ad zone. A station ID (or in the case of VOD, a program asset ID) will be passed along so a content information service look up can determine the proper network or program. Linear Replication In the US, the traffic team prepares linear insertion instructions well in advance of live airing (hours at least). The IP ABR infrastructure needs to apply these linear instructions to the new IP ABR stream. The BlackArrow solution does this by ingesting linear schedules and using that information to dynamically insert the ads that appeared in the original broadcast into the IP stream. This is done dynamically, in real-time for each viewer since the ads for viewers in different zones will be different. Addressable Insertion Addressable insertion takes the process to the next level and allows for specific, individualized ad decisions and insertion instructions for each playout stream. The addressable insertion is made based upon knowledge of the content, session, device, behavior, and other relevant factors. The BlackArrow solution does this by evaluating the campaigns that are currently available in the BlackArrow Campaign Manager/ADS or other ad servers / ADSs and returning the right ad. In either case, the BlackArrow system sends instructions about which ad(s) to play down to the RGB system. The RGB system then splices the ads into the stream and passes it to downstream playout systems. 2012 BlackArrow, Inc. 8
Integrated Measurement IP ABR ad playout provides more value when the platform views are combined with traditional TV linear measurement, for example, when merged with traditional linear QAM viewing to provide a comprehensive linear view. Combining these measures and presenting information back for billing also presents considerable challenges. Measurement can be made either in the network or via client-side signaling. Since all client delivery is unicast, the network knows which ads have been played, by whom, and when. However, network-collection of play-out data presents a few challenges. In a distributed scenario, the ads may be served from a CDN cache, not from a central server on which access logs may be processed. It is, however, possible to process the ABR manifest requests, which drive the ad streaming and hence detail viewing statistics. Client-side metrics specify exactly which ads were viewed, but they require client-side interaction with a metric collection system which must be publically accessible and hence susceptible to unwanted potential manipulation. The complete ecosystem for reporting remains to be sorted out, with several competing systems currently under testing. Summary Ad insertion in an IP ABR scenario (both live and on-demand) requires understanding where ads can be placed, who can place them, what information they may use to make the ad decision, making an ad decision, communicating it to the packager, playing out the stream, and collecting return path information. The BlackArrow and RGB solutions together provide an end-to-end system for ad-enabling IP ABR streams for any monetization strategy. The key capabilities of the system comprise of: 1. Identify ad breaks For live/linear feeds, identification of local operator-owned inventory occurs through SCTE-35 or by some associated metadata payload. For VOD, a good alternative is to ingest a metadata file specifying break points and durations. 2. Evaluate ad breaks Identify the duration of the break. 3. Identify inventory Identify the inventory structure associated with the break. This can be as simple as the break duration or the break can be partitioned and allocated across multiple inventory owners. Additionally, metadata associated with companion inventory can also be generated here. In advanced cases, this can include knowledge of the ads in the source broadcast. 4. Identify inventory owners Allocate inventory to owners. 5. Collect session information Capture available session data. This can include metadata on content, household, viewer, geography, device, behavior, history, and more. 2012 BlackArrow, Inc. 9
6. Notify inventory owners of ad opportunities Each ad owner needs to know what decisions they must make and what information is available to make that decision. Opportunities and data must be routed to each inventory owner in real time. The Pay TV operator shares information with inventory owners based upon data sharing agreements and policies in place. 7. Make ad decisions All inventory owners make ad decisions for their inventory. In the event that an inventory owner does not return a valid decision, take the appropriate action. 8. Assemble logical playlist Consolidate ad decisions for use by the packager. 9. Communicate desired ad break information to encoder/transcoder Send instructions for ad break metadata to the encoder/transcoder which will appropriately modify encoding and insert the ad break metadata. 10. Communicate ad decisions to packager Send instructions to the packager. 11. (Advanced) Send parallel companion decisions to other companion devices. 12. Playout packager executes instructions. 13. Receive confirmation of ad play The packager logs results. In some architectures the playout device can also return logs on a sample panel or census basis. All of these steps occur in both live and time-shifted playout, but the timing requirements are much stricter for live. With the delivery of video to multiple screens growing rapidly, pay TV operators need the capabilities listed above to be available for all of their TV platforms. BlackArrow and RGB Networks have worked together to integrate their solutions and streamline the deployment process. With this solution in place, operators can see substantial revenue returns as they evolve their networks to meet the changing needs of their subscribers. 2012 BlackArrow, Inc. 10