Reducing Video Loading Time

Prefetching video during preroll at Dailymotion, by Guillaume Du Pontavice

At Dailymotion, we do our best to enhance our viewers experience. It is a known fact that video buffering is a big factor of user frustration, lots of studies and articles have shown that video rebuffering has a significant impact on user engagement.

There are two kinds of buffering:

• Initial video buffering, also known as video loading time, or join time.
• Spurious video re-buffering that happens in the middle of playback when video buffers become empty

In this post, we’ll explain the different directions we’re exploring to reduce video loading time.

Ways to reduce video loading time

Here are different technics we’re using to reduce video loading time.

Optimize the video delivery:

• redirecting our videos to different proxy (Dailymotion’s one and/or external CDNs) across the globe to reduce network latency and increase download speed

Reduce first fragment loading time by reducing its size:

• biggest files are video fragments (size could be reduced by either)
• starting the playback on a lower rendition
• reducing fragment duration

Optimize the player startup sequence by prefetching the start of the video during the preroll. This technic is detailed below.

Playback Startup Sequence

See below a standard player startup sequence, it is made up of two slots:

• An “Ad Slot” during which Ad plugins will determine whether an inline video ad (also called a preroll) should be displayed before the actual video. if Ad plugins decide that an ad should be displayed, preroll video will be displayed in this same slot
• A “Video Slot” dedicated to the playback of the actual video content

Before being able to display the first video frame, 3 URLs need to be loaded before being able to playback an HLS playlist:

• The Variant Manifest, which references available qualities and provides a Stream manifest URL for each of them
• The Stream Manifest which references video fragments URLs
• The first video fragment

Manifest Prefetching

The idea is to split video loading into two parts:

• Prefetch these manifests during preroll: these are tiny files, and care should be taken to ensure that their loading has no impact on Ad Loading.
• Then load first fragment in video slot

This manifest prefetching has been implemented in our Flash and HTML5 Player, and we can observe a significant drop of median video loading time from 2400ms to 1100ms in our Flash Player.
Ad Loading time and Ad Display time also remains stable. No impact on Ads revenue.

The gain in our HTML5 Player was less substential. The reason why loading time reduction is significant in Flash is that our HLS media engine, flashls, supports progressive fragment parsing: the TS packets are parsed and transmuxed into FLV packets as soon as they’re loaded: therefore the playback could start even though the first fragment is not fully loaded yet.

This progressive parsing is not yet achievable in HTML5: our HTML5 streaming engine, hls.js, uses XMLHttpRequest to load manifests and fragments, which does not support onprogress() event on binary content.
Thus playback could only start after the entire loading/transmuxing of the first fragment into ISO-BMFF format, and video loading time is higher in HTML5. Fetch API will resolve this, but it is still an experimental feature and not yet available mainstream.

Stream Prefetching

To further improve video loading time, we decided to A/B test stream prefetching: the idea is to prefetch both manifests but also first video fragment during the Ad slot.

We implemented it in our HTML5 player and AB tested it: hls.js supports manifests and first fragment prefetching, even if <video> element isn't available (as it might be used to display a preroll video).
Refer to this config parameter.

See results on video loading time distribution below: as we can see the loading time is significantly reduced — by half — for most playback sessions.

Then we also compared viewers behavior: as it can be seen below, more users are watching to the end of the video; which is a good way of showing that streaming experience was better overall.

On the revenue side, we also noted that although the preroll revenue decreases slightly, it was compensated by an increase in midroll / postroll revenue. So overall, we provided our viewers with an improved streaming experience without compromising our revenues. We continue our quest to enhance user experience, and the next step is to enhance hls.js ‘ ABR algorithm, through A/B testing.