Slower preset runs longer, but makes larger file

[Larek]

Summary of the bug:x264 preset failure
How to reproduce:

% ffmpeg -i input -preset slow -crf 18 -c:v libx264 output-S
% ffmpeg -i input -preset slower -crf 18 -c:v libx264 output-Sr
% ffmpeg -i input -preset veryslow -crf 18 -c:v libx264 output-Vs
% ffmpeg -i input -preset placebo -crf 18 -c:v libx264 output
ffmpeg version  N-75976-gd59bfcd
Zeranoe Static Win32 build (linked from this site)
built on 13-10-2015
ffmpeg-20151013-git-d59bfcd-win32-static.7z

Slow took 6min produced 261MB file
Slower took 13min produced 252MB file
Veryslow took 24min produced 230MB file
Placebo took 83min produced 237MB file

​https://trac.ffmpeg.org/wiki/Encode/H.264 , says that

A slower preset will provide better compression

As time for me isn't a factor compared to quality and file size, I'll take that ~1% better Placebo should do over Veryslow. Heck if ffmpeg had a Ludicrous preset that took a similar job 24-48hours for a 4% gain I'd be using it.

But just to see how much better Placebo has been doing, I ran a duplicate Veryslow job. Placebo is producing a larger output from the same input file and settings than Veryslow job!

More Detail
Input #0, matroska,webm, from 'Disk02_(ep05-09)-001.mkv':

Metadata:

encoder : libebml v1.2.2 + libmatroska v1.3.0
creation_time : 2015-10-15 14:15:42

Duration: 00:23:11.04, start: 0.000000, bitrate: 7332 kb/s

Stream #0:0: Video: mpeg2video (Main), yuv420p(tv), 720x576 [SAR 16:15 DAR 4:3], max. 9000 kb/s, 50 fps, 50 tbr, 1k tbn, 50 tbc (default)
Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)

Stream mapping:

Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))
Stream #0:1 -> #0:1 (ac3 (native) -> vorbis (libvorbis))

[Larek]

I should note that ​​https://trac.ffmpeg.org/wiki/Encode/H.264 ,also says that

(Placebo) helps at most ~1% compared to the veryslow preset at the 
cost of a much higher encoding time.

That is "helps" not hinders.

[Carl Eugen Hoyos]

Please reopen if the issue is not reproducible with the x264 executable: This bug tracker is not for problems related to external libraries.

[Hendrik]

Note that increased file size is not necessarily wrong, it doesn't guarantee smaller files, just improved quality.

But cehoyos is right, this is a question for the x264 project if anything.