Cloudinary Blog

Optimizing Video with Cloudinary and the HTML5 <video> Player: Part 1

Video Optimization With the HTML5 <video> Player

Short-form videos are starting to pop up on the web in places never seen before--hero banners, product pages, ads, social content, and the like. This trend could be problematic because of the many formats and codecs, let alone inadequate expertise on what best to adopt for web consumption. Nowadays, most people are familiar with image formats (JPG, PNG, and so forth) but ask them what HEVC, Vorbis, and VP9 are and their eyes glaze over.

Video Compression and High-Efficiency Coding Matter

Lack of experience and compression knowhow can cause significant user-experience problems. For instance, on a major retail site, I recently ran into a 48 MB video-hero banner. Pulling out the video and encoding it as an H.264 MP4 reduces the size to 1.9 MB. So, despite the desire for more video content, developers have not yet caught up to best practices. How do we get the best of both worlds without creating a disaster like the one above?

Fortunately, Cloudinary offers a simple solution. Requesting different formats and codecs simply involves adding a couple of parameters to the video URL.

Take this original video at 8.67 MB:

Ruby:
cl_video_tag("dog")
PHP:
cl_video_tag("dog")
Python:
CloudinaryVideo("dog").video()
Node.js:
cloudinary.video("dog")
Java:
cloudinary.url().videoTag("dog");
JS:
cloudinary.videoTag('dog').toHtml();
jQuery:
$.cloudinary.video("dog")
React:
<Video publicId="dog" >

</Video>
Angular:
<cl-video public-id="dog" >

</cl-video>
.Net:
cloudinary.Api.UrlVideoUp.BuildVideoTag("dog")
Android:
MediaManager.get().url().resourceType("video").generate("dog.mp4");
iOS:
cloudinary.createUrl().setResourceType("video").generate("dog.mp4")

That's a lot of bytes for a simple non-HD, 13-second-long video. Optimization is clearly called for.

Enter the HTML5 Video Player and Cloudinary

First, have a look at the markup:

<video controls>
   <source src="https://res.cloudinary.com/demo/video/upload/vc_h265,w_1280,c_limit/dog.mp4" type="video/mp4; codecs=hevc">
   <source src="https://res.cloudinary.com/demo/video/upload/vc_vp9,w_1280,c_limit/dog.webm" type="video/webm; codecs=vp9">
   <source src="https://res.cloudinary.com/demo/video/upload/vc_auto,w_1280,c_limit/dog.mp4" type="video/mp4"> 
</video>

With the HTML5 Video Player, you can include multiple sources for the browser to choose from. The browser then starts at the top of the list and goes down until it finds a version it can play. This way, you can get optimal cross-browser support for video compression with the best possible file delivered for each visitor, with only some simple HTML markup.

Take the first , an H265-encoded MP4 file. (H265 is also known as HEVC, if that wasn’t confusing enough). The reason we list that source first is that it's about 30 percent more efficient than the universally supported conventional standard, H.264 (also known as AVC). Currently, H265 works only on IE, Edge, Safari,and iOS Safari 11 and up; all other browsers would move on to the second listed.

Thankfully, VP9 codec enjoys support from Firefox and Chrome, which is nice because those are the big gaps in H265 support. They are relatively similar in video compression though it can vary by video content, length, resolution, and other aspects. Nonetheless, both codecs do a far better job at video compression than H264. Hence, be sure to give those options to the browser before falling back to that old standard, which is listed as the third option for all outlier browsers that support neither VP9 nor H265.

Why go through this effort? The answer lies in the file sizes for the dog video in each codec:

  • H264: 801kb
  • VP9: 515kb
  • H265: 436kb

There is a ~300kb savings in using H265 or VP9 versus H264. That’s significant. You could also look at this another way-- deliver a higher quality video for the same file size. It's really up to you, perhaps A/B test and see what your visitors prefer: A) Less bandwidth overhead -or- B) Better visuals

One last thing you'll notice is the w_1280,c_limit transformation, a parameter that tells Cloudinary to resize the video to 1280px wide unless the original is smaller than that, which is the case in the dog video. Such a resizing ensures that you're not delivering something way too big, like a 4k video, which most screens cannot actually fully display. You can change that 1280 value to whatever you wish; it's just a good idea to have something there.

Feel free to copy the above code snippet and replace cloud_name with your own and the video public_id with the one that pertains to your case. You can then rest assured that you're delivering the best possible user experience.

Preview Part II

In Part II of this post, we’ll discuss how adaptive bitrate streaming plays into this topic and recommend best practices for longer-form videos. In the meantime, check out our Video Transformation Reference Guide.

Recent Blog Posts

Hipcamp Optimizes Images and Improves Page Load Times With Cloudinary

When creating a website that allows campers to discover great destinations, Hipcamp put a strong emphasis on featuring high-quality images that showcased the list of beautiful locations, regardless of whether users accessed the site on a desktop, tablet, or phone. Since 2015, Hipcamp has relied on Cloudinary’s image management solution to automate cropping and image optimization, enabling instant public delivery of photos, automatic tagging based on content recognition, and faster loading of webpages. In addition, Hipcamp was able to maintain the high standards it holds for the look and feel of its website.

Read more
New Image File Format: FUIF: Why Do We Need a New Image Format

In my last post, I introduced FUIF, a new, free, and universal image format I’ve created. In this post and other follow-up pieces, I will explain the why, what, and how of FUIF.

Even though JPEG is still the most widely-used image file format on the web, it has limitations, especially the subset of the format that has been implemented in browsers and that has, therefore, become the de facto standard. Because JPEG has a relatively verbose header, it cannot be used (at least not as is) for low-quality image placeholders (LQIP), for which you need a budget of a few hundred bytes. JPEG cannot encode alpha channels (transparency); it is restricted to 8 bits per channel; and its entropy coding is no longer state of the art. Also, JPEG is not fully “responsive by design.” There is no easy way to find a file’s truncation offsets and it is limited to a 1:8 downscale (the DC coefficients). If you want to use the same file for an 8K UHD display (7,680 pixels wide) and for a smart watch (320 pixels wide), 1:8 is not enough. And finally, JPEG does not work well with nonphotographic images and cannot do fully lossless compression.

Read more
 New Image File Format: FUIF:Lossy, Lossless, and Free

I've been working to create a new image format, which I'm calling FUIF, or Free Universal Image Format. That’s a rather pretentious name, I know. But I couldn’t call it the Free Lossy Image Format (FLIF) because that acronym is not available any more (see below) and FUIF can do lossless, too, so it wouldn’t be accurate either.

Read more
Optimizing Video Streaming and Delivery: Q&A with Doug Sillars

Doug Sillars, a digital nomad and a freelance mobile-performance expert, answers questions about video streaming and delivery, website optimization, and more.

Doug Sillars, a freelance mobile-performance expert and developer advocate, is a Google Developer Expert and the author of O’Reilly’s High Performance Android Apps. Given his extensive travels across the globe—from the UK to Siberia—with his wife, kids, and 11-year-old dog, Max, he has been referred to as a “digital nomad.” So far in 2018, Doug has spoken at more than 75 meetups and conferences!

Read more