Linear Multiscreen is focused on delivering linear TV services to connected devices, using HTTP as the delivery method. As such, the TV services are copies of the traditional TV services, with the same programming and, most importantly in this context, the same adverts.

However, HTTP is a point-to-point unicast protocol, as opposed to a broadcast protocol. As such, the delivery system is aware of, and must manage, every connected user on an individual basis. While this adds complexity (which is managed via content delivery networks) it also means content decisions can be taken on an individual user basis.

Dynamic Targeted Advertising therefore focuses on changing the adverts each user sees. For simplicity, users can be grouped into demographic or regional groupings, but if desired the decision about which advert to show can be made individually. It is very easy to make these individualised decisions because in order to deliver linear video over an HTTP network, the content is already divided into small chunks called segments. Each segment has a unique URL, and the list of URLs is defined in a manifest file. By conditioning the video encoding so that segment boundaries align with the start and end point of an advert or group of adverts, replacing an advert is simply a case of rewriting the manifest file for each user, so that old content is replaced with targeted content. Alternative approaches use client-side advert overlays, in which a second instance of the device’s media player is launched and adverts overlaid on the original content. It is difficult to precisely time this, resulting in a clunky experience. In addition, it is easier for users to override the playback of the adverts, so it is less reliable for advertisers.

2. Workflow

The following diagram illustrates the workflow for multiscreen targeted advertising. It is split into two sections, with the red arrows indicating the non-live part of the process, and the blue arrows indicating the live part. Essentially the non-live part of the process is focused on managing adverts, and the live part on managing advert slots. The bridge between the two parts marries advert slots with actual adverts.

2.1 Non-Live

Advertisers who wish to buy advertising slots must provide both the advert creatives and the metadata that controls the campaign.

2.1.1 Advert Creatives

These are a set of media files that contain the actual video content of the advert. Note that a given campaign might feature several versions of the same advert, or several related adverts. For example, a car company might mount a campaign promoting a finance package, and therefore offer a different video for each car in the range. Alternatively, the advertiser may offer different videos for the same advert, to be used in different contexts. For example, the car company might want to promote high-end features during an upmarket program, and value-oriented features in a more mainstream program.

The adverts are typically supplied as a single file per advert, i.e. in a format not yet suitable for delivery using HTTP adaptive streaming. As a result, they need to be transcoded and segmented before they can be used, which requires an offline file-to-file transcoding step. Once the transcoding is complete, but before the prepared asset can be used in the linear part of the workflow, it must be ingested into an asset database. This allows a translation to be made between the media files provided by the advertiser and the transcoded files prepared for the linear network.

An existing CMS can be used for this function, but to install a full-fledged CMS just for managing adverts (given there are typically only a small number of adverts to manage at any one time, whereas CMS systems are scaled for thousands of adverts) would be over-kill. Hence a smallscale CMS focused just on adverts is needed in systems with no pre-existing CMS

2.1.2 Campaign Metadata

Along with the actual adverts, the advertiser will want to be able to define metadata controlling the campaign, such as how many slots to buy, when to use the slots, and targeting information (target audience demographics, target time slots etc).

2.2 Live

In the live part of the workflow, the operator receives TV services along with metadata to mark available advertising slots. The metadata might be supplied in-band, via SCTE35 messages, or out of band. If the out of band method is used, then an interface known as ESAM is used to push the metadata into the transcoder.

The final streams with advertising markers are then processed by the linear compression headend before being pushed onto the delivery network. The delivery network is aware of individual user connections and hence user-specific decisions can be made on which adverts to use to replace the available slots.

2.3 Bridging the Workflows

A complete use-case obviously needs the workflows to connect at some point, so that advert slots in the live side can be filled with adverts from the non-live side. This bridge is implemented via industry-standard interfaces, with the two most common being SCTE-130 and VAST. Both interfaces allow the live part to pass details of an advert slot to the non-live part, and for the non-live part to respond with a decision as to which advert to show.

3. Concepts

This section explores in more detail the concepts introduced in the workflow overview above.

3.1 Insertion vs. Replacement

The focus of this document is advertising replacement. In other words, the source stream already contains adverts. The multiscreen targeted advertising system is designed to replace those with adverts specific to the multiscreen network. Given there are already adverts in the stream, the issues that motivate operators to want to replace those adverts must be explored.

Fundamentally, advertisers pay for reach and engagement. Reach relates to how many people actually watch a given advert, whereas engagement is how many people are actively interested in the advert.

Re-using on the multiscreen network the adverts already in the stream can be an easy way to increase reach. However, this assumes that multiscreen drives additional audiences, as opposed to simply spreading the same audience over a broader set of devices. For example, if multiscreen allows a household to watch more than one channel at a time, then this increases reach. However, if a user watches content on a multiscreen device because it is more convenient (e.g. an easy way to get television in the kitchen), then this does not increase reach.

Targeting the adverts, however, increases engagement. An advert that is not relevant to a user is subconsciously filtered, and although much linear TV has a target demographic this is far from 100% accurate. This means much of the advert’s reach is not actively engaged in the advert. Targeting significantly improves this, and as a result operators are willing to pay more for targeted slots.

The motivation therefore for operators to replace adverts is because targeted slots have better engagement levels and hence are more valuable. Re-selling slots as multiscreen-only therefore drives increased revenues.

The alternative to replacement is insertion. Adverts can be inserted before the stream starts, in the middle or at the end – these are known as pre-, mid- and post-roll respectively. Post-roll has little value because there is little motivation to the user to watch the advert. Mid-roll is not applicable in a linear context, because it is impossible to insert additional adverts into a stream without the multiscreen version becoming ever further time delayed in comparison to the nonmultiscreen version.

Pre-roll is of interest however. In many situations, the operator may not have the rights or the infrastructure (i.e. metadata showing where replaceable adverts are in the stream) to replace adverts, and pre-roll offers a set of advert slots that are purely controlled by the operator. Using pre-roll need not be an either/or decision vs. mid-roll. Many internet video services, such as YouTube, already use pre-roll, meaning users are conditioned to them. Therefore even operators who are deploying advert replacement may also be interested in advert insertion as a way of generating additional revenues (for example, the operator can offer upgrade to a premium package that removes pre-rolls).

3.2 Marking Advert Slots

In order to be able to replace an advert, the advertising system needs to know where it is in the stream. There are two main approaches – in-band and out-of-band.

In-band works by embedding metadata in the linear stream itself that identifies the start and end timestamps of the advert. The main technology for achieving this is called SCTE35, which is a US technology by origin. Using SCTE35 results in a simplified workflow in comparison to out-of-band approaches, but relies on the upstream programmer having the infrastructure. This is relatively commonplace in the US, but much rarer outside of that market. The alternative therefore is out-of-band. Typically this is achieved by obtaining metadata from the programmer’s playout automation server, which can then be passed in to the multiscreen transcoder using an interface called ESAM.

Multiscreen targeted advertising replacement relies on one of these two methods being available. Advertising insertion can be done without either of these, which typically makes it a simpler launch pad for many first-generation targeted advertising systems.

3.3 Stream Conditioning

Advert replacement in multiscreen is implemented simply by replacing the ABR segments that relate to the advert. This is far simpler than the stream splicing approaches that must be used in the non-multiscreen world. However, it relies on the segment boundaries coinciding exactly with the start and end of the advert. Given segment boundaries have a regular cadence, this is unlikely to happen by coincidence.

Instead the multiscreen transcoding must condition the stream around the advert, by forcing the insertion of an unplanned segment boundary. This results in variable length segments, which is acceptable as long as the modified segments are the same length or shorter than the original segment length. Longer segments are tolerated, but much less variation is allowed. The issue here is that devices allocate a certain amount of buffer memory, and longer segments can easily overflow that buffer.

The transcoder must also manage advert boundaries following very soon after a planned segment boundary (at the start of an advert) or preceding very closely a planned segment boundary (at the end of an advert). This is because very short segments (only a few frames) are inefficient to package and can also affect decoder buffering.

In the above diagram, the orange part indicates standard multiscreen transcoding, resulting in a series of equal-length segments, all of which occur at planned intervals. The green diagram, in contrast, illustrates the effect of adding in advert boundaries, with the blue

3.4 Template Manifest

The transcoder and segmenter exist in a part of the workflow that isn’t aware of individual user connections – that awareness comes later, inside the delivery network. As a result, the segmenter/packager is not able to actually write the final end-user manifest. Instead, it must write a manifest containing the original segments, but then mark up those segments that are to be replaced. This is called a template manifest.

The template manifest is ingested into the delivery network, which can make user-specific decisions about the adverts to use to replace advert slots.

3.5 Manifest Re-writing

Once into the delivery network, it is possible to start making user-specific decisions about the content of the manifest file. Note this does not mean that adverts have to be targeted at individual users – only that decisions can be made at a user level if needed. It is common to group users together to simplify advert decisions. The great benefit with multiscreen is that those groupings can be dynamic, and are not constrained by the architecture of the network (advert targeting in, for example, cable networks is tied into how the network architecture aggregates users into regions).

In order to fill an advert slot, the network must detect advert slots in the template manifest file. It must then make a call into the non-live part of the workflow in order to get an advert decision – this is described more fully in the following section. Finally, the result of the decision must be written into a new manifest file, as summarised in the following diagram:

Here the template manifest can be seen on the left, containing the original segments. On the right is a new manifest for one particular user (or user group) in which the segments (highlighted in orange) surrounded by the Cue Out and Cue In tags have been replaced by new segments.

3.6 Advert Decision Call-Out

When the manifest rewriting step in the workflow detects an advert replacement opportunity, something in the system needs to decide which advert to use to fill the slot. In order to do this, the manifest rewriter needs to make a call out to the campaign management suite.

There are two main APIs for this task, SCTE-130 and VAST. MostMedia’s advertising solution supports both. SCTE-130 is most commonly used when the Campaign Management suite is operator owned and controlled.

VAST is an IAB (Internet Advertising Bureau) standard, and is most commonly associated with banner adverts on web pages. Web sites can make call outs to external advertising agencies in order to retrieve banner adverts – this makes web site advertising scalable even for small, independent web sites that don’t have the scale to run their own advertising sales operation. By using an external agency, web sites can effectively pool their resources to find scale.

These external agencies also provide video-based adverts. Hence when using an external agency, VAST is the most common call out interface.

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-TARGETDURATION:11

#EXT-X-MEDIA-SEQUENCE:12

#EXT-X-CUE-OUT:DURATION=0,ID=2913840557

#EXTINF:6.6,

20120328T122641-01-12.ts

#EXTINF:10,

20120328T122641-01-13.tss

#EXTINF:6.56,

20120328T122641-01-14.ts

#EXT-X-CUE-IN:ID=2913840557

#EXTINF:3.44,

20120328T122641-01-15.ts

#EXTINF:10,

20120328T122641-01-16.ts

#EXTINF:10,

20120328T122641-01-17.ts

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-TARGETDURATION:11

#EXT-X-MEDIA-SEQUENCE:12

#EXT-X-CUE-OUT:DURATION=0,ID=2913840557

3.7 Filling Advert Slots

A generalised commercial break consists of a set of adverts lasting a few minutes, with a mixture of advert lengths. When replacing those adverts for new, multiscreen-specific adverts, a number of strategies are possible. The choice of strategy depends on how adverts are marked in the stream, and whether the multiscreen advertising approach is to replace all or just some of the adverts in each commercial break.

Two models are possible:

Like-for-Like

This model assumes the start and end of every advert is individually marked, as opposed to justthe start and end of the whole advert break. In this case, the system will see a sequence of advertslots, e.g. 15 seconds followed by 30 seconds, followed by another 15 seconds and finally a 60second. Hence individual requests can be made to the campaign management suite, asking for adverts of a specific length.

Whole Advert Break

Sometimes only the start and end of the advert break are marked. In this case, an iterative approach is needed. The system requests the first advert from the campaign management suite, leaving a reduced amount of time to fill. A second request is made, followed by a third request and so on, until the end of the ad break is reached.

Therefore the sequence of advert timings will change – e.g. the original 15, 30, 15, 60 example might be replaced with a 60 and two 30 second adverts.

3.8 REPORTING

In order to fulfil contracts with advertisers, any system for advert insertion or replacement needs to be able to track which adverts were viewed.

The approach is different for VAST vs SCTE130-based workflows. In VAST, the response contains a tracking URL which works as a call-back. The advertising system can be configured to specify where to find this URL (it will be different for different VAST providers) and call back to the URL when the advert is played.

In SCTE130 workflows, an XML structure called a Placement Status Notification (PSN) is issued with each ad response. The PSN structure is then returned to the campaign management suite when the advert is played, closing the loop and allowing the suite to collate reporting data.

In general, the system makes advert requests in response to seeing an advert slot. The advert slot is seen because an updated manifest file is about to be generated for a given user, and the next segment to be played has been marked as being available for replacement or insertion. In this case, the advert is played as soon as it its first segment is inserted into the manifest file. Given the turnaround time for reporting call backs will be very short in this case, it is reasonable to ask why reporting is needed at all.

Two use-cases need to be covered. The first one is longer adverts, e.g. 30 or 60 seconds. These will typically span multiple segments, and hence playing the first advert does not mean the user will finish the advert. Hence reporting can be delayed until the end of the advert to be totally sure the user has viewed the advert.

The second use-case covers when the system makes a series of consecutive adverts. Typically these will be requested in one SCTE130 or VAST call out, meaning although playing the first segment of the first advert means the system can be reasonably sure the user will view that advert, that probability decreases throughout the advert sequence. Hence it is necessary to respond to each advert individually.

CONCLUSION

The technologies described here enable operators to capitalise on the key advantages of HTTP Adaptive Bitrate as a delivery technology. The implicit point to point nature of the technology can finally enable truly personalised advertising.

The technology also has applications beyond advertising. Manifest manipulation and stream conditioning can be used to solve other challenges, and also provide additional routes to monetisation.

For example, many linear programs are not licensed for multiscreen delivery, and current solutions force blackout to static images. The technologies described here, however, allow blackout to alternative video content, such as VOD or catch-up TV. Thus the EPG schedule moves away from being a fixed entity, constant across all users, and instead becomes dynamic and personalised.