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:
<Video publicId="dog" > </Video>
<cl-video public-id="dog" > </cl-video>
That's a lot of bytes for a simple non-HD, 13-second-long video. Video optimization is clearly called for.
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=hvc1"> <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
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.
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.