Video preload=auto and adaptive bitrate

In recent posts, I have broken down how HLS video streaming works, and how the player can adapt the bitrates to ensure a great player experience.   In this post, we’ll walk through an example of a video (or three) that must quickly adaapt to the available network conditions.

While I was testing a site with Webpagetest.org I noticed that there are 3 simultaneous requests for a 3 different video downloads.

Screen Shot 2017-10-27 at 10.23.39 PM

This occurs because the video tag in the HTML uses the parameter “Preload = auto.”  This parameter tells the browser to download the entire file before the user clicks play.

A quick aside on preload=auto.  By downloading an entire video in advance, you can use up a lot of data and bandwidth.  For customers on mobile – potentially with limited data plans – this can lead to very large data downloads for files that might not ever be consumed by the user.  Use this parameter with extreme caution, especially on mobile.

Now, it kind of goes without saying that if preload=auto should be used with caution for ONE video, doing the same for THREE videos simultaneously is probably not a great idea.  Each of these files have a similar list of available bitrates, and they all kick off with a 2.7 MBPS stream:

Screen Shot 2017-10-27 at 10.26.17 PM

This is actually “middle of the road” for this video – with throughputs available form 224KBPS to 11.1 MBPS.  The WebPageTest run was on a Nexus 7, using the Cable connection (max throughput of 5 MPBS.)  So here is where some basic math shows that we’re going to hit a congestion problem.  Trying to download 7.2 MBPS on a 5 MBPS is like this truck driver trying to squeeze his truck under this bridge… It is just is not going to work….

687155797_4dd09a6f1b_z.jpg

Adaptive Bitrate To The Rescue?

The player quickly realizes that these 3 competing files cannot download in time, so it adapts – to the lowest possible quality video: 224 KBPS for all 3 streams (we the the m3u8 manifests and the first streams coming down here):

Screen Shot 2017-10-27 at 10.35.00 PM

The network can handle the 675 KBPS, and the player begins downloading, and since the bandwidth is ok, jumps up a few bitrates before centering on 1.36 MPBS for all 3 streams (~4 MBPS total).  This is the correct stream to fit all 3 videos into the 5 MBPS cap, and the complete videos download:

Screen Shot 2017-10-27 at 10.47.40 PM.png

All told, we see that these video files (that are never consumed unless clicked by the customer) utilize 55 MB of data on mobile.

Screen Shot 2017-10-27 at 10.48.40 PM

Conclusion

This case study of video streaming illustrates two very important points:

  1. Preload = auto will download the *entire* movie onto the device.  Use this with extreme discretion – especially for consumers on mobile.  They will incur a huge cost, and they may never even click the button to watch the video.
    1. Sub point:  Do not do this on mobile for THREE videos.  That’s just not very nice.
  2. Adaptive bitrate video quickly conforms to the available bandwidth to ensure the highest quality video is consumed.  In this case, the player quickly realized that it could not perform at the initial bitrate – pulled back to a lower bitrate, and then quickly dialed in to the maximum bitrate possible with the available network conditions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s