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:
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:
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:
slowest
encoding makes a huge
difference, so what if we use that?Take the blind tests:
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.
- slowest 3m50s → 19.6MB
- slower 2m31s → 21.5MB
- slow 2m5s → 21.5MB
- medium 1m47s → 21.7MB
- fast 1m37s → 22.3MB
- faster 1m33s → 21.4MB
- veryfast 1m17s → 18.9MB
- superfast 1m12s → 26.7MB
- ultrafest 1m9s → 44.8MB
Interpolation & Deinterlacer Settings
For encoder speed “slowest”:
- Fast: 3m20s → 19.6MB
- Best: 3m50s → 19.6MB
For encoder speed “veryfast”:
- Fast: 1m12s → 18.9MB
- Best: 1m17s
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.