Does 2-Pass encoding with H.264 really not result in better quality?

[mike23]

Much to my surprise I read on web page

https://trac.ffmpeg.org/wiki/Encode/H.264

that 2-pass encoding does NOT result in a better video quality (See FAQ section there).

The only purpose of 2-pass encoding is to match the target video file size more accurately.

Is this really true?

Can someone confirm this?

As far as I remember I read in the past that 2-pass encoding increases significantly the output quality.

Did I miss something?

[Groucho2004]

The only purpose of 2-pass encoding is to match the target video file size more accurately.

Is this really true?Yes.

As far as I remember I read in the past that 2-pass encoding increases significantly the output quality.It depends on to what you compare it. Compared to CRF mode (given the same bitrate), the answer is no.

[Stereodude]

Yes.

It depends on to what you compare it. Compared to CRF mode (given the same bitrate), the answer is no.
At a high level your answers are potentially wrong. Since neither of you qualified your statements you're both right and you're both wrong.

2-pass encoding is not to match the target video size more accurately than 1 pass encoding. You can achieve an exact target size with a 1 pass CBR encode. 2 pass is to achieve uniform perceptual quality across a video of a given size by allocating more bits for the most demanding scenes and saving them on the simple scenes.

A 2 pass encoding should have the same image quality as a CRF encode of the same size. It should also be better than a 1 pass encode of the same size in the more demanding scenes, but will be worse in the simple scenes.

[Groucho2004]

At a high level your answers are potentially wrong.I give you that my answers are brief and/or ambiguous but they are not wrong.


Also, the bold part of your statement below is misleading:
A 2 pass encoding should have the same image quality as a CRF encode of the same size. It should also be better than a 1 pass encode of the same size in the more demanding scenes, but will be worse in the simple scenes.There are settings to optimise bitrate distribution in CRF encodes, one does not have to resort to a far inferior CBR mode.

[Stereodude]

Also, the bold part of your statement below is misleading:
There are settings to optimise bitrate distribution in CRF encodes, one does not have to resort to a far inferior CBR mode.
No, it's not misleading. It is accurate. A 2 pass encoding at the same average bitrate will be worse in simple scenes than a 1 pass CBR encoding (presuming there are scenes of varying complexity). Your comment about bitrate optimization of CRF modes has nothing to do with the statement I made.

[Groucho2004]

No, it's not misleading. It is accurate. A 2 pass encoding at the same average bitrate will be worse in simple scenes than a 1 pass CBR encoding (presuming there are scenes of varying complexity). Your comment about bitrate optimization of CRF modes has nothing to do with the statement I made.I bet the OP is now utterly confused.

For what it's worth, here (http://akuvian.org/src/x264/ratecontrol.txt) is an explanation of x264's ratecontrol by the man himself, Loren Merritt.

[Monarc]

Much to my surprise I read on web page

https://trac.ffmpeg.org/wiki/Encode/H.264
that 2-pass encoding does NOT result in a better video quality (See FAQ section there).

Is this really true?

Did I miss something?

the question in the faq:


Will two-pass provide a better quality than CRF?

Answer:
No, though it does allow you to target a file size more accurately.

explanation from Dark Shikari


CRF and 2-pass use identical bit allocation algorithms. All 2-pass does is pick the CRF value that gives the filesize you want. It's still using the CRF algorithm.

[jpsdr]

I don't know if it has an effect on the quality, but there is one difference i've noticed between CRF and 2-pass encoding.

If you look at the log file, with a CRF encode, or on the 1rst pass of a 2-pass encode, you'll always have (at least it's my case) :
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
But, on the 2-pass of a 2-pass encoding, you'll may have something like that :
x264 [info]: direct mvs spatial:98.7% temporal:1.3%
I've never seen a temporal different of 0.0% with a CRF encode (or on the 1rst pass of a 2-pass encode).

I don't know what is the effect, and if it also affect the bit allocation, but according this result, the 2nd pass obviously doesn't produce the same result than CRF, and for now, i wouldn't say also the bit allocation is identical...

But, i may be wrong also, as i don't know what is the effect of the bit allocation between a 100.0%/0.0% and 98.7%/1.3% difference spatial/temporal ratio.

[amichaelt]

I don't know what is the effect, and if it also affect the bit allocation, but according this result, the 2nd pass obviously doesn't produce the same result than CRF, and for now, i wouldn't say also the bit allocation is identical...

But, i may be wrong also, as i don't know what is the effect of the bit allocation between a 100.0%/0.0% and 98.7%/1.3% difference spatial/temporal ratio.

Dark Shikari can be quoted in a number of posts saying they are exactly the same. There is even one such instance right above your post...

[LoRd_MuldeR]

Dark Shikari can be quoted in a number of posts saying they are exactly the same. There is even one such instance right above your post...

I think we can say that CRF and 2-Pass use the same basic rate-control algorithm, but in slightly different ways.

CRF mode simply picks a fixed scaling factor, based on the "--crf" argument, and that's it. 2-Pass mode makes a "best guess" to choose the scaling factor that will likely result in the desired average bitrate (file size). This is done by predicting the size of all 'not-yet-encoded' frames, using the "complexity" information that was collected in the first (ABR) pass. But, TTBOMK, this is not a fixed decision: As the encode goes on, the actual size of the 'already-encoded' frames is compared to what was predicted, and a correction factor is applied to the 'future' frames, in order to compensate for possible mispreditions – such mispreditions can happen, because slower compression options are often used in the second pass.

[benwaggoner]

Also, a 2-pass encode can help when VBV constraints are happening. With 2-pass, the encoder has nearly infinite lookahead to taper down bitrate earlier on to allow for lower QPs at the most difficult parts. --rc-lookahead can do some of this, but only up to 1 GOP.

I doubt this would make a noticible difference in most cases, but it is a difference.

[Blue_MiSfit]

^ "infinite lookahead" is a good way to define 2 pass encoding :)

[benwaggoner]

^ "infinite lookahead" is a good way to define 2 pass encoding :)
In retrospect "full file lookahead" would be more accurate.

[SeeMoreDigital]

^ "infinite lookahead" is a good way to define 2 pass encoding :)In retrospect "full file lookahead" would be more accurate.What are the command line options for this?

[Asmodian]

What are the command line options for this?

LOL :cool:

[Liisachan]

In my quick tests, a CRF version and a 2-pass version look identical when played back. In terms of SSIM, however, the CRF version tends to be slightly better by ~0.0001, though such a minor difference is probably unnoticeable.

1) I test-encoded a sample file (SD) with --crf 18 --preset slow --tune ssim --ssim, and got SSIM Mean Y:0.9905793 with 842.83 kbps. So I re-encoded the same input with --pass 1/2 --bitrate 843 --preset slow --tune ssim --ssim, and got SSIM 0.9904917, 842.95 kbps. To get the same SSIM as that of --crf 18, I had to use about 860 kbps in 2-pass encoding:
In this sample: crf 18 (~843kbps) ≈ 2-pass (~860kbps) in terms of SSIM

2) I test-encoded the same sample with --crf 16 --preset placebo and got SSIM 0.9918823 with 993.88 kbps. The 2-pass version of placebo 994 kbps gives SSIM 0.9917863, again smaller by ~0.0001.

This is just one sample. SSIM differences between CRF and 2-pass are so small that in some cases, 2-pass might do better than CRF. If blind-tested, probably one can't tell the difference anyway.

My naive understanding is... CRF is faster and better if you want to achieve a consistent quality without size limit (i.e. if you don't mind how small or how big the resulted file might become). Conversely, if you want to achieve a consistent file size and get the optimal quality with that size, you can use 2-pass. They are two different methods used in different situations.

[benwaggoner]

What are the command line options for this?
--pass 1
--pass 2

Note that the gain is about the same as doing a 2-pass CBR versus 1-pass CBR. To whit, very rarely enough to care.

[SeeMoreDigital]

--pass 1
--pass 2

Note that the gain is about the same as doing a 2-pass CBR versus 1-pass CBR. To whit, very rarely enough to care.Oh... I was under the impression that you guys had found a more accurate method of encoding using 2-passes using VBR...

[Sagittaire]

for x264:
crf mode and 2 pass mode are really comparable because 2 pass mode in an inloop of crf mode. Anyway, if you want strickty identical stream between crf and multipass mode, you must use 3 pass mode for x264.

for x265:
crf and multpass mode are not identical. crf mode and multipass mode use differente rate control. For exemple bframe ratio is not the same (with same --ib-ratio setting and all identical command). crf produce little higher metric at same bitrate with really higher ratio for bframe (--ib-ratio seem don't change anything in crf mode).

[benwaggoner]

Oh... I was under the impression that you guys had found a more accurate method of encoding using 2-passes using VBR...
It depends on what you mean by "you guys" and "2-passes" :sly:.

There are all kinds of analysis that can be doing prior to encoding that doesn't require a full encoder pass for each output stream. In practice, doing 2-pass doesn't make sense unless you need to control both average AND peak bitrate. Optical disc or downloads, for example.

Otherwise, if you have the CPU to do 2-passes, it's generally better to just double the complexity of a single-pass encode. Adaptive streaming is either CBR or capped VBR, so either ABR=PBR or ABR is intentionally variable based on content complexity.

[jpsdr]

You'll never have identical bistream between crf and 2 or 3 or more passes, because as i said in my post, the mvs will be different. It's always 0%/100% on the 1rst pass or crf pass, and different on next passes, even if you use the exact same parameters each times (in the case of course you're using --direct auto).
So, between crf and the 2nd or more pass, the mvs will always be different => the bistream will never be identical.
And even more if you're using --non-deterministic, but that not the subject here... ;)

[Sagittaire]

You'll never have identical bistream between crf and 2 or 3 or more passes, because as i said in my post, the mvs will be different. It's always 0%/100% on the 1rst pass or crf pass, and different on next passes, even if you use the exact same parameters each times (in the case of course you're using --direct auto).
So, between crf and the 2nd or more pass, the mvs will always be different => the bistream will never be identical.
And even more if you're using --non-deterministic, but that not the subjet here... ;)

Stricktly identical ... for metric (and certainely really near but not strickly identical stream). If you compare crf and 3pass mode with the same setting, you have the same PSNR (with less than 0.01 db difference in my memory). x264 use crf inloop for Npass mode by successive crf adjustement to reach the right bitrate: stream will be strickly identitical if you use infinite pass number. Anyway, I think that human eyes will be unable to see the difference frame by frame between crf mode and 3pass mode simply because PSNR can't make the difference pixel by pixel.

[hello_hello]

While trying to get it straight in my head, I wrote a summary of the "x264 rate control methods" article. It explains the basic differences between CFR, ABR and 2 pass.
https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encoding-instead-of-2-with-x265#post2470457

I don't think the link tor the original article works any more, but it might be find-able with Google.

[LoRd_MuldeR]

I don't think the link tor the original article works any more, but it might be find-able with Google.

You mean this one?
https://code.videolan.org/videolan/x264/-/blob/master/doc/ratecontrol.txt

[hello_hello]

You mean this one?
https://code.videolan.org/videolan/x264/-/blob/master/doc/ratecontrol.txt

Yep. I'm pretty sure that's the one I based my little summary on.

[Liisachan]

While trying to get it straight in my head, I wrote a summary of the "x264 rate control methods" article. It explains the basic differences between CFR, ABR and 2 pass.
https://forum.videohelp.com/threads/381668-would-it-make-more-sense-to-use-1-pass-encoding-instead-of-2-with-x265#post2470457 Good one. Very educational. Especially, it's interesting that there may exist a "killer sample" where 2-pass does significantly better than cfr.

But the title of the linked thread is "would it make more sense to use 1 pass encoding instead of 2 with x265?" Is this explanation about x264, about x265, or both?

I'd like to point out one thing that may be obvious for encoding gurus but may not be so obvious for ordinary users like myself: the statement "2-Pass encoding does not result in better quality" is true, but that does not mean "2-pass is significantly worse." The statement "CFR encoding does not result in significantly better quality" is also true. The original statement is, like saying "x is not greater than y" - which is true when x==y, but is misleading and confusing for ordinary people, because it sounds like "y is greater than x".

If by "condition" we mean "the size of the resulted file", then CFR is a solution to the "unconditional optimization" problem, while 2-pass is a solution to the "conditional optimization" problem. They are solutions to different problems. If you have a condition - like "I want to get the best quality under the condition that the resulted file must be 1 GB or less", 2-pass encoding is the answer. It's just that today storage is cheap and so encoding without the strong file size limit is more usual.

[Treaties Of Warp]

BUMP

I was doing some testing, and I compared screenshots of a Blu-Ray encoded with x264 Average Bitrate set to 8000, and a 2-pass set to 8000. In every screenshot I tested (my methodology was to use IrfanView to put up the same frame of the source, then both encodes, then click on window buttons to switch between them with them being displayed at actual size and overlaid exactly on top of each other; this I find is the absolute best way to compare), I saw changes to the image with the 2-pass encode and I saw no perceptible change using the 1-pass encode. I would not say the 2-pass looked worse, just different. Film grain seemed to blur in parts of the image, or change slightly. Some pixels seemed to noticeably shift slightly. But I was surprised to see the source image and the 1-pass encode look identical to each other on a near pixel-by-pixel basis.

So I'm not sure what's going on, maybe it's my command lines:

1-pass:
x264 --preset veryslow --bitrate 8000 --profile high --level 5.1 --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --vbv-maxrate 8000 --vbv-bufsize 300000 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

2-pass:
x264 --preset veryslow --pass 1 --slow-firstpass --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

x264 --preset veryslow --pass 2 --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

[Asmodian]

When doing frame by frame comparisons you need to make sure you are not comparing different frame types. If you happen to compare an P frame to a B frame you can get a warped sense of the difference between encodes. This is easy to do because the different methods will make different frame type decisions.

[Sagittaire]

BUMP

I was doing some testing, and I compared screenshots of a Blu-Ray encoded with x264 Average Bitrate set to 8000, and a 2-pass set to 8000. In every screenshot I tested (my methodology was to use IrfanView to put up the same frame of the source, then both encodes, then click on window buttons to switch between them with them being displayed at actual size and overlaid exactly on top of each other; this I find is the absolute best way to compare), I saw changes to the image with the 2-pass encode and I saw no perceptible change using the 1-pass encode. I would not say the 2-pass looked worse, just different. Film grain seemed to blur in parts of the image, or change slightly. Some pixels seemed to noticeably shift slightly. But I was surprised to see the source image and the 1-pass encode look identical to each other on a near pixel-by-pixel basis.

So I'm not sure what's going on, maybe it's my command lines:

1-pass:
x264 --preset veryslow --bitrate 8000 --profile high --level 5.1 --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --vbv-maxrate 8000 --vbv-bufsize 300000 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

2-pass:
x264 --preset veryslow --pass 1 --slow-firstpass --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

x264 --preset veryslow --pass 2 --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -


Difficult to see difference simply beacuse 8 Mbps is really high bitrate for 1080p and x264.

[Z2697]

Difficult to see difference simply beacuse 8 Mbps is really high bitrate for 1080p and x264.

When said "film grain" is involved, that bitrate's probably not really that high

[excellentswordfight]

BUMP

I was doing some testing, and I compared screenshots of a Blu-Ray encoded with x264 Average Bitrate set to 8000, and a 2-pass set to 8000. In every screenshot I tested (my methodology was to use IrfanView to put up the same frame of the source, then both encodes, then click on window buttons to switch between them with them being displayed at actual size and overlaid exactly on top of each other; this I find is the absolute best way to compare), I saw changes to the image with the 2-pass encode and I saw no perceptible change using the 1-pass encode. I would not say the 2-pass looked worse, just different. Film grain seemed to blur in parts of the image, or change slightly. Some pixels seemed to noticeably shift slightly. But I was surprised to see the source image and the 1-pass encode look identical to each other on a near pixel-by-pixel basis.

So I'm not sure what's going on, maybe it's my command lines:

1-pass:
x264 --preset veryslow --bitrate 8000 --profile high --level 5.1 --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --vbv-maxrate 8000 --vbv-bufsize 300000 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

2-pass:
x264 --preset veryslow --pass 1 --slow-firstpass --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -

x264 --preset veryslow --pass 2 --bitrate 8000 --profile high --sync-lookahead 24 --ratetol 2.00 --qcomp 0.80 --ipratio 1.10 --pbratio 1.10 --no-dct-decimate --psy-rd 1.00:0.25 --aq-strength 0.50 --deadzone-inter 6 --deadzone-intra 6 --sar 1:1 --qpfile GENERATED_QP_FILE --deblock -2:-2 --non-deterministic --range tv --colorprim bt709 --transfer bt709 --colormatrix bt709 --stats "C:\Users\Admin\AppData\Local\Temp\Test.stats" --demuxer raw --input-res 1920x1080 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "C:\Users\Admin\AppData\Local\Temp\Test.264" -
How long is your sample? Is it the whole movie or just a segment?

You should have better bitrate distribution on the 2pass version, but that might not be relevant if the sample is short or are rather equal in complexity.

You can also feed your encodes through a bitrate analyzer so you can check the distribution yourself and also check the parts were the bitrate is different.