Is Handbrake usually this slow?

[pizzaboyUK]

Admittedly, this is the first time I'm encoding such a big file (8.5GB to 4.3GB MKV - around 2,300 bitrate at 1920x800), but does H2.64 really take this much time?

Estimated around 7hrs... Pentium Dual Core E6500@2.93GHz, 2GB RAM, Win7 64-Bit, GeForce 9500GT.

Though I recall my Intel(TM)2 Quad Q8400@2.66GHz, 4GB RAM, Win7 64-Bit, GeForce GT430 - didn't fair much better either...


I'm using VidCoder which is an interface to Handbrake.

[Hoser Rob]

Slow compared to what? How many other video encoders have you tried? Handbrake isn't particularly slow ... and there are no magically fast encoders. Especially with a 2 core 2Gb setup running Windows 7.

Anyway, without knowing what profile/settings you're using it's not meaningful to talk about speed. The advanced h.264 settings (where the quality really is) slow encoding down hugely. The slowest setting takes about 100x as long as the fastest. If you just dip your toes into the good quality settings you're talking at least 3x as long.

[pizzaboyUK]

Thanks mate, was generally just interested in how other users judged and whether they had better (quicker) experiences using other software.

[roma_turok]

If you set X264 preset to Very Slow , so yes it can take long time
Handbrake encoding depend on CPU speed
You can check you CPU from handbrake cpu benchmark list: http://www.tomshardware.com/charts/cpu-charts-2013/-31-Handbrake,3164.html
for example you can see Intel Core E6750 on last place

[jagabo]

does H2.64 really take this much time?

It depends on what encoder settings you use. There's a >100 fold difference between x264's fastest and slowest presets.

[Kerry56]

You have three choices. Use faster settings in Vidcoder (which is easy to do).

Or, if the resulting visual quality isn't up to your personal standards, get used to longer encoding times using the slow settings.

Or invest in a faster machine, preferably a modern Intel quad core.

[pizzaboyUK]

Thanks guys.

Kerry56 My quad core didn't fair too well either. Guess I had other stuff running in the background as well, thats why I've resorted to the Dual core as thats not as busy...

[pizzaboyUK]

Great link roma_turok!

[redwudz]

Takes me about 20 minutes to convert a 8GB DVD to a 2GB MKV (H.264/AC3) file. But that's on a 8 core CPU running at 4.2GHz. I use a Constant Quality setting of 19.5.

CPU speed, and number of cores, makes a huge difference, as does the encoding settings. You just find the settings that give you the quality you want and let it run.
I used to do all my encodes overnight with a slower PC. VidCoder will let you set up a batch encode of several DVDs and then overnight really works well.

[pizzaboyUK]

Thanks redwudz

[hello_hello]

As a rough comparison. This PC has a E6750 CPU running at 3.2Ghz. I took a 1920x1080 MKV and cropped it to 1920x800. No other filtering. Default x264 settings (medium speed preset), constant quality encoding. It's currently plodding along at about 6.7fps, estimated time for a 43 minute video, 2 hours, twenty five minutes, but the speed and estimated time tends to change a bit as encoding progresses.

Already it's changed to 8.2fps and estimated time has dropped to 2 hours, ten minutes, but no doubt it'll slow down again, then speed up etc....

I also own a Q9450 running at 3.2Ghz. It tends to encode at pretty much twice the speed of the dual core, assuming there's no filtering causing a bottleneck.

(8.5GB to 4.3GB MKV - around 2,300 bitrate at 1920x800)

That seems to imply you've selected an output bitrate/file size which requires two pass encoding. 2 passes takes longer than a single pass (CRF encoding) but I can't recall how fast the first pass is compared to the second. It's been so long since I ran a 2 pass encode.
I ran the above test encode with MeGUI but Vidcoder shouldn't be any different speed-wise, as far as I know, assuming the same encoder settings are used (I think HandBrake/Vidcoder's High Profile preset encodes with the default x264 settings, unless you've changed them).

[pizzaboyUK]

Thanks hello_hello.

Your Dual and Quad Core gives me quite a good estimate on the times I should be getting.

Why don't you bother doing a 2 pass? Isn't first pass more of a quick preview kind of encoding?

From encoding XVID files in the past, 2 Pass (on its own) takes around twice as long as 1 Pass, so for a 2hr 1 Pass it would take around 6hrs, so obviously quite a bit of compression going on (I guess anyway ).

[jagabo]

Why don't you bother doing a 2 pass? Isn't first pass more of a quick preview kind of encoding?

No. He's using Constant Quality encoding in Handbrake, CRF in x264 nomencalture. There are two basic methods of encoding:

1) Bitrate, where you specify the bitrate but you don't know what the quality will be.
2) Quality, where you specify the quality but you don't know what the bitrate will be.

When they both give the same bitrate the quality is the same, and vice versa. You use bitrate based encoding when you need a specific file size (like fitting a 2 hour movie on a 4.7 GB DVD). You use quality based encoding when you want a certain level of visual quality (relative to the source -- a high quality setting will not turn a crappy VHS source into a Blu-ray quality video).

Constant quality encoding only requires one pass because the encoder knows how to encode each frame at the specified quality. Bitrate based encoding takes two passes because the encoder needs to know what the entire video looks like before it can allocate the right bitrate to difference scenes. Unlike Xvid, x264 uses a "fast" first pass by default. It runs several times faster than the second pass where the real encoding is done.

[hello_hello]

Why don't you bother doing a 2 pass? Isn't first pass more of a quick preview kind of encoding?

CRF (single pass encoding) lets you pick the quality. The final bitrate (file size) will be unknown.
When you choose a bitrate/file size, the x264 encoder uses the first past to work out how to distribute the bits, it calculates the required CRF value to produce the bitrate/file size requested, then the second pass does the encoding. When you choose a bitrate, you don't know what the quality will be.

If you run a single pass encode using a particular CRF value, make a note of the resulting bitrate, then use that bitrate to encode the video again with a 2 pass encode, the video will be encoded pretty much exactly the same way each time. There's minor differences, but nothing which changes the quality.

So..... CRF encoding lets you pick the quality, and 2 pass encoding lets you pick the bitrate/file size. As file size is generally not an issue for me, I mainly stick to CRF encoding. CRF18 is "roughly" where the x264 encoder is considered to be transparent (higher values = lower quality = smaller file sizes). Some people use lower CRF values, some use higher. I mostly stick to CRF18 for 720p or lower resolutions and CRF20 for higher resolutions. I think the x264 default is CRF23 so it should still look pretty good.

Edit: I guess jagabo beat me to most of that!

From encoding XVID files in the past, 2 Pass (on its own) takes around twice as long as 1 Pass, so for a 2hr 1 Pass it would take around 6hrs, so obviously quite a bit of compression going on (I guess anyway).

Xvid doesn't have a true quality based single pass encoding method as x264 does, which is one of the reasons 2 pass encoding was mostly used. That's nothing to do with first pass/second pass speed though. I do recall the first pass being faster though. I mainly used AutoGK back in the Xvid days.
I haven't done any Xvid encoding for quite a while but as a quick test...... same video as last time (1920x800), but I just encoded a two minute section of it. MeGUI again, E6750 CPU.

Xvid single pass (Q2, default settings) 4 minutes 15 seconds, 11.4fps.

Xvid 2 pass
1st pass (standard, not turbo): 2 minutes 23 seconds, 20.3fps.
2nd pass: 3 minutes 45 seconds, 12.9fps.

Xvid doesn't work the CPU as hard as x264. I think CPU usage sat on around 70% for the first pass. I forgot to check the second pass but it sat on around 60% for the single pass encode.

I ran the same 2 minute encode again. Default x264 settings, CRF18.
6 minutes 58 seconds, 6.9fps

And given I'd gone that far......
x264 2pass (slow first pass not selected as it's not the default):
1st pass: 1 minute 42 seconds, 28.4fps
2nd pass: 6 minutes 6 seconds, 7.9fps

I'll confess I didn't expect the second pass of the 2 pass encode to be any faster than the single pass, but it was. It meant 2 pass encoding wasn't too much slower than a single pass. Less than I expected. 6 minutes 58 seconds, vs 7 minutes, 48 seconds. Although that's only for 2 minutes worth of video. Extrapolate it to 2 hours worth and it'd add up. An extra 50 minutes?

When you consider a 2 pass Xvid encode took a little over six minutes in total, x264 doesn't seem all that slow in CRF mode. If I ran the same encodes again using the quadcore, I suspect x264's single pass encoding would be faster than Xvid's 2 pass.
I have lots of fond memories of Xvid being really fast too, which I guess it was, when the average encode had a resolution of something like 704x400.

[pizzaboyUK]

Woah, jagabo hello_hello, you guys rock!

Thanks for taking the time for such detailed explanations. I did some read up of CRF before, but had no idea what it actually entailed.

[jagabo]

x264 is well multithreaded. It can keep an 16 core system fully occupied. Xvid is not well multithreaded and can't even keep 4 cores fully occupied. On a single core Xvid is faster than x264. But as the number of cores rises the speed disparity decreases until x264 gets to be faster than Xvid -- around 4 cores (depending on settings used).

Originally, Xvid didn't have a fast first pass. The first pass of a 2-pass encode was simply a Target Quantizer 2 encoding at the chosen settings. Later they added such an option and made it the default. You can still get the slower option by selecting "Full quality first pass".

Xvid's Target Quantizer mode is a type of constant quality based encoding. It's similar to x264's qp mode. Those are constant quality in a mathematical sense whereas CRF mode takes into account what's more visible to the human eye.

[hello_hello]

That's possibly the first time I've compared Xvid and x264 at such a high resolution. I expected the x264 encode to be noticeably better, but it wasn't for this particular video. Yes, x264 retained more fine detail, but it's the sort of thing I had to stop each video on identical frames to see. With both encodes playing normally I'm not sure I could reliably tell them apart.

I can see huge Xvid/x264 differences when low resolution video is running fullscreen, but not so much for higher resolutions it seems. And considering for this 2 minute encode, Xvid at Q2 (maximum quality) was 2750kbps while x264 at CRF18 was 3110kbps, I thought Xvid did reasonably well. I just thought I'd mention it....

Edit: I changed the Xvid bitrate above from 2600 to 2750 because I looked at the bitrate of the wrong file originally.

[pizzaboyUK]

hello_hello, I'm doing a comparision on XVID/x264 now with Fellowship of the Ring at 1DVD size.

I did a previous encode on Avatar (these are my first 2 encodes ever with x264 ), only had a brief look but one of the darker sequences, XVID had some blocky black bits Had to look really carefully to notice though as it was quite short for that part of the movie.

As for now, I'm quite satisfied at having most videos playing at 720px/1.4GB, even 700MB for non action-y type films.


jagabo, I know I'm delaying the inevitable upgrade... its probably time now anyway considering a new generation of video games have passed since I built my last PC (yeah, I know - still downscaled console games ) - really struggling on some games even on the lower settings

[pizzaboyUK]

hello_hello, learning quite a bit about encoding this week...

Only just realized that a video with different resolution sizes at the same bitrate equalled the same quality

Care to explain?

If encode a video, one at 1280px with 2500 bitrate, and another at 720px with 2500, both at 1.4GB... does the 720px get upscaled? Little confused with that as a lot of places I've read up on usually consider the larger resolution the better the quality, though they probably used the CRF encoding method...

[jagabo]

Only just realized that a video with different resolution sizes at the same bitrate equalled the same quality

It's not true.

Little confused with that as a lot of places I've read up on usually consider the larger resolution the better the quality

Reduce your 1280x720 video to a 1x1 pixel frame size, ie a single pixel. How much picture quality does that have? Resolution is a part of the video quality. When you reduce the frame size you are trading off resolution to get fewer blocky artifacts.

[pizzaboyUK]

Only just realized that a video with different resolution sizes at the same bitrate equalled the same quality

It's not true.

Not even if both videos were exactly the same file size?

[pizzaboyUK]

I asked a question about File size : Resolution on the forums the other day, and a member gave me this reply:

It follows that the bitrate was the same for both the 1280 and 720 files.

It also follows that the larger the target size, the higher the bitrate would be.

On a strict target size, the quality is, therefore, the same.

[pizzaboyUK]

When you reduce the frame size you are trading off resolution to get fewer blocky artifacts.

Thats precisely what I thought!

[jagabo]

When you enlarge the small frame video to full screen, or the same size as the large frame video, you will see that the smaller video is not as sharp.

[pizzaboyUK]

Thanks jagabo for pointing that out.

Really helped me get a better idea of what I want from my encodes now!


And thanks to everyone who gave some input!

Now off to play some framerate skipping Dead Rising 3!!