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

Dave Romrell David Romrell
Engineering Fellow,
Advance Research Group,

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!

Zachary Cava Zachary Cava
Software Architect,

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>

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

Video: How CBS Sports Digital streams live events at scale

Delivering high scale in streaming really exposes the weaknesses of every point of your workflow, so even those of us who are not streaming at maximum scale, there are many lessons to be learnt. CBS Sports Digital delivered the Super Bowl using the principles of ‘practice, practice, practice’, keeping the solution as simple as possible and making mitigation of problems primary to solving them.

Taylor Busch tells walks us through their solution explaining how it supported their key principles and highlighting the technology used. Starting with Acquisition, he covers the SDI fibre delivery to a backup facility as well as the AWS Direct Connect links for their Elemental Live encoders. The origin servers were in two different regions and both received data from both sets of encoders.

CBS used ‘Output locking’ which ensures that the TS segments are all aligned even across different encoders which is done by respecting the timecode in the SDI and helps in encoder failover situations. QVBR encoding is a method of encoding up to a quality level rather than simply saying ‘7000 kbps’. QVBR provides a more efficient use a bandwidth since in the situations where a scene doesn’t require a lot of bandwidth, it won’t be sent. This variability, even if you run in capped mode to limit the bandwidth of particularly complex scenes, can look like a failing encoder to some systems, so the fact this is now in ‘VBR’ mode, needs to be understood by all the departments and companies who monitor your feed.

Advertising is famously important for the Super Bowl, so Taylor gives an overview of how they used the CableLabs ESAM protocol and SCTE to receive information about and trigger the adverts. This combined SCTE-104, ESAM and SCTE-35 as we’ll as allowing clients to use VAST for tracking. Extra caching was provided by Fastly’s Media Shield which tests for problems with manifests, origin servers and encoders. This fed a Multi-CDN setup using 4 CDNs which could be switched between. There is a decision point for requests to determine which CDN should answer.

Taylor then looks at the tools, such as Mux’s dashboard, which they used to spot problems in the system; both NOC-style tools and multiviewers. They set up three war rooms which looked at different aspects of the system, connectivity, APIs etc. This allowed them to focus on what should be communicated keeping ‘noise’ down to give people the space they needed to do their work at the same time as providing the information required. Taylor then opens up to questions from the floor.

Watch now!

Taylor Busch, Sr. Taylor Busch
Senior Director Engineering,
CBS Sports Digital