Devious Fish
Music daemons & more
profile for Perette at Stack Overflow, Q&A for professional and enthusiast programmers

Video Encoding Render Settings

This is an examination of video render settings, using Kdenlive as a testbed.

Mpeg encoding by its nature introduces distortion. Because of this, if you are rendering to video that will be fed into further editing later, aim high in quality; imperceptible changes will accumulate. For distribution, though, there’s the matter of balancing file size/bandwidth vs quality; we want the best quality for the least bits (since every bit costs disk space and network bandwidth, and the energy to build and power these things). Alternately, during editing/development, render speed may matter—we just want a good-but-fast render to show someone for their review; we don’t want to waste time waiting around for it.

This document looks at all these to suggest some good settings, offering blind tests for you to review to assess my conclusions for yourself.

Encoder speed vs. Quality

In this test, we compare the effects of encoding quality vs. encoding speed to see the interrelationship.

All tests were run with interpolation and delacing set to “best”.

Take the blind tests:

My impression and conclusions

At 75% quality, I do not see any difference between the two renders. At 35%, however, the slowest generates a much better image with smoother pans; fastest is showing blotchyness and, during pans, distortion of the image.

Conclusion: Slower speeds result in better, crisper renders. However, only at lower quality levels can this improvement be perceived. slowest rendered files may be smaller or larger than their veryfast counterparts, so possibly the additional compute time is determining when, where and how to invest in bits for the render, whereas veryfast may just do a a dumb, steady bitrate and/or an even distribution of bits over the image—fast by sacrificing quality.

How little can we get away with?

In this test, we compare slow encoding at lower qualities to faster encoding at higher qualities.

All tests were run with interpolation and delacing set to “best”.

Take the blind tests:

My impression and conclusions

A slow-rendered video with 35% quality doesn’t match up to a 75% fast-rendered video, but for a 69% savings on bandwidth, it’s not far off.

And boosted to 45% quality, I had to invoke my girlfriend to make sure I wasn’t biased. It seems that despite a 57.5% reduction in file size vs 75% quality encoding, the 45% quality encoding attains a very comparable result.

The cost of this is rendering takes 2× or 3× longer. For a “daily”, this is a waste of time. But for distribution, especially on the Internet, the added rendering time and compute power will return savings in storage and bandwidth.

Rescaling the video

If we’re out to save on space, another strategy is to rescale the video to a smaller size.

Take the blind tests:

My impression and conclusions

If we use the same encoding speed, qHD (960x540) at 75% beats FHD (1920x1080) at 35%, and if we increase that to 45% the qHD still wins, even though its bitrate is higher. But we know slowest encoding makes a huge difference, so what if we use that?

Take the blind tests:

My impression and conclusions

In some places (the pan), the 35% FHD is more detailed than the qHD. But during fast motion (the driving sequence), the 35% FHD shows more pixellation than qHD. Increasing quality to 45% solves the pixelation for the FHD video; the lost resolution of qHD can’t be overcome.

Exhaustive rendering speed results

slowest seems best for release, producing a similar-size size (sometimes slightly larger, sometimes slightly smaller) output files. veryfast seems a good tradeoff for speed vs. size for non-release renders.

Interpolation & Deinterlacer Settings

For encoder speed “slowest”:

For encoder speed “veryfast”:

For these settings, fast is slightly faster, but it’s not a huge difference and scales with the encoder speed setting. Output size does not change much.

Conclusions

For a quick preview render, use Kdenlive’s default 75% with veryfast encoding. It’ll look fine.

For release to the Internet, rendering at 45% quality with slowest encoding provides comparably-perceived results. If you want to further reduce file size, rescaling the video to a lower resolution provides better results than further reductions in quality.

Note, however, that Kdenlive has some bugs that cause incorrect positioning with its rescale rendering option. Therefore, when rescaling one should review the output before publication.