x264 Preset - Super Fast / Very Fast / Faster etc.

[Henry Hall]

Hi there,
I am attempting to work out the time/quality/file size efficiency for the x264 presets in handbrake.

From experimenting @ RF 18:
Ultra fast --> 00:56 --> 190 MiB
Super fast --> 01:08 --> 267 MiB
Very fast --> 01:20 --> 105 MiB
Faster --> 01:45 --> 118 MiB
Fast --> 02:26 --> 121 MiB

My belief was that the slower the file is encoded at, the better the compression and therefore the smaller the file size. However from my results, often the file size actually increases.

So my questions are
a) Does the quality always increase the slower the encoding speed?
b) Why does the file size sometimes increase?
c) Which is the most efficient preset?

Many thanks!

[Smithcraft]

A - The quality should not decrease when going slower.

B - Without logs it is difficult to know what happened.

C - Placebo?

SC

[Henry Hall]

Hi there,
I have repeated and got the same results. This change in file sizes remains the same regardless of any custom setting. I have also seen other reports of the exact same outcome. I will get the logs if they will help.

Thanks

[Henry Hall]

Aaah this report helps:
http://mmmash.blogspot.co.uk/2013_02_01_archive.html

This graph backs up my outcome:
http://3.bp.blogspot.com/-SmK5i_KLZ-g/U ... e+Diff.png
(With the exception of Ultra Fast)

So just to confirm, decreasing the encoding speed helps reduce the file size, however does only a very little, if any to increase the quality?

[Deleted User 13735]

You're beginning to get it. Encoding time and file size vary inversely.
Also, you've missed the most important metric in your first tests -- CRF.
You are never going to pin it down, and the next source file may give completely different results.
So learn not to chase file size or bitrate.

[Henry Hall]

Thanks, so given the following scenario, do you reckon encoding 1080p content using 2 pass average bitrate (aiming for just short of 23.3GiB / 25GB), with the x264 preset on "Very Fast" would be a reasonable thing to do?

With my build anything slower than "Very Fast" makes it noticeably slower.
Thanks again

[mduell]

That's a rather high bitrate target for typical sources.

I'd say use a reasonable RF and a slightly slower setting since you only need to do 1 pass with CRF.

[Deleted User 13735]

Guess you missed it.

Also, you've missed the most important metric in your first tests -- CRF
So learn not to chase file size or bitrate.

You should read this first:
https://trac.handbrake.fr/wiki/ConstantQuality

[Henry Hall]

Hi, sorry maybe I didn't make myself clear. The source is larger than 23.3 GiB. I am shrinking it down to a maximum of 23.3GiB as to fit on a BD-R disk. Therefore it is appropriate and most efficient to use 2 pass average bitrate.

The question is just in your opinion, which x264 preset would you go for. After observing the following graph, in my opinion "Very Fast" looks by far the best.
http://3.bp.blogspot.com/-SmK5i_KLZ-g/U ... e+Diff.png

[Smithcraft]

It is actually least efficient to do a two pass encode.

I've never bothered with testing at a speed faster than Medium, and I found that the slower the smaller.

SC

[Henry Hall]

It is actually least efficient to do a two pass encode.

I've never bothered with testing at a speed faster than Medium, and I found that the slower the smaller.

SC

Yep but baring in mind I'm aiming for an exact maximum file size. It is most SPACE efficient in terms of maximising the available space on the BD-R disk. Using CRF would be very difficult to maximise the potential storage space on the disk.

Thanks for your comments, as I am using only a mobile i7 I think I will stick with Very Fast. It seems to result in a file size half that of Super Fast and Ultra Fast, and takes not much more time.

Faster takes much longer with my system and I can't tell the difference in quality between it and that of Very Fast

[Smithcraft]

I'm using a i5 660 so I'm sure it can't compare to your i7.

Perhaps you should use Vidcoder since it still has target file size, and it's based on the core Handbrake library.

Or BDRebuilder to get a BD remuxed to the size to fill a disc.

SC

[Henry Hall]

I'm using a i5 660 so I'm sure it can't compare to your i7.

Perhaps you should use Vidcoder since it still has target file size, and it's based on the core Handbrake library.

Or BDRebuilder to get a BD remuxed to the size to fill a disc.

SC

Hi, average bitrate (in handbrake) is the same thing as target file size. I am also not happy with BDRebuilder. There are a few noticeable bugs I'm not going into here.

Anyway this doesn't matter, the original post was just asking what people preferred. Super Fast / very fast / faster. Please don't talk about anything else.

I take it you encode with Medium then, how long does that take with your i5?

[Deleted User 13735]

Please don't talk about anything else.

OK.

[mduell]

Hi, sorry maybe I didn't make myself clear. The source is larger than 23.3 GiB. I am shrinking it down to a maximum of 23.3GiB as to fit on a BD-R disk. Therefore it is appropriate and most efficient to use 2 pass average bitrate.

Yep but baring in mind I'm aiming for an exact maximum file size. It is most SPACE efficient in terms of maximising the available space on the BD-R disk. Using CRF would be very difficult to maximise the potential storage space on the disk.

If you can't see the difference between a 5 or 10GB CRF encode and a 23GB target bitrate encode, is the latter any better?

Thanks for your comments, as I am using only a mobile i7 I think I will stick with Very Fast. It seems to result in a file size half that of Super Fast and Ultra Fast, and takes not much more time.

Faster takes much longer with my system and I can't tell the difference in quality between it and that of Very Fast

Anyway this doesn't matter, the original post was just asking what people preferred. Super Fast / very fast / faster. Please don't talk about anything else.

I take it you encode with Medium then, how long does that take with your i5?

Encode with the slowest preset you can tolerate.

I use medium and get about 12fps on my C2Q Q9300.

[Smithcraft]

I don't use Medium, I use Slow. I get about 4 fps for a full 1920 by 1080 frame.

But I won't talk about anything else.

SC

[Henry Hall]

Thanks. Seeing as we're all criticising my use of average bitrate let me explain my concerns as to why I'm not using constant quality

If you can't see the difference between a 5 or 10GB CRF encode and a 23GB target bitrate encode, is the latter any better?

Issue 1 - The thing is actually I can tell the difference. I have a little home cinema consisting of a projector. When I blow the image up larger there is a difference in quality.

Issue 2 - If I was to encode using constant quality, (baring in mind issue 1), what value would I use as to not run over the maximum capacity of the disk (23GiB)

Issue 3 - (This is the main one, I see what you are saying) - What would visually give better results -
1) Encoding with a constant quality at "Medium" and getting a final size of say 15GiB (Note Issue 2)
2) Encoding with 2 pass average bitrate at "Very Fast" and getting a final size of exactly 23GiB (maximum capacity of disk)

Thanks again

[GregiBoy]

FFS, you are overthinking the whole issue.

Ultimately, it comes down to what YOU are happy with and there really is no need for debate if you wish to disregard the advice you have been given.

[Henry Hall]

FFS, you are overthinking the whole issue.

Ultimately, it comes down to what YOU are happy with and there really is no need for debate if you wish to disregard the advice you have been given.

No I'm just asking you to justify the advise given. I'm completely open to better ideas. What would your opinion be for "Issue 3"?

[mduell]

Thanks. Seeing as we're all criticising my use of average bitrate let me explain my concerns as to why I'm not using constant quality

Issue 2 - If I was to encode using constant quality, (baring in mind issue 1), what value would I use as to not run over the maximum capacity of the disk (23GiB)

Issue 3 - (This is the main one, I see what you are saying) - What would visually give better results -
1) Encoding with a constant quality at "Medium" and getting a final size of say 15GiB (Note Issue 2)
2) Encoding with 2 pass average bitrate at "Very Fast" and getting a final size of exactly 23GiB (maximum capacity of disk)

2) There's no way to guarantee this, but with reasonable settings you're unlikely to exceed 23GB with normal feature films. Maybe Saving Private Ryan or similar that's 3 hours and grainy. Try watching a few movies at RF 20 to see how the quality and filesize are. I've never heard of anyone choosing to go lower except when attempting to solve a problem the wrong way (usually banding or blocking).

3) I'd guess #1; veryfast has to give up a lot of of compression in exchange for speed.

[Deleted User 13735]

OP doesn't want to "limit" encodes to 23 GB as he says. He wants to fill 23 GB, on the impression that file size = quality, efficiency be damned. Since he is pixel-peeping rather than making temporal observations, we will never convince him that he is anything but correct, despite multiple attempts already made.

Mduell is quite correct in that you'd have to work really hard to exceed 23 GB using CRF. In fact it will be quite a bit smaller, but that's not what the OP wants. If he wants big files with less efficiency, he should just use CBR and be done with it.

What I don't get is why he wants to render a file that size in Handbrake when it can only be used as a data file on BD-R. It won't be a BluRay.
There are other utilities out there that will shrink and burn a real BluRay without all the hassle. Handbrake just wasn't meant for that purpose.

Which x264 preset to use is of very little real consequence, considering the real purpose, which is a fixed file size. If he uses a slower preset and ends up with a smaller file, he'll just up the bitrate until he gets the size he wants.

[Henry Hall]

OP doesn't want to "limit" encodes to 23 GB as he says. He wants to fill 23 GB, on the impression that file size = quality, efficiency be damned. Since he is pixel-peeping rather than making temporal observations, we will never convince him that he is anything but correct, despite multiple attempts already made.

Thank you Sir, I was indeed under the illusion that file size = quality. Only now having read your post do I now realise I was wrong. Instead of criticising me, maybe you could actually help by explaining!? ^^No attempts have been made.

Mduell is quite correct in that you'd have to work really hard to exceed 23 GB using CRF. In fact it will be quite a bit smaller, but that's not what the OP wants. If he wants big files with less efficiency, he should just use CBR and be done with it.

Why would CBR be better? You haven't explained why? Don't leave me hanging.

What I don't get is why he wants to render a file that size in Handbrake when it can only be used as a data file on BD-R. It won't be a BluRay.
There are other utilities out there that will shrink and burn a real BluRay without all the hassle. Handbrake just wasn't meant for that purpose.

This is because many programs don't work on my system, the only one that does is BDRebuilder, but as the software is in a "beta" stage, it contains some bugs such the lack of forced subtitles and others.. My Blu-Ray player has 100℅ Full MKV support, which is why handbrake is a good choice. I therefore don't care about it only being a "data disk". There is also a pointless 7% overhead on the m2st container.

Which x264 preset to use is of very little real consequence, considering the real purpose, which is a fixed file size. If he uses a slower preset and ends up with a smaller file, he'll just up the bitrate until he gets the size he wants.

That's correct, what's wrong with that? You haven't explained.

All I got from https://trac.handbrake.fr/wiki/ConstantQuality was that it didn't need 2 passes, and supposedly you get smaller file sizes.

If you would mind could you really thoroughly answer "Issue 3" (See my last post) explaining very clearly why CRF would be better, as I am struggling to understand why CRF is so great (as I am a novice). Tah

[Smithcraft]

I would have been happy to try an point out why we pretty much think that what you are doing is a waste of time, but you said "Please don't talk about anything else."

You could read this thread about target file size and it will point out several things about why we are agreement about using CQ instead of CBR.

SC

[Deleted User 13735]

I'll let your last post speak for itself; except for you to say three times that this has not been explained to you is simply not correct.
I'm not able to validate your theories, sorry. Best of luck.
http://www.dvdfab.com/bdshrink.htm

[GregiBoy]

This rather bemuses me. Why go to all the trouble of transcoding and then storing the resultant files on optical disks? For goodness sake, invest in a large capacity USB hard disk and a player that can utilise it if your current one does not!!

"OP doesn't want to "limit" encodes to 23 GB as he says. He wants to fill 23 GB, on the impression that file size = quality, efficiency be damned. Since he is pixel-peeping rather than making temporal observations, we will never convince him that he is anything but correct, despite multiple attempts already made."