Convert video to mp4
When preparing our videos for web, we should consider different aspects regarding format and quality. In web, the king format to publish videos is MP4. Here, we summarise the main points to address when we convert our videos to optimized MP4 files, from resolution to compression quality. We'll also comment on the creation of additional derivatives coded with VP9 and HEVC.
ProRes and high quality master videos
Video post-processing generally requires handling files with very high quality settings. This is necessary to avoid undesired degradation or artifacts in general video editing operations -like color grading, cropping, or filtering-. In a post-processing stage, videos usually feature high framerates, high resolutions, and low compression rates. Sometimes videos are even encoded in a specific format like ProRes, defined by Apple with video editing in mind and capable to support resolutions up to 8K.
Whatever the format used, video editing is synonym with very high quality. This translates into really heavy files, difficult to handle and definetily not suitable to web workflows. After post-processing a video, we always should convert it to an optimized MP4 file.
Color washing issues in video conversion
A clean color management is essential to avoid undesired surprises with colors. Otherwise, we may end up with video colors that change when viewed in a browser or app. In a web context, this means working with videos in the BT.709 color specification end-to-end, using properly calibrated displays in the production stages. This is the safe color space, sharing the primary chromaticities with sRGB, the standard color space for web.
Of course, colors should also be properly managed when we transcode files in the conversion step, always with sRGB as reference. This is a well-known problem for seasoned Premiere users, which until late 2018 didn't manage color, making the life difficult for those working in wide gamut displays.
H264 profile and level
Back in 2003 in the beginning of the standard H264, three profiles were defined to cope with the diversity of devices and their computational power: Baseline, Extended, and Main. Each profile supports increasingly complex features that improve compression efficiency but also require a higher computational effort. A fourth -more powerful- profile was introduced in 2005, requiring even more computational capacity. This is the High profile.
Today H264 is the coding standard universally supported across devices, systems, and browsers. Any current device supports the four H264 profiles and is capable to decode them in real time without problem. This means there is no reason to use the less eficient profiles for encoding. When converting for the web, we should stick to encoding H264 videos with the High profile.
In H264 we also find different levels that cater to different quality requirements. That is different resolution, framerate and bitrate ranges. For instance, Level 4 covers full HD resolution and over with 30fps and a maximum bitrate of 20Mbps. It is more than enough for the vast majority of videos in the web. Likewise, 4K videos have to be encoded with a level 5. Some decoders limit the framerate and resolution than can decode by limiting the level.
Video resolutions for web
Compared to images, videos result in a much higher consumption of bandwidth. If images are to be delivered responsively, even more so the videos. Delivering a heavy FullHD version to be rendered in a small viewport is pointless. We should define breakpoints that ensure a proper coverage of our audience, bearing in mind our layout and types of videos.
We don't need to zoom in videos and details are less perceptible in the presence of movement. So we'll tipically use a lower maximum resolution for videos compared to images.
Four usual resolutions for 16:9 videos in the web are:
- Full HD 1920 x 1080 px
- HD 1,280 x 720 px
- FWVGA 480 x 854 px
- nHD 640 x 360 px
For high quality videos intended for large displays, we can find a 4K resolution (3,840 x 2,160 px). We still have a 2K resolution (2560 x 1440 px) in between to provide high quality in high density desktop displays, like iMac retina.
In many cases -like ecommerce sites-, we'll likely use product and marketing videos with custom aspect ratios. A straightforward approach is to stick to the same breakpoints for the short side of the video -that is 360 px, 480 px, 720 px, 1080 px, 1440 px- and set the other side accordingly.
Quality and video compression for web
As we compress videos more and more agressively we'll notice increasing visual artifacts (blur, blocking, mosquito) that damage the quality of experience (QoE) of our users. As well, if we fall short of compressing the video, we'll risk to bloat their connection. Again, we'll damage their QoE due to low page speed or video stalling and rebufering. So we need to put an optimization strategy in place that fits our content.
Compression codecs support different coding strategies by setting a number of quality-related parameters. Two important parameters are the bitrate and the crf. The first can be used to assure the bandwidth used by the video and the second is a proxy for visual quality.
Setting a fixed bitrate isn't generally a good practice. Depending on the content of the video -slow vs sudden movements, fine textures vs solid colors-, we'll need different bitrates for a target visual quality. So setting a fixed bitrate means wasting bandwidth with some videos and damaging visual quality in others.
While a policy based on crf assures the visual quality in most cases, it risks producing bitrate peaks in videos with sudden or fast movements in which the underlying metric becomes unstable.
Ideally, an optimization strategy better assures a target visual quality, avoiding bitrate peaks, under different optimization criteria.
Convert to Webm or HEVC
In some cases, especially when we deliver heavy Full HD videos we may be interested in using more recent and powerful encoding specifications like VP9 (WebM) for Android and Chrome users or H265/HEVC for MacOS and iOS users. These encodings will feature a higher compression efficiency reducing the bitrate by about a 30% for the same visual quality.
Similarly to H264, we should have an optimization strategy in place with a visual quality target shared among codecs.
Since only H264 has universal support, we should always keep it as fallback. If we use the default HTML5 player, we should have some code like this for delivering versions in the three codecs.
<video width="100%" controls> <source src="OurVideo.1080p.mp4" type="video/mp4; codecs=hevc"> <source src="OurVideo.1080p.webm" type="video/webm; codecs=vp9"> <source src="OurVideo.1080p.m4v" type="video/mp4"> </video>
We discuss a bit more about video formats for the web in this short article.
Tools for video conversion
There are different tools we can use to compress our videos to get light MP4 files.
We can do it manually with an open source application like Handbrake. A great option is ffmpeg, a powerful library for video transformation. It can be used in the command line or in custom applications. The caveat of these options is that puting an effective optimization strategy in place is not that easy. In the manual case, it requires fine tuning which is time consuming. With ffmpeg, you'll need to develop optimization algorithms and metrics, which in turn require knowledge and development time.
An easy alternative is to use an online service like Abraia video conversion service. Using our content-based optimization strategy any video is converted to an optimized MP4 version. Moreover, we can create all the variants corresponding to different breakpoints and to different codecs if we also want to deliver WebM and HEVC derivatives.