Skip to main content

Presets versus quality in x264 encoding

I'm scoping a project that will require re-encoding a large training video library into HTML5 and Flash-compatible formats. As of today, this means using H.264-based video for best compatability and quality (although WebM might become an option in a year or two).


The open source x264 is widely considered the state of the art in H.264 encoders. Given the large amount of source video we need to convert as part of the project, finding the optimal trade-off between encoding speed and quality with x264-based encoders (x264 itself, FFmpeg, MEencoder, HandBrake, etc.) is important.


So I created a 720p video comprised of several popular video test sequences concatenated together. All of these sequences are from lossless original sources, so we are not re-compressing the artifacts of another video codec. The sequences are designed to torture video codecs: scenes include splashing water, flames, slow pans, detailed backgrounds and fast motion. I did several two-pass 2500 kbps encodings using the x264 presets distributed with the x264 command line encoder (version 0.110.1820 fdcf2ae). Excepting the "ultrafast" preset, which does not use B-frames and was dropped from the charts as an extreme outlier, all of the presets created files that varied by less than 0.2% in bitrate.


Here is the actual encoding command used in the test:

x264 --preset {presetname} -B 2500 --ssim --pass {1|2} -o {output}.mp4 input.y4m


The mean luminance SSIM (as reported by x264) was used as the objective quality metric in my tests. Yes, I know about the weaknesses of using arithmetic means for video metrics, and the benefits of box-and-whisker plots for showing variance between frames. However, a single number is quite illustrative, especially since we are testing the same basic codec at the same bitrate with marginally differing tunings. This was a quick-and-dirty test. If I find the time to get avisynth working correctly on my Windows 7 x64 machine I will update the plots to include variance information.


Here's a quick and dirty chart (click to enlarge):


I was quite surprised that there was only a 0.75 dB difference in mean SSIM from the veryfast to placebo presets, despite placebo being 68 times slower than veryfast mode. I would have expected much more quality improvement for the CPU effort expended, given that placebo was producing just 1.5 fps on an eight-core machine. From a subjective standpoint, the results are indistinguishable to me, even going frame-by-frame through tough sections of the video.


Needless to say, all of my x264 encoding will now be done with medium preset or faster. Decoding a lossless source video for re-encoding became the bottleneck with medium presets or faster. If there is interest, please leave a comment, and I will find a hosting spot for the lossless, veryfast, and placebo versions of the video so others can compare, reproduce, or extend this simple test.


Comments

Anonymous said…
oh. please do so
Polar Torsen said…
Thanks for posting this! I was wondering for some time now, how much gain in visual quality there actually is between Medium and Slow presets. Guess I'll just do all encodes in Medium mode from now on. Thanks again.
RPM said…
While far from a scientific Mean-Opinion-Score study, we did ask our QA group (which is a collection of about a dozen internal folks with varying visual acuity) to judge the quality differences of some sample clips. Essentially, they as a group detected no differences whatsoever between medium and placebo settings at the same bitrate. This is in an office environment however; a large-screen movie-theater viewing could I suppose show some differences to the visually acute. But that was not our use case, and was not tested.
Anonymous said…
what were the size differences between the presets? did placebo for example generate a much smaller file?
RPM said…
The bitrate was specified as 2.5 Mbps for all encodes, so there were no significant file size differences (less than 1 percent as I recall).

Now, if you do a fixed-quality encode, there will be a size difference. But in my tests the size difference is very small between veryfast all the way to placebo. There are outliers, though: ultrafast and superfast do seem to produce significantly larger file sizes when a fixed-quality rather than fixed-bitrate is used. But they are really, really fast - much faster than realtime encoding on my systems.
Anonymous said…
If there is interest, please leave a comment, and I will find a hosting spot for the lossless, veryfast, and placebo versions of the video so others can compare, reproduce, or extend this simple test.

Hi, really nice article. Could you please do so? Thanks.
RPM said…
Unfortunately, too much time has elapsed, and I seem to have misplaced the original files. That said, I created them by concatenating lossless clips from the xiph.org archive using ffmpeg, resizing to 1920x1080p if needed. I believe I used the clips "aspen","controlled_burn","ducks_take_off","factory","old_town_cross","park_joy","red_kayak","snow_mnt", and "touchdown_pass" in that order. As mentioned, these clips are a torture test for a video codec.
RPM said…
FYI, the xiph.org test media archive is here: http://media.xiph.org/video/derf/
G Fichtner said…
My experience has been about 50% smaller filesize with fixed quality. I took preset "IPAD" as the base (which Is medium x264) - then increased fixed quality from 20 to 23 and lowered x264 to placebo and resulted in ~ 50% smaller file sizes. I would really like to know how some of the other settings are though - because placebo works just like its name implies - very, very, slowly. Taking over 24 hours for 1 hour home videos.

Popular posts from this blog

Fixing slow NFS performance between VMware and Windows 2008 R2

I've seen hundreds of reports of slow NFS performance between VMware ESX/ESXi and Windows Server 2008 (with or without R2) out there on the internet, mixed in with a few reports of it performing fabulously.
We use the storage on our big Windows file servers periodically for one-off dev/test VMware virutal machines, and have  been struggling with this quite a bit recently. It used to be fast. Now it was very slow, like less than 3 MB/s for a copy of a VMDK. It made no sense.
We chased a lot of ideas. Started with the Windows and WMware logs of course, but nothing significant showed up. The Windows Server performance counters showed low CPU utilization and queue depth, low disk queue depth, less than 1 ms average IO service time, and a paltry 30 Mbps network utilization on bonded GbE links.
So where was the bottleneck? I ran across this Microsoft article about slow NFS performance when user name mapping wasn't set up, but it only seemed to apply to Windows 2003. Surely the patch me…

Google's public NTP servers?

I was struggling with finding a good set of low-ping NTP servers for use as upstream sources in the office. Using pool.ntp.org is great and all, but the rotating DNS entries aren't fabulous for Windows NTP clients (or really any NTP software except the reference ntpd implementation).

ntpd resolves a server hostname to an IP once at startup, and then sticks with that IP forever. Most other NTP clients honor DNS TTLs, and will follow the rotation of addresses returned by pool.ntp.org. This means Windows NTP client using the built-in Windows Time Service will actually be trying to sync to a moving set of target servers when pointed at a pool.ntp.org source. Fine for most client, but not great for servers trying to maintain stable timing for security and logging purposes.

I stumbled across this link referencing Google's ntp servers at hostname time[1-4].google.com. These servers support IPv4 and IPv6, and seem to be anycast just like Google's public DNS servers at 8.8.8.8. time…