View Full Version : How to encode with x264 to achieve a "certain" quality?
Valeron
7th April 2007, 08:03
With XviD, I can check the 1st pass stats file to see how complex the clip is, then decide how many bits I should give for the 2nd pass encoding to achieve a "certain" quality. But x264 don't output a stats file during the 1st, what can I do with it if i would like to do a "certain" quality encode?
buzzqw
7th April 2007, 08:11
i usually do a first pass with this option --pass1 --crf 18 , in this way x264 will output the stats file (if i need a 2 pass encode) but i can even argue file size/quality by encoding in crf mode...
BHH
Viechal
7th April 2007, 11:54
hmm with the batchfile encoder i do have the stats...
are you using meGUI?
Valeron
9th April 2007, 04:33
yes, i'm using megui
i've found some interesting threads about crf mode, i'll check it first, thank u for your attention.
PuzZLeR
10th April 2007, 18:32
Actually, may I suggest, why don't you use the Xvid data for your x264 encoding?
I personally am a believer of two pass, but to get the "right" bitrate, for a "certain quality" I run quality based encoding for DivX (since I'm familiar with it) at the fastest levels first.
The bitrates and file sizes of this result from the DivX files serves as an index for my bitrate inputs into x264 encoding. DivX is wonderful at determining whether some clips will need more bitrate than others.
I use DivX because it's much faster than any H.264 encoder if you just want some numbers.
With experience, you will find the DivX results quite proportional to the CRF encodes, and you will be able to find your "sweet spot" easily when you use this data for your final encoding.
Terranigma
10th April 2007, 18:58
Or how about using a constant quality (crf, not cq) pass with x264 at 22.0 with subpixel refinement at level 7, and using diamond as the m.e. algorithm? This would be more accurate than your suggestion imho.
PuzZLeR
10th April 2007, 21:08
If the method has a better speed/accuracy balance for acquiring data, then why not?
Terranigma
10th April 2007, 21:13
If the method has a better speed/accuracy balance for acquiring data, then why not?
Actually, it should be slower since x264 compresses higher than divx. The main reason why I suggest he/she use x264 instead of divx is because of the higher compression, so using the same codec (x264) to predict the bitrate would be more feasible. :p
NDM
PuzZLeR
11th April 2007, 02:23
I agree in the better accuracy.
But just for the record, I found that DivX quantizers produce proportionally equal outputs. In other words, if it looks good to you with DivX at bitrate X, then you can multiply X by a certain number between 0.60 to 0.75 for your bitrate to get roughly the same amount of quality with x264 in 2 pass.
This value of X that DivX determines will obviously not be the same with all clips, but it varies just as much, almost proportionally, to what value CRF will yield as its measure of bitrate necessary for the same quality.
As well, here are some equivalents. The first column is the DivX quantizer and the second is the equal x264 quantizer:
2 - 18
3 - 22
4 - 24
5 - 26
6 - 27 or 28 (in between)
Hopefully it helps.
Valeron
13th April 2007, 01:28
@all:
thank u for all ur attention^_^
@PuzZLeR:
the advantage of ur suggestion for me is that i'm familiar with this path, but the disavantage to me is that require an extra pass... and i'm still driven my old Barton 3000+(OC from 2500+)...
@Terranigma:
ur suggestion is the way i'm looking for, but i was too busy to read the threads about crf mode.
anyway, i'll probably try both methods to find which would better comfort me.
PuzZLeR
13th April 2007, 04:55
Actually there's a long way and a short way. The long way produces a bit better quality per file size IMHO.
Long Way:
-Encode using a DivX quantizer of your choice (the lower the quantizer, the higher the file size/quality).
-Check the avg bitrate of the completed DivX file (like with VirtualDub and file info).
-Multiply that DivX avg bitrate by about 60% to 75%.
-Use that bitrate for 2-pass encoding with x264.
Example:
-You encode a file with DivX and the avg bitrate ends up 1500kbps.
-You decide to multiply it by .75, so that = 1125kbps
-Encode with x264, 2pass with bitrate 1125 and you'll get similar quality to the DivX file with a smaller file size
Short Way:
-Pick your level of quality that you like with DivX using a quantizer of your choice (this is easy with a little testing and experience)
-Choose the equivalent in from the table and encode with that value in CRF using x264
Example:
-Say you like the quantizer = 4 in DivX
-Don't encode in DivX, just use 1 pass CRF in x264 with value of 24.
Not hard is it?
Anyhow, I am not familiar with Xvid as I am with DivX. I'm not sure how similar they are in this fashion but maybe someone has an answer for the equivalent Xvid quantizers (not sure what Xvid uses there actually).
Valeron
13th April 2007, 06:44
yes, i understand the path, i'd like to try both, thx
to answer ur question about XviD, since its an ASP implementation too, so the equivalent quantizer for XviD is the same for DivX.
smok3
31st December 2011, 13:30
i usually do a first pass with this option --pass1 --crf 18 , in this way x264 will output the stats file (if i need a 2 pass encode) but i can even argue file size/quality by encoding in crf mode...
BHH
is there any speed penalty for making pass1 file?
kemuri-_9
31st December 2011, 17:34
is there any speed penalty for making pass1 file?
the writing of the stats file itself is negligible in speed.
But specifying --pass 1 without specifying --slow-firstpass changes the encoding settings to fast options, therefore reducing the compression/quality of the encode.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.