Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#4940 closed defect (invalid)

Slower preset runs longer, but makes larger file

Reported by: Larek Owned by:
Priority: normal Component: ffmpeg
Version: unspecified Keywords: libx264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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

Slow took 6min produced 261MB file
Slower took 13min produced 252MB file
Veryslow took 24min produced 230MB file
Placebo took 83min produced 237MB file , 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':


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))

Change History (3)

comment:1 Changed 4 years ago by Larek

I should note that ​ ,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.

Last edited 4 years ago by Larek (previous) (diff)

comment:2 Changed 4 years ago by cehoyos

  • Keywords libx264 added
  • Resolution set to invalid
  • Status changed from new to closed

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

comment:3 Changed 4 years ago by heleppkes

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.

Note: See TracTickets for help on using tickets.