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

[Ofer Shem Tov <[e-mail]>]

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 [phone]
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>