Short-form videos—hero banners, product pages, ads, social content—are popping up on the web in places never seen before. This trend could become challenging 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 about High Efficiency Video Coding (HEVC), Vorbis, and VP9, and their eyes glaze over.
Lack of experience and compression knowhow on the part of web developers can cause significant user-experience problems. For instance, while on a major retail site recently, I ran into a hero banner in the form of a 48-MB video, which, if encoded correctly as an H.264 MP4, would weigh 1.9 MB only. Encoding it with a more advanced codec, such as HEVC, VP9, or AV1, would yield even more compression.
Obviously, despite the demand and desirability of more video content, many developers have yet to catch up to the best practices. Just how do we get the best of both worlds without creating a bandwidth disaster like the one I just mentioned?
Cloudinary offers a simple solution. Identifying the most suitable format for video delivery on the web and encoding it involves only adding a couple of parameters to the video URL.
Take this original video at 8.67 MB:
That's a lot of bytes for a simple non-HD, 13-second-long video. Optimization is clearly called for.
First, have a look at the markup:
<video controls> <source src="https://res.cloudinary.com/demo/video/upload/q_auto,vc_h265,w_1280,c_limit/dog.mp4" type="video/mp4; codecs=hvc1"> <source src="https://res.cloudinary.com/demo/video/upload/q_auto,vc_vp9,w_1280,c_limit/dog.webm" type="video/webm; codecs=vp9"> <source src="https://res.cloudinary.com/demo/video/upload/q_auto,,w_1280,c_limit/dog.mp4" type="video/mp4"> </video>
With the intuitive HTML5
<video> tag, you can list multiple sources as format choices for the browser. The browser then goes through the list, starting at the top, until it finds a version it can play. That way, you’re assured of optimal cross-browser support for video compression, ready for delivery to your audience.
In the markup above, the first
<source> element points to an H.265-encoded, i.e., HEVC-encoded, MP4 file. The reason for the top billing is that H.265 is about 30 percent more efficient than the universally supported standard, H.264 (aka AVC). However, H.265 currently works only on Safari (both desktop and mobile). All other browsers would move on to the second
<source>, VP9, a codec supported by Edge, Firefox, and Chrome, gratifyingly bridging the big gaps in H.265 support.
Though both H.265 and VP9 are similar in video-compression capability, the result varies, depending on the video content, length, resolution, and other factors. Nonetheless, both codecs do a far better job of compression than H.264. Be sure to list them as the first and second choices for the browser, leaving that old standard from 2003, MP4, as the third option for all outlier browsers that support neither H.265 nor VP9.
f_auto) feature to automatically identify the viewer’s device and browser, also to adapt the video to the optimal format and codec, as in this transformed version of the dog video:
<video src="https://res.cloudinary.com/demo/video/upload/q_auto,f_auto,w_1280,c_limit/dog.mp4 controls">
Why mount that effort to change video tags to encompass the list above? Three reasons:
File size. The file size of the dog video in each of the codecs is as follows, all delivering the same visual quality:
- H.264: 801 KB
- VP9: 515 KB
- H.265: 436 KB
Encoding the video with H.265 or VP9 instead of H.264 yields a significant savings of approximately 300 KB, meaning that you’d deliver the same video quality much faster. Alternatively, you could leverage some of the saved bytes to encode for a higher quality. Of course, the choice is yours. Perhaps do an A/B test—A for less bandwidth overhead and B for more compelling visuals—and see what your visitors prefer?
q_autotells Cloudinary to automatically find and adopt the right balance between quality and file size. Being content aware, the adjustment varies between simple one-shot videos and complex action scenes. You can control that tradeoff by specifying the desired quality according to this syntax:
q_auto:quality, where quality is
w_1280,c_limittransformation. The width (
w) parameter tells Cloudinary to resize the video to a width of, in this example, 1,280 px. unless the original is narrower, which is the case of the dog video. That way, you avoid delivering an oversized video, like a 4K-wide footage, which most screens cannot fully display. It’s a good idea to specify a ballpark value, but feel free to change
1280to whatever you desire.
Do experiment with the HTML markups in the example above. Be sure to replace
cloud_name with your account’s cloud name and the video’s public ID (
public_id) with the one that identifies your video. You can then rest assured of the best possible user experience.
Part 2 of this series will describe how adaptive bitrate streaming plays into this topic and recommend the proven ways for optimizing longer-form videos. In the meantime, check out our Video Transformation Reference Guide.
- Optimizing Video with Cloudinary and the HTML5 Video Player
- ExoPlayer Android Tutorial: Easy Video Delivery and Editing
- How to Generate Waveform Images From Audio Files
- Auto-Generate Subtitles Based on Video Transcript
- Automated Generation of Intelligent Video Previews on Cloudinary’s Dynamic Video Platform
- Converting Android Videos to Animated GIF Images With Cloudinary: A Tutorial
- Tips for Retaining Audience Through Engaging Videos
- Product Videos 101: What Makes Them Great?