Video: Understanding the World of Ad Tech

Advertising has been the mainstay of TV for many years. Like it or loathe it, ad-support VoD (AVoD) delivers free to watch services that open up content to a much wider range of people than otherwise possible just like ad-supported broadcast TV. Even people who can afford subscriptions have a limit to the number of services they will subscribe to. Having an AVoD offering means you can draw people in and if you also have SVoD, there’s a path to convince them to sign up.

To look at where ad tech is today and what problems still exist, Streaming Media contributing editor Nadine Krefetz has brought together Byron Saltysiak from WarnerMedia, Verizon Media’s Roy Firestone, CBS Interactive’s Jarred Wilichinksy and Newsy’s Tony Brown to share their daily experience of working with OTT ad tech.

 

 

Nadine is quick to ask the panel what they feel the weakest link is in ad tech. ‘Scaling up’ answered Jarred who’s seen from massive events how quickly parts of the ad ecosystem fail when millions of people need an ad break at the same time. Bryon adds that with the demise of flash came the loss of an abstraction layer. Now, each platform has to be targetted directly leading to a lot of complexity. Previously, as long as you got flash right, it would work on all platforms. Lastly, redundancy came up as a weakness. Linked to Jarred’s point about the inability to scale easily, the panel’s consensus is they are far off broadcast’s five-nines uptime targets. In some ways, this is to be expected as IT is a more fragmented, faster-moving market than consumer TVs making it all the harder to keep up and match the changing patterns.

A number of parts of the conversation centred around ad tech as an ecosystem. This is a benefit and a drawback. Working in an ecosystem means that as much as the streaming provider wants to invest in bolstering their own service to make it able to cope with millions upon millions of requests, they simply can’t control what the rest of the ecosystem does and if 2 million people all go for a break at once, it doesn’t take much for an ad provider’s servers to collapse under the weight. On the other hand, points out Byron, what is a drawback is also a strength whereby streaming has the advantage of scale which broadcasters don’t. Roy’s service delivered one hundred thousand matches last year. Byron asks how many linear channels you’d need to cover that many.

Speed is a problem given that the ad auction needs to happen in the twenty seconds or so leading up to the ad being shown to the viewer. With so many players, things can go wrong starting off simply with slow responses to requests. But also with ad lengths. Ad breaks are built around 15 seconds segments so it’s difficult when companies want 6 or 11 seconds and it’s particularly bad when five 6-second ads are scheduled for a break: “no-one wants to see that.”

Jarred laments that despite the standards and guidelines available that “it’s still the wild west” when it comes to ad quality and loudness where viewers are the ones bearing the brunt of these mismatched practices.

Nadine asks about privacy regulations that are increasingly reducing the access advertisers have to viewer data. Byron points out that they do in some way need a way to identify a user such that they avoid showing them the same ad all the time. It turns out that registered/subscribed users can be tracked under some regulations so there’s a big push to have people sign up.

Other questions covered by the panel include QA processes, the need for more automation in QA, how to go about starting your own service, dealing with Roku boxes and how to deal with AVoD downloaded files which, when brought online, need to update the ad servers about which ads were watched.

Watch now!
Speakers

Tony Brown Tony Brown
Chief of Staff,
Newsy
Jarred Wilichinsky Jarred Wilichinsky
SVP Global Video Monetization and Operations,
CBS Interactive
Byron Saltysiak Byron Saltysiak
VP of Video and Connected Devices,
WarnerMedia
Roy Firestone Roy Firestone
Principal Product Manger,
Verizon Media
Nadine Krefetz Nadine Krefetz
Contributing Editor,
Streaming Media

Video: Managing Unplanned Media Transitions in DASH Live Streaming

In live sports, a cut to or from ads can happen at a moment’s notice. Whilst not an issue for over-the-air broadcast, when you’re streaming it can be tough to get the ‘switch’ message out to the client in time. Server-side ad insertion is usually achieved by manipulating a manifest for a customer. This allows insertion of ads without having to encode the video into the programme video and allows for personalisation.

David Romrell from CommScope starts by giving an overview of how SSAI works and where players can get tripped up by going a little ahead. This talk looks at how to deal with unexpected breaks, for instance when play finishes abruptly, and for early recalls where, say, something interesting happens on pitch and the break is abandoned. There is in-band signalling of events possible within MPEG dash, but this will only work when the player hasn’t gone ahead of time so it’s not to be relied upon in this scenario.

Players can ‘go ahead’ because of the MPD (Media Presentation Description). David walks us through the anatomy of an MPD showing how it lays out a template for extrapolating the chunk name for future chunks. It also provides a heartbeat for how often the client needs to check for an updated playlist known as the MUP. This minimum update period needs to be set to balance between allowing the client some autonomy and being able to make moment-to-moment changes.

David walks through a scenario with an early return showing how a player may get confused and, at best, cause a bandwidth spike and a double hit on the CDN. At worst, the stream will rebuffer and jump. To avoid this, we see 4 options offered by David. One is to issue new periods the moment they’re known about. Even if the media list is empty, this at least signals that there’s a change coming up. This method works but the less warning there is, the less effective it is. A second idea is to ensure that ads aren’t advertised ahead of the packager which stops the player going ahead and downloading content early. The last two, we look at in more detail.

Using and @availabilityStartTime (AST) are looked at in a little more detail. The UTCTiming technique adapts the to the timing presented by the packager and pauses the ads clock which works well other than for clients which ignore this indicator. Lastly, adjusting the AST shifts the downloading times is a simplistic constant shift which doesn’t adapt to the packager rate.

David concludes saying there is plenty of flexibility for implementation in DASH, that UTCTiming or AST shift can deliver the consistent client experience we are looking for but that the lower the latency, the more severe the trade-offs in these unplanned scenarios.

Watch now!
Download the presentation
Speaker

Dave Romrell David Romrell
Engineering Fellow,
Advance Research Group,
CommScope

Video: Scalable Per-User Ad Insertion in Live OTT

Targetted ads are the most valuable ads, but making sure the right person gets the right ad is tricky, not only in deciding who to show which ad to, but in scaling – and keeping track of – the ad infrastructure to thousands or millions of viewers. This video explains how this complexity arises and the techniques that Hulu have implemented to improve the situation.

Zachary Cava from Hulu lays out the way that standard advertising works for live streams. Whilst he uses MPEG DASH as an example, much the same is true of HLS. This starts with cutting up the video into sections which all start with an IDR frame for seeking. SCTE 35 is used to indicate times when ads can be inserted. These are called SCTE Markers. As DASH has the principle of defining a period (exactly as it sounds, just a way of marking a section of time), we can define periods of ‘programme’ and periods for ‘ads’. This allows the possibility of swapping out a whole period for a section of several ads.

If it were as simple as just swapping out whole periods, that would be Server-Side Ad Insertion. For per-user targetted ads, the streaming service has to keep track of every ad which was given to a user so that when they rewind, they have a consistent experience. This can mean remembering millions of ads for services which have a large rewind buffer. Moreover, traffic can become overwhelming as, since the requests are unique, a CDN can’t help in the caching. Whilst you can scale your system, the cost can spiral up beyond the revenue practical.

Enter MPD Patch Requests. This addition to MPEG Dash requires the client to remember the whole of the manifest. Where the client has a gap in its knowledge, it can simply request that section from the server which generates a ‘diff’, returning only the changes, which the client then assimilates into memory. The benefit here is that all the clients end up converging on only requesting what’s happening ‘now’ and so CDNs come back in to play. Zachary explains how this works in more detail and shows examples before explaining how URLQueryInfo helps reduce the complexity of URL parameters, again in order to interoperate better with CDNs and allows the ad system to be scaled separately to the main video assets.

Finally, Zachary takes a look at coming back from an ad break where you may find that your ads were longer then the ad period allotted or that the programme hasn’t returned before the ads finished. During the ad break, the client is still polling for updates so it’s possible to quickly update the manifest and swap back to programme video early. Similarly at the end of a break, if there is still no content, the server can start issuing its own ad or content, effectively moving back to server-side ad insertion. However, this is not necessarily just plain ad insertion, explains Zachary, rather Hulu cal it ‘Server-Guided’ ad insertion. There is no stitching on the server, but the server is informing you where to get the next video from. It also allows for some levels of user separation where some larger geographies can see different ads to those from other areas.

Zachary finishes by outlining the work Hulu is doing to feedback this learning into the DASH spec, via the DASH Industry Forum and their work with the industry at large to bring more consistency to SCTE 35 markers.

Watch now!
Speaker

Zachary Cava Zachary Cava
Software Architect,
Hulu

Video: SCTE 224? ESNI? What is Everyone Talking About?

Ad insertion with SCTE 35 is common enough in streaming today, but it can be a blunt tool when it comes to running a complex service which requires complex scheduling and switching plus more detailed control of advert playback and geographical deployment. SCTE 224 is here to meet the challenge by increasing the range of metadata that can be signalled.

Stuart Kurkowski from Comcast explains this need for SCTE 224 and what it delivers. For instance, a lot of SCTE 224 is devoted to controlling the US-style blackouts where viewers close to a sports game can’t watch the game live on TV. Whilst this is relatively easy to deal within the US for local terrestrial transmitters, in OTT, this is a new ability. But SCTE 224, however, isn’t just able blackouts. It also transmits accurate, multi-level, schedule information which helps to schedule complex ad breaks providing detailed, frame-accurate, local ad insertion.

It shouldn’t be thought that SCTE 35 and SCTE 224 are mutually exclusive. SCTE 35 can provide very accurate updates to unscheduled programmes and delays, where the 224 information still carries the rich metadata.

Find out more in this short primer!/a>
Speakers

Stuart Kurkowski Stuart Kurkowski
Distinguished Engineer and Principal Architect,
Comcast Technology Solutions