[x264] Do more than 2 passes improve quality?

[dbmaxpayne]

Hi,

I just wanted to know, if more than 2 passes improve quality on x264 encodes?

One time I've done a very very low bitrate encode (200kbit/s or something like that, i don't remember anymore) which gave me much better results with 6 passes than with 2.
But what about encoding normal DVDs with bitrates around 1800kbit/s?

Encoding time is not a problem by the way, I've got an 8-Core Intel Xeon Server for encoding. :-)

My commandline is always:
--preset placebo --tune file --b-pyramid normal --rc-lookahead 250 --aq-mode 2


Thanks in advance.

Mark

[Firebird]

I just wanted to know, if more than 2 passes improve quality on x264 encodes?

Nope.

[SeeMoreDigital]

Nope.Although I've often wondered if more than one analysis pass might...

[nurbs]

Isn't every pass except the last one also an analysis pass?

BTW --b-pyramid normal is used by default.

[Audionut]

Pass 2 doesn't overwrite the stats file, pass 3 does.

[dbmaxpayne]

Pass 2 doesn't overwrite the stats file, pass 3 does

yes, but you use it like that:
pass 1 = --pass 1
pass 2 = --pass 3
pass 3 = --pass 3
pass n = --pass 3
last pass = --pass 2


@DarkShikari (or another developer): What do you think about using more than two passes?

[Dark Shikari]

What do you think about using more than two passes?Useless waste of time. 99% of any benefit you'll get from it can be gotten by running the first pass with --slow-firstpass instead running a third pass, and even that benefit is tiny.

[dbmaxpayne]

ok, thanks for the quick reply.
because I'm using --preset placebo I will use 2passes now :-)

[dbmaxpayne]

anyway, for what special cases more passes would be useful?

[Dark Shikari]

anyway, for what special cases more passes would be useful?Heating your house if your heater is broken.

[dbmaxpayne]

ok.. :-D so why it is implemented in x264 if it has no benefit at all?

[Dark Shikari]

ok.. :-D so why it is implemented in x264 if it has no benefit at all?3-pass isn't implemented in x264. Rather, the ability to both read and write the statsfile at the same time is implemented in x264. This can be, among other things, used for stupid concepts like 3-pass, but it's not limited to that.

[Warperus]

Is it ok to do first pass once and then use stats file for several 2nd pass encodes with different bitrates?

[Dark Shikari]

Is it ok to do first pass once and then use stats file for several 2nd pass encodes with different bitrates?Yes, as long as the bitrates don't vary too wildly. For example, a first pass at 1000kbps and a second pass at 10000kbps would probably be too large a difference.

So if you want second passes at 1000kbps, 2500kbps, 5000kbps, and 10000kbps, do the first pass in the middle, e.g. at 3500kbps.

[kolak]

Useless waste of time. 99% of any benefit you'll get from it can be gotten by running the first pass with --slow-firstpass instead running a third pass, and even that benefit is tiny.

With Adaptive GOP (and other adaptive features) it does make more sense. CC-HDe improves quality quite a lot between 2nd and 3rd pass- more is waste of time. Its engine tries to flatten Q. You can see how Q is going to change before you encode. More passes you do the smaller change is.


Andrew

[Dark Shikari]

With Adaptive GOP (and other adaptive features) it does make more sense. CC-HDe improves quality quite a lot between 2nd and 3rd pass- more is waste of time. Its engine tries to flatten Q. You can see how Q is going to change before you encode. More passes you do the smaller change is.That just means the encoder is bad and can't figure out how to do things properly the first time around, not that 3-pass is actually useful.

"Adaptive GOP" is a buzzword for scenecut detection.

[kolak]

That just means the encoder is bad and can't figure out how to do things properly the first time around, not that 3-pass is actually useful.

"Adaptive GOP" is a buzzword for scenecut detection.

In case of encoding for BD it produces better results than x264, so definatelly you can't call it bad, otherwise x264 is "more" bad :)

Adaptive GOP is not only for scenecut detection- all (or most) encoders have scenecut detection, but only few of them "real" Adaptive GOP. Adaptive GOP works briliantly for fades, cross fades, flashes, high motion scenes and simmilar. In case of CC-HDe it tries thousands of possible GOP structures to minimize Q and that's why more than 2 passes are needed.
Can you find in 2 steps golden bitrate allocation for specific source? It is simmilar to looking for global minimum for some function- not easy.

Andrew

[Dark Shikari]

In case of encoding for BD it produces better results than x264, so definatelly you can't call it bad, otherwise x264 is "more" bad :)

Adaptive GOP is not only for scenecut detection- all (or most) encoders have scenecut detection, but only few of them "real" Adaptive GOP. Adaptive GOP works briliantly for fades, cross fades, flashes, high motion scenes and simmilar. In case of CC-HDe it tries thousands of possible GOP structures to minimize Q and that's why more than 2 passes are needed.
Can you find in 2 steps golden bitrate allocation for specific source? It is simmilar to looking for global minimum for some function- not easy.

AndrewCan you stop pasting marketing material for your favorite proprietary encoder in every single x264 thread on Doom9?

x264 has fade detection, flash detection, motion detection, and so forth and all work just fine in 1-pass mode.

[kolak]

Can you stop pasting marketing material for your favorite proprietary encoder in every single x264 thread on Doom9?

x264 has fade detection, flash detection, motion detection, and so forth and all work just fine in 1-pass mode.

It's disccussion about more than 2pass encoding and CC-HDe is one of the few encoders which does it, so it's very good example. There is nothing in the thread name about x264, so if you don't want to comment it, you don't have to. Not every thread here is about x264- is about AVC encoding and different fatures.

As I said- I have nothing to do with CT company, I don't sell CC-HDe- it's basicly the best AVC encoder (definately for BD usage), so I treat it as a reference one.
Can you stop being so offended if someone mention feature which x264 does not support or support worse/different than x264.
x264 achives very good quality in 2 pass mode, CC-HDe in 3, but still encoding time is shorter than x264. It's just a different approche- which is better or worse is actually part of this disscussion.


Andrew

[J_Darnley]

There is nothing in the thread name about x264

What? The thread is "[x264] Do more than 2 passes improve quality?" To which the simple answer is "No"

[kolak]

What? The thread is "[x264] Do more than 2 passes improve quality?" To which the simple answer is "No"

Sorry-yes. I didn't notice probably because of brackets.

[jethro]

As I said- I have nothing to do with CT company, I don't sell CC-HDe- it's basicly the best AVC encoder (definately for BD usage), so I treat it as a reference one.


Andrew

I would be interested in seeing where x264 "does bad" in BD scenario and what typical artifacts or problems at such high bitrate can be shown. That should be more persuasive rationale for improving x264 engine further for BD/low QP encoding.

[jpsdr]

@kolak
Encode a sample where you've find out problems, with both encoders, specifying the exact parameters used each time for encoding, and make it avaible, if possible. This way, x264 developpers may analyse the 2 streams, and find out any problem (if there is), and as jethro said, improve the x264 engine.

[Blue_MiSfit]

Yes. Sample pls.

Source, x264, and CC outputs, with detailed settings / prefiltering used.

~MiSfit

[kolak]

Yes. Sample pls.

Source, x264, and CC outputs, with detailed settings / prefiltering used.

~MiSfit

It's not as easy as taking first source, encode 5min and there is a problem. x264 is to good for this. I've already reported problem which I have noticed during my tests, but it seams to be known one.
I'll keep an eye on it :)

Andrew