HandBrake

With upcoming changes to data protection and privacy laws in Europe coming into effect soon, we thought this would be a good time to remind everyone that we do have a privacy policy.
This applies to all users and visitors world-wide.

We have made a few changes to the language to make it clearer in relation to this new regulation but fundamentally, the terms and your rights are unchanged.

If you have any questions about this, please feel free to ask in the General Forum

first of all:
i dont know where to post this. currently this is just a question, in future this is hopefully a collection of benchmarks. so feel free to move if you think there is a subforum that would be a better choice.

since i plan to upgrade my cpu (and other hardware) from an i7-3770 to an i7-7770 (k) or ryzen i'm curious for some handbrake-cpu-benchmarks...

therefore i downloaded the blender-rendering "bbb_sunflower_1080p_30fps_normal.mp4" (link later in this post). Encoding this file with my current i7-3770 (source and destination on the same hdd) with the following settings took 14m34s.

So if you have 10-20min to perform the same encoding and post your time (logs and hardware too) here that would be really nice
To get the encoding time have a look in the log-file, search for "reader: done" and calculate the difference between the "reader: done" line and the previous one. Average fps is in the next line. For Windows 10 and (possibly 7, 8, and 8.1) the logs can be found here:

disclaimer: there are many things that can affect benchmark results (so even if you own the listed hardware you will possibly produce different result(s)): reasons can be: operating system, security-software, updates, drivers, other running software, hardware (mainboard, ram-timings, ssd), ... Because of that this benchmark(s) can ONLY give a HINT about the differences!

what i want to know is how much another cpu (f.e. i7-7770k or ryzen x1700 or ...) will reduce encoding time using the same settings.

Hopefully this question isn't to stupid... but whats the benefit of using the command line? The only advantage that i see is that its easier to use my settings since you only need to copy&paste the command, adjust the file-paths and execute it. But my personal experience is that posting long-cryptic-command-lines stops most people from reading...

When using the command line, you have to redirect stderr to the file. For Windows/linux/unix systems (which should include Mac), that would be "2>error" (where "error" is the name of the file you want it written to) on the end of the command line.

Using the command line is "better" because it is consistent across all operating systems. There are subtle differences in the GUI implementations which can affect the speed.

CPU is often the bottleneck for video encoding. Looking at a random CPU benchmark, i7-7700K @ 4.2 GHz is 40% faster than i7-3770 @ 3.4 GHz. I would expect it to be in the ballpark for HandBrake.

If you are encoding HEVC, Haswell and above will be much faster due to AVX 2.0.

I have two suggestions:

1. Do you need to use slower preset? Can you live with veryfast? It has the best speed/size tradeoff, at the expense of some quality. It is around 9x faster than slower.

2. Do you need 1080p? I would keep the source and encode to 720p (for 10", 27" to 40" screen) or 480p (<8" screen). It saves both size and bandwidth. For 12-24" screens, some people can accept 720p, some can't -- due to viewing distance.

HEVC would be a nice. But not all of my devices (TV, Tablet, ...) support hardware HEVC decoding. So i could possibly store in HEVC and let my NAS transcode it. For a single stream this might work... But accessing multiple files at the same time... I dont think so. Testing HEVC (slower-preset) with my current cpu and the blender movie, the fps are constantly below 3. (medium-preset around 13fps).

1) Since this is about digitalization and not about transcoding... Quality comes before Speed.

2) Well, the idea is to be able to access all my movies easily from any device. So, yes, i keep the original source as disc. Since there are multiple target devices from 7" up to 55" i store in 1080p and if i know that the target device will be 7" or 10" i can (temporary) downsize the file to 720p with an faster preset.

3) Yes. CRF 18.5 is to much for this file. As I said i use this settings for 1080p movie digitalization. And i used the blender movie since it is public availiable and everyone can access it. This file (animated) is not really representative for my usual case - if I encode a movie with my settings i'm often below 10fps. But I am also assuming that f.e. if an i7-4770 is about 13% faster than i7-3770 encoding an animated file i expect the improvement encoding a real movie should be arround 6-7% (~50% less then the improvement of encoding an animated movie)...

4) Yeah, the file-size-thing is interisting. And also that using the slower-preset and all cores E5-2670v2 < E5-2660v3 < E5-2670, but with veryfast-preset the E5-2670 seems to be much better then E5-2660v3.

The increase in file size isn't strange in hindsight. It is the tradeoff of lookahead: encoding speed vs size efficiency. For smallest size, it is best to use lookahead of one thread, which then limits encoding speed (because the encoding threads are starved).

Haswell+ CPUs have a 40% speed increase due to the use of AVX2 in x265 v1.9. It is extremely significant.

The low CPU usage and Haswell inversion were surprising to me. I had not seen it before. Previously, my results were pretty standard:

Overall, Haswell is 5% faster than IvyB, and IvyB is 10% faster than SandyB, and SandyB just blows X5650 out of the water

Clock-for-clock, per-core, it's a different story. Haswell is 10% faster than IvyB; IvyB is 3% faster than SandyB

veryfast is 3x faster than medium and medium is 3x faster than slower. This might have been specific to my test video/settings and I generalized it wrongly. It still has the best time/size/quality trade-off, though

Encoding speed increases linearly. HyperThread speeds up by 15%. If two physical CPUs are used, there may be no penalty, or up to 25%! (Speed-up is 1.5x instead of the expected 2x)

CPU usage is in the range of 60-80%

Because the Haswell machine performed so poorly, I tested it on another Haswell machine, but got the same results. I then checked the physical machine to make sure the memory configuration was optimal. It should be -- all 8 memory slots were filled in (4 per CPU). 4-channel doesn't matter much, but the slots must be filled in correctly.

Maybe when I have some time, I'll investigate why I got these strange results.

Lookahead thread is indeed the first limiter. But there are three problems with using more lookahead threads: (i) it is still not able to saturate the CPU, (ii) encoding efficiency goes down, (iii) 2-CPU overhead [not apparent here].

So that means that high-end server cpu's with more physical cores don't have any 'real' advantage over current desktop/gaming processors in x264 video encoding? at least if we're looking at encoding-speed and filesize. Thats... unexpected... But i think this is a general encoding problem, due to linear processing, right? If the encoder would split the source material (depending on physical/logical cpu count and content length) and encode multiple parts in parallel and then merge the results back together.... The encoding time should be much lower... But the filesize might be increased slightly because of the cut/merge points... But this... is just a little off-topic