This was primarily motivated by the need for both faster and slower presets
than what were in the list, but it also served to move the presets closer
to the current x264 tunings (the old ones were done before significant new
features, such as weighted P-frames). In particular, we no longer disable psy-rd
or motion estimation based on chroma, since neither is changed by any x264 preset
and I could not get them to give me any speed increase at all.
In general, the strategy was to take x264's existing presets, save for
parameters that we cannot change runtime (we never set --subme to 0 because
you cannot get out of it, and cannot modify --mbtree, --rc-lookahead and
--weightp after initial setup), and then build intermediate steps between
them based on what would give the biggest SSIM gain with the least fps drop.
This gives a significantly expanded range; the old one went from roughly
"superfast" to a bit faster than "slow", while the new goes from about 55%
the speed of "ultrafast" (more than twice as fast as the old fastest preset)
all the way to "veryslow" (requiring four times as much CPU as the old
slowest preset, but with a ~0.7 dB SSIM boost in the reference benchmark,
which is quite a bit), about a 30x range. It also gives more evenly spaced
presets than before, although especially in the faster end, it would have
been nice with even more in-between presets (the lack of them is not for
trying; I just couldn't find more useful knobs to tweak in these ranges).
The presets assume the base is "--preset faster --ref 16" (in particular,
that means --weightp 1 --mbtree --rc-lookahead 20); if you change
other options (including starting at "ultrafast", which does things like
--no-deblock which has only modest speed gains but _eats_ quality), you're on
your own. In particular, using "medium" or something else as base would
change --rc-lookahead, which affects both performance and quality
(invalidating the timings), and choosing a lower value for --ref would mean
the slower presets would not be able to use that many reference frames.
x264 does not warn about this, it just silently refuses to apply your
settings.
All benchmarks (both timing and the SSIM values) were run by encoding the first
1000 frames of “Tears of Steel” in 1080p at 2 Mbit/sec, on a quadcore 3.2 GHz
i5 Haswell, which should be more representative of today's machines than the
Sandy Bridge the old timings were done on. I also verified the general trend of
the results on a much more difficult test, namely a 5 Mbit/sec encode of 2000
frames (starting at 48 seconds) of "Metamorf II" at 720p60 (source:
http://zd3n.com/get.php3?get=files/str_metamorf2_hi.mp4). Despite the
addition of faster presets, there are still sections of Metamorf II that I
cannot encode in realtime on the target machine without dropping frames from
the 50-frame queue I'm using.
The benchmark was run using the x264 command-line tool on said machine (so no
hyperthreading) when it was otherwise idle. Input was y4m on tmpfs, output was to
/dev/null. The x264 process was run with realtime priority, frequency scaling
was off, and results varied generally less than 1% between runs (although
there were some exceptions). --no-psy --ssim was used to get SSIM numbers;
--no-psy did not have any impact on measured performance. All tests were run
ten times with frame times (not frame rates) averaged.
projects / x264 / commit