Subject: [Hls-interest] Support for server side ads in long form VOD

From: Ofer Shem Tov <[email-masked]>
Date: Wed, 27 May 2020 18:40:42 +0300

In Verizon Media Platform we have a video platform with server side ad
insertion called Uplynk. We have a problem with long VOD videos that
involve the HLS specification. When a player asks to watch a VOD video,
before returning the master playlist, we go and fetch ads and stitch them
into the media playlists. This works great for short videos, and live, but
for longer videos (episodes, movies, etc.) there are several major
problems: - Start time is very long since we need to fetch a lot of ads. -
When the player actually plays an ad which is at the end of the video, a
long time after the ad was requested, the ad network might ignore ad
impression beacons - Users might not watch the entire videos causing a lot
of ads to be requested but not played which reduces the requestor credit
with the ad network - In general for programmatic ads that involve real
time bidding, playing an ad a lot of time after the bid is not optimal DASH
has a solution for that. In DASH each ad is in a different period. A period
is like its own video with segment description. This would cause the same
problems as with HLS but a period can also point to a remote manifest (MPD
xlink) instead of listing the period segments. This allows for just in time
ad stitching for long videos. One possible solution for HLS (since the
master playlist has no timeline) is to allow a reference to a media
playlist inside a media playlist. This reference can have an estimated
duration (since we know the size of the ad slot but not the exact duration
of ads we would receive from the ad networks) and a URL to a media playlist
containing the stitched ads. The player should fetch the referenced
playlist when it needs to download a new segment and this segment is in the
referenced playlist. Assuming the player buffer is 1-3 minutes it means the
server serving the referenced playlist will fetch the ads 1-3 minutes
before playback time which is good. Once the referenced playlist is
fetched, the actual duration can be known to the player. The video duration
reported in the player API can be the net duration without referenced
playlists since we do not show a seek bar for the ads but maybe a more
flexible API is required to report changing video duration. Since ad
encoding might be different from content encoding we will add
EXT-X-DISCONTINUITY before and after the referenced playlist. We will send
ad information including beaconing URLs using EXT-DATE-RANGE tags. Our apps
can use those metadata events to display UI about the ads and send
impression beacons. The EXT-X-PROGRAM-DATE-TIME of the content will be the
same for all users on the content part while another clock will be used for
EXT-X-PROGRAM-DATE-TIME in the referenced playlists which are personalized
and can be different, and with different duration, for each user.

We will be happy to hear about any plans or ideas for solving this problem
with the current spec or future spec of HLS.

Thanks
-- 
<http://www.verizonmedia.com>

Ofer Shem Tov

Distinguished Software Dev Engineer
Media Platform

M +972548842664
2A Jabotinsky St.
Amot Atrium 36th Floor
Ramat Gan

<http://www.facebook.com/verizonmedia>   <http://twitter.com/verizonmedia>
<https://www.linkedin.com/company/verizon-media/>
<http://www.instagram.com/verizonmedia>

---

From: Roger Pantos <[email-masked]>
Date: Thu, 28 May 2020 11:59:21 -0700

Hello Ofer,

> On May 27, 2020, at 8:40 AM, Ofer Shem Tov <ost=[email-masked] <mailto:ost=[email-masked]>> wrote:
> 
> In Verizon Media Platform we have a video platform with server side ad insertion called Uplynk. We have a problem with long VOD videos that involve the HLS specification.
> 
> When a player asks to watch a VOD video, before returning the master playlist, we go and fetch ads and stitch them into the media playlists. This works great for short videos, and live, but for longer videos (episodes, movies, etc.) there are several major problems:
> - Start time is very long since we need to fetch a lot of ads.
> - When the player actually plays an ad which is at the end of the video, a long time after the ad was requested, the ad network might ignore ad impression beacons
> - Users might not watch the entire videos causing a lot of ads to be requested but not played which reduces the requestor credit with the ad network
> - In general for programmatic ads that involve real time bidding, playing an ad a lot of time after the bid is not optimal
> 
> DASH has a solution for that. In DASH each ad is in a different period. A period is like its own video with segment description. This would cause the same problems as with HLS but a period can also point to a remote manifest (MPD xlink) instead of listing the period segments. This allows for just in time ad stitching for long videos.

We've got some ideas about how we could fit something like this into HLS. I expect that we’ll be able to share them once we get further along. 

In the meantime we’re certainly interested in hearing about your requirements, including how you’d like to package ad assets, whether you’d have live vs. VOD vs. EVENT use, multi-language support, if and when ads get decisioned or re-decisioned, and essentially any other complications or edge cases that you can think of.

Roger Pantos
Apple Inc. 

> 
> One possible solution for HLS (since the master playlist has no timeline) is to allow a reference to a media playlist inside a media playlist. This reference can have an estimated duration (since we know the size of the ad slot but not the exact duration of ads we would receive from the ad networks) and a URL to a media playlist containing the stitched ads. The player should fetch the referenced playlist when it needs to download a new segment and this segment is in the referenced playlist. Assuming the player buffer is 1-3 minutes it means the server serving the referenced playlist will fetch the ads 1-3 minutes before playback time which is good.
> Once the referenced playlist is fetched,  the actual duration can be known to the player. The video duration reported in the player API can be the net duration without referenced playlists since we do not show a seek bar for the ads but maybe a more flexible API is required to report changing video duration.
> Since ad encoding might be different from content encoding we will add EXT-X-DISCONTINUITY before and after the referenced playlist.
> We will send ad information including beaconing URLs using EXT-DATE-RANGE tags. Our apps can use those metadata events to display UI about the ads and send impression beacons. The EXT-X-PROGRAM-DATE-TIME of the content will be the same for all users on the content part while another clock will be used for EXT-X-PROGRAM-DATE-TIME in the referenced playlists which are personalized and can be different, and with different duration, for each user.
> 
> We will be happy to hear about any plans or ideas for solving this problem with the current spec or future spec of HLS.
> 
> Thanks
> -- 
>  <http://www.verizonmedia.com/>
> Ofer Shem Tov
> 
>  <http://www.facebook.com/verizonmedia>   <http://twitter.com/verizonmedia>   <https://www.linkedin.com/company/verizon-media/>   <http://www.instagram.com/verizonmedia>
> 
> -- 
> Hls-interest mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/hls-interest