Blog

Server-side ad insertion for MPEG-DASH

Olivier Cortambert

Head of Solutions Architecture at Yospace

Apr 3, 2019

·

3

min read

There’s been a lot of talk in the industry about MPEG-DASH and we’re finding that a number of our customers are turning to this protocol, and of those a number are looking to it as a means of implementing multi-platform DRM.

Yospace was the first vendor to announce server-side ad insertion (SSAI) support for MPEG-DASH and are one of the only vendors today that can boast live services.

The ecosystem for supporting MPEG-DASH is still relatively immature in terms of players, encoders and packagers.  Behind this is the fact that the specification for MPEG-DASH doesn’t specify exactly how an MPD should be expressed to support SSAI, while the DASH-IF has only made a recommendation which is not universally followed.

Compared to HLS, which provides a simple list of segments in its manifest files, MPEG-DASH lists a much more complex set of information which includes the exact presentation time of each segment.  This complexity and precision makes replacing segments a much more involved task.

In a traditional linear television environment ad breaks are usually pretty precise, but in digital this is not always the case.  The SSAI system may receive four 30-second ads from the ad server to fill a two minute ad break but find they are not actually 30 seconds to frame, meaning there may be a slight under run over overrun at the end of the break.  HLS handles these discrepancies in a much simpler manner than MPEG-DASH through the use of a simple holding slate.

To avoid gaps between period in MPEG-DASH (which would lead to a break/buffer of the playback experience) it is necessary to adjust the timing of every period (content and ad breaks).  MPEG-DASH requires that all levels must be expressed on every manifest update, and the XML format of the MPD is quite wordy, so the CPU required to support a manifest update in MPEG-DASH is greater and more bandwidth is required.  HLS, by contrast, uses a more terse expression syntax and the player only grabs the levels it is actually playing, ultimately making server-side ad insertion more expensive for MPEG-DASH than it is for HLS.

It’s also harder to match audio and video when the programming is time-shifted in this way due to the fact that they are digitised in different ways: audio is usually divided in 44000 or 48000 samples per second whereas video is divided into 25 or 50 frames per second.

While MPEG-DASH throws up some complexities for applying SSAI, they are by no means insurmountable and Yospace has proved this over the last 12 months.  We were the first SSAI vendor to announce support for MPEG-DASH, in March 2018, and the first to implement it in a live customer environment later that year.  Today we have several customers using MPEG-DASH with SSAI.

There does remain more expertise in supporting SSAI for HLS though, and we are seeing broadcasters start to explore the alternative of using HLS with CMAF, the Common Media Access Format.  HLS with CMAF maintains the simplicity of HLS (especially for SSAI) while many of the advantages provided by MPEG-DASH. I would actively encourage broadcasters to consider harmonising to CMAF fragments as they are now supported on Apple devices, and use MPEG-DASH as and when it is required.

Where there are devices that can support both MPEG-DASH and HLS+CMAF, careful consideration should be given as to what format is most suited to their in-house expertise.

Recommended Reading

Yospace and Capella to demonstrate Cloud Orchestration for live events at NAB Show

Apr 11, 2024

·

2

min read

Yospace x Endeavor Streaming: powering the future of regional sports

Apr 9, 2024

·

3

min read

Marking a decade of SSAI for live events

Feb 22, 2024

·

2

min read