Trade-off between encoding speed preset, file size and encoding time

[kailinu]

Hi Avidemux friends,

For what is worth, I have just run a queue of very simple straightforward x264 encoding jobs with the same original video (length = 6 s) and all the possible presets to determine which was the best trade-off between encoding time and file size. The presets as we know are:

• ultrafast
• superfast
• veryfast
• faster
• fast
• medium
• slow
• slower
• veryslow
• placebo

Here is the chart showing the file size and the encoding time for each preset


There was no filters, Tuning was set to none, IDC level was high, encoding mode was CRF (single pass) with a quality set at 20.

So it looks like the best trade-off would be "very fast" as the file size barely changes between that preset and placebo. Not sure about the quality though, but it's not supposed to change.

Cheers

[szlldm]

IMHO that 6 seconds is way too short to get a meaningful result.
The source should be a real (not something like a static image) video, with much details & high bitrate.

[kailinu]

Yes, 6 seconds was too short but that was a proof of concept and got me to use avidemux_jobs for the first time and to parse the logged details.

If there is interest, I will do it again but this time on a full feature movie or at least a substantial part of it. 

[szlldm]

It would be interesting! A few minutes long video should be enough.

[kailinu]

So here is a new - hopelessly much more representative - version of my test of the trade-off offered by the various presets offered by the x264 codec.

This time I encoded a 7 and a half minute long 4k HEVC video into a 1080p x264 video. FWIW, the sample video can be downloaded here.

And without further ado, the chart



So there really is something funky happening with the presets "Very Fast" and "Faster" presets. The other presets are pretty much in line with what should be expected though.

And I now suddenly realize  that it is a question I should have addressed to the guys working on the x264 codec instead of here.   

Hey, still worth a look for Avidemux curious minds I guess!

[szlldm]

Thank you for the effort! An interesting result.
I checked the source, my problem with it is, that it is basically a sequence of still images.

[butterw]

Slower compression presets have more tools available to perform the compression.

Results will depend on the source.

A quality metric such as VMAF can be used to measure quality degradation.
 
the default crf for x264 is 23.

[AvidUser]

So there really is something funky happening with the presets "Very Fast" and "Faster" presets. The other presets are pretty much in line with what should be expected though.

And I now suddenly realize  that it is a question I should have addressed to the guys working on the x264 codec instead of here.   

This analysis is missing a quality evaluation. Video encoding is very much like a "Pick 2 triangle", the vertices being: quality, file size, and encode time/complexity. You can have any combination of two desirable outcomes but not all three. Next time plot your output against quality metrics like PSNR, VMAF, or SSIM to find the sweet spot for your purpose.

So to your point, the reason very fast is a small file and fast encode is likely because quality was sacrificed.

[Cormy1]

So to your point, the reason very fast is a small file and fast encode is likely because quality was sacrificed.

You seem to be suggesting that the quality factor is ignored.
Vertices can be enforced, whether it be encoding time, size or quality.
In this case, isn't quality being enforced through CRF Single Pass encoding mode set to 20?


I have observed a similar strangeness, though in my case I just wanted to compare Avidemux's default setting to Very Fast.
https://avidemux.org/smif/index.php/topic,19687.0.html

My sample was 5 minutes of very laggy 1080p60 video game footage, the game is a 3rd person shooter.

[butterw]

The preset, not just crf, impact video quality in x264 (a quality metric such as vmaf would show this).

The speed/filesize/quality sweet-spot depends on source content, constraints and application (streaming videogames is really quite different from movie backups). The default medium would be good trade-off in the general case.