Video Advertising in an IP ABR Environment

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
Platform
Time Shifted Viewing
Traditional
Broadcast
Traditional – schedulen.a.
based, batch mode selling
and traffic – the way $75B of
ads are bought today
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-APID02-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