Handbrake's x264 performance

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
ClickClick5
Posts: 15
Joined: Sun Oct 30, 2011 5:40 pm

Handbrake's x264 performance

Post by ClickClick5 » Sun Jan 24, 2016 11:49 pm

Hey all,

After seeing the following post, I decided to see if there was a speed bump between the version of x264 Handbrake is using (r2525) and the latest r2665 (almost a year more of development).
viewtopic.php?f=26&t=32881

My test was done on an Intel i7-5930K @ 4.1GHz.

The video test file was an extra feature clip on the BluRay from the movie "Up" from Pixar.
File: Up_encode_test_2_BLURAY.mt2s
Length: 4 min, 43 sec (6777 frames)
Size: 920MB

I first ran the file three times through the r2525 encoder with the following command:

r2525.exe --crf 20 --preset medium -o 1.mkv Up_encode_test_2_BLURAY.m2ts

Then again three times with r2665:

r2665.exe --crf 20 --preset medium -o 2.mkv Up_encode_test_2_BLURAY.m2ts

Both versions used the same CPU abilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2

I averaged the first three runs together, then the second three together for the results below (nothing else was active on the computer during this time):

r2525:
FPS: 62.16
Encode bit speed: 3951.56 kb/s
Video size: 133MB

r2665:
FPS: 62.52
Encode bit speed: 3953.15 kb/s
Video size: 133MB


So not very exciting. Now this is no way an extreme through test with features and filters to determine changes throughout the revisions, but a "normal person" test. I take it due to the speed, the file size being the same, and no known bugs towards Handbrake, there is no need to update at the moment!

The devs will update when it needs to be updated...or if they just do to do, for the sake of doing.

Enjoy!
~CC5

musicvid
Veteran User
Posts: 3208
Joined: Sat Jun 27, 2009 1:19 am

Re: Handbrake's x264 performance

Post by musicvid » Mon Jan 25, 2016 12:51 am

I don't think the talent pool is focusing on x264 as much these days
A lot of the updates are just housekeeping, and warrant little fanfare, as you confirmed in your tests.

nhyone
Bright Spark User
Posts: 212
Joined: Fri Jul 24, 2015 4:13 am

Re: Handbrake's x264 performance

Post by nhyone » Mon Jan 25, 2016 3:01 pm

Can x264 be further optimized for 4K to make it even more competitive to HEVC? :D

That notwithstanding, it is pretty easy to use x264 today:
  1. set the highest profile & level that your playback device supports
  2. pick a CRF value (typically 18 - 2x)
  3. pick a preset (10 to choose from!)
  4. pick a tuning (typically none, film, animation)
  5. any other small tweaks
The CRF range varies from people to people, but it should not deviate too much from 18 - 22 for "transparent" to "almost-transparent" quality.

There are ten presets, so you might think this is purely a linear scale (from worst to best), but no, there is a method to this madness. Based on a posting, the main setting that affects video quality is trellis, hence the presets can be grouped by it:
0. ultrafast, superfast, veryfast
1. faster, fast, medium, slow
2. slower, veryslow, placebo

The other settings affect encoding efficiency.

I can't really prove this, but I did find a few things from my limited testing:

- all presets look almost identical at the same CRF. Presets affect encoding efficiency, not video quality

- The trellis 0 group looks slightly different (but not in a bad way) [but I could be biased because I knew they were trellis 0.]

- The size goes down in each group, but increases for the next group (typically) [e.g. size(faster) > size(veryfast), size(slower) > size(slow)]

- Choose the slowest in each group for the best efficiency, except placebo should never be used


Some small tweaks:

- slow and slower are hampered by their low b-frame limits, so they should be increased. slower's ref-frame is too high, so it should be lowered. The output will be smaller and the encoding is likely to run faster!

- veryslow, on the other hand, has too high ref and b-frame limits, so they should be lowered. The encoding will run faster, and the output will be negligibly bigger.

Updated: corrected mistake on slower's ref-frames. It is too high, not too low.

keybounce
Posts: 22
Joined: Thu Jan 26, 2017 10:43 pm

Re: Handbrake's x264 performance

Post by keybounce » Sat Apr 01, 2017 3:12 am

(bumping the appropriate thread to continue the discussion)
nhyone wrote:
Mon Jan 25, 2016 3:01 pm
... Based on a posting, the main setting that affects video quality is trellis, hence the presets can be grouped by it:
0. ultrafast, superfast, veryfast
1. faster, fast, medium, slow
2. slower, veryslow, placebo

The other settings affect encoding efficiency.

I can't really prove this, but I did find a few things from my limited testing:

- all presets look almost identical at the same CRF. Presets affect encoding efficiency, not video quality

-- snip --
This is what I don't understand.

If a file at CRF 21.5 looks the same no matter which preset was used, then the VeryFast preset should be as good as the slow preset in preserving quality, right? Yet the VeryFast will be smaller; why use the others?

If B-frames are about letting motion be presented back from a future keyframe in the same way that normal frames are about presenting motion forward from the previous keyframe, why does enabling them increase file size? It would make sense if it also improves quality, but then wouldn't the idea be that group 2 is better quality and can handle a higher RF value? (The RF value is ultimately about deciding what data can be thrown away during compression, right?)

... I'm really not understanding Trellis. Maybe the docs I read were old and confusing.

OH -- Very slow finally completed, and came in smaller. But probably not worth the time for most of us.

nhyone
Bright Spark User
Posts: 212
Joined: Fri Jul 24, 2015 4:13 am

Re: Handbrake's x264 performance

Post by nhyone » Sat Apr 01, 2017 4:42 am

keybounce wrote:
Sat Apr 01, 2017 3:12 am
If a file at CRF 21.5 looks the same no matter which preset was used, then the VeryFast preset should be as good as the slow preset in preserving quality, right? Yet the VeryFast will be smaller; why use the others?
They look similar, not identical. There is still minor improvement in quality as you use higher presets. (So my early post was wrong -- but I was looking for big changes.)

Some settings enable higher quality, at the expense of size/speed. Some settings save space, at the expense of speed. A preset is a collection of these settings.

veryslow is the best that x264 can do. I use a tweaked version (lower ref/bframe) all the time.

Since you have encoded using different presets, you can compare the output for yourself. :D

User avatar
s55
HandBrake Team
Posts: 9463
Joined: Sun Dec 24, 2006 1:05 pm

Re: Handbrake's x264 performance

Post by s55 » Sat Apr 01, 2017 2:08 pm

x264 is a very mature and very well optimised encoder. It's unlikely we'll see any more significant leaps and bounds out of it unless hardware comes along it can take advantage of (i.e a new instruction set)

arcuser
Bright Spark User
Posts: 183
Joined: Mon Mar 09, 2015 5:55 am

Re: Handbrake's x264 performance

Post by arcuser » Sat Apr 01, 2017 4:35 pm

What version of Handbrake did x264 move to r2665?

Post Reply