x264 + 3 pass (Various Questions)!

[Terranigma]

Hi, i'm trying to figure out what'd be the most essential way to do 3 passes to try and get the most out of my specified bitrates. I have a couple of ideas, but I need assurance that i'm on the right path.

1. Would there be a large variable bitrate difference between using 3 passes over 2?

2. Which one of these would be more suitable for 3 passes?
(crf = Constant Quality : qp = Constant Quantizer : abr = Average Bitrate)
If I type the following
crf - qp - abr
crf would be 1st pass, qp would be 2nd pass, abr would be 3rd pass.

Now for the selections

crf - qp - abr
crf - crf - abr
crf - abr - abr
qp - crf - abr
qp - qp - abr
qp - abr - abr
crf - crf - crf
qp - qp - qp


I have a theory on what'd be more suitable, but i'll hold that to myself 'til I get a confirmation by some experts :D

3. Would it be unwise for me to change the M.E. Algorithm for the 3rd pass from "Exhaustive" to "Multi hex" if I used Exhaustive for the first 2 passes?

Those would be all for now. :)

[nurbs]

1. The difference between 2 and 3 pass is minimal. It might help some if you use a really small bitrate.

2. Most of your proposed settings make no sense. If you want a specific filesize you do 2 (or 3) abr passes. If you don't care about filesize you do crf or cqp (1 pass). You could also do a crf encode and use that bitrate for the second pass (abr) if you tell the encoder to write stats for the first one. Both this and doing 3 passes is probably a waste of time.

3. Don't know. But there is only a small difference in quality between exhaustive and multihex. The former is much slower of course.

[burfadel]

Exhaustive is not just much slower, its overkill! I tried it on a few encodes of 10 minutes each, in most cases the file size was literally only a few bytes difference. This was using constant quality mode, so the better settings go in to reducing file size and not quality. even if you used an ABR, the quality difference between Multi-hex and exhaustive is not humanly perceivable even with zoom! I guess akupenguin would be best to comment on this. but I have heard that it was only included to show it can be done rather than be a practical encoding solution :)

If you have it on exhaustive I take it all your other settings are maxed out too? including reference frames and b-frames? That would take a very long encoding time, especially on high definition content!

It would be better setting the ref frames to 16 rather than use exhaustive search!

[Terranigma]

2. Most of your proposed settings make no sense. If you want a specific filesize you do 2 (or 3) abr passes. If you don't care about filesize you do crf or cqp (1 pass). You could also do a crf encode and use that bitrate for the second pass (abr) if you tell the encoder to write stats for the first one. Both this and doing 3 passes is probably a waste of time.

Well, I use crf for the first pass, and abr for the 2nd pass. I've never done 3 passes because I was satisfied with 2 passes. Thanks for the Input :)


If you have it on exhaustive I take it all your other settings are maxed out too? including reference frames and b-frames? That would take a very long encoding time, especially on high definition content!

It would be better setting the ref frames to 16 rather than use exhaustive search!
Yes, all other settings are maxed out too, but I don't mind the time it takes since I get around 2-3 fps, which I think is pretty good. :D

The point of this post was to basically acquire more info about rate control, and what'd be better suited when used in multiple passes.

Time isn't of the essence, quality is :p

[PuzZLeR]

1. Very little difference between 3 and 2 passes. Not sure of the tech behind it, but the 3rd pass is basically useful for very small files of maybe under 30 seconds long where a 2-pass scheme may not have enough "runway" to "adjust" to optimal quality.

2. Most of the possible combinations would be redundant anyway. Not sure though, but if there's some log/stats/work file that is passed on to the next pass it could be useful, otherwise the next pass would be a waste of time if it disregards the previous pass'es work.

3. In my experience with x264, mathematically speaking, the curve for quality rate is rarely (negatively) proportional to the rate of speed for slower settings (if at all). In other words, slower settings can be exponentially slower in speed when the quality may be just slightly higher.

Yes, I believe that quality is more of an essense than time, however I have recently started to reconsider that when the quality increase may be 1% for maybe 300% more CPU time, especially if your have a high volume of video you wish to encode. Find a balance of tolerance between the two.

[Terranigma]

Thanks PuzZLeR, you answered my questions.
:cool:

[Terranigma]

actually, I think akupenguin made it so that crf and qp can only be used in the first pass ;)

[audyovydeo]

1. Very little difference between 3 and 2 passes. Not sure of the tech behind it, but the 3rd pass is basically useful for very small files of maybe under 30 seconds long where a 2-pass scheme may not have enough "runway" to "adjust" to optimal quality.

This is something I've been mulling over and had been planning to ask about. Since h/x264's work is essentially statistical, it must follow that the longer the sequence the better it works.
Since I mainly work with very short sequences (30sec to 5min), I am wondering if x264 even has the time to do its statistical work.
To put it more formally : what is the minimum number of frames a movie sequence must have in order for x264 to correctly apply its formulas ? Intuitively, if max GOP is 250, it must be, at the very very least, that number. But I'm thinking it should be several times that : after all, if x264 unit of work is the GOP, then a statistical sample of 1 is pretty useless.

Any idea ?



Yes, I believe that quality is more of an essense than time, however I have recently started to reconsider that when the quality increase may be 1% for maybe 300% more CPU time, especially if your have a high volume of video you wish to encode. Find a balance of tolerance between the two.

ha ha ! reminds me of another recent thread : I loved your analogy work/vs/salary-)

(which in turn reminds me of an old joke where employee goes to boss "if you dont give me a pay increase I'll tell everyone that you gave me one".)


audyovydeo

[akupenguin]

To put it more formally : what is the minimum number of frames a movie sequence must have in order for x264 to correctly apply its formulas ?
There are two parts to this.
* Training the predictors. This takes maybe 10 frames to stabilize. (Note that the frames have to have content; e.g. if a movie starts with blackness, that doesn't count.)
* Amortizing prediction error. There is no particular threshold for this, it just asymptotically improves as 1/sqrt(frames). In 2pass this counts against filesize accuracy, and in ABR this counts against both quality and filesize accuracy.

Intuitively, if max GOP is 250, it must be, at the very very least, that number. But I'm thinking it should be several times that : after all, if x264 unit of work is the GOP, then a statistical sample of 1 is pretty useless.
The x264 ratecontrol's unit of work is 1 frame. It does treat I-frames specially, but it does not care about GOPs.
Some computations are performed separately for each frame type, so the first few I-frames may be inaccurately predicted even after than P- and B-frame predictors are stabilized. But that doesn't necessarily reduce quality, it only contributes to filesize inaccuracy. Since I-frames' QPs aren't very dependent on their own complexity, but mostly on the nearby P-frames.

Insofar as GOPs matter, the number to look at is how big the GOPs in your movie are, not what the max allowed is. But ratecontrol doesn't suddenly stop working even if your movie is a single 100000 frame long scene. On the contrary, I would guess that given a constant total number of frames, a movie that divided those frames into fewer different scenes would allow more accurate ratecontrol.

[audyovydeo]

mister aku,

currently travelling w/limited access, but wanted to thank you for reply.

audyovydeo