would it make more sense to use 1 pass encoding instead of 2 with x265?

[zanzar]

i have an avisyth script that takes a lot of time to encode
i use Megui 2 pass encode (i think its the default)
the videos are like 20-30 min long (anime) and are upscaled from 480p to 720p (come times to 1080p)
it take a long time with two pass encode (about 3.5 hours for each pass)

i've read that the main difference is that with 2 pass encode you get a -better picture for the same file size- (or same bit rate)
and i wonder if it really matter for me? since i already make this videos at sizes 500-1000mb AND x265 ...

what do you say? because it can save me a lot of time

also if i want to do 1 pass with Megui , what do i need to do? just change the passes from 2 to 1 in the automated encoding setting?

[jagabo]

i've read that the main difference is that with 2 pass encode you get a -better picture for the same file size- (or same bit rate)

This is a fallacy based on the old style of single pass bitrate based encoding. With that method the encoder doesn't know what future frames will bring so it can't optimize bitrate distribution over the entire file. But with modern constant quality encoding (CRF in x264 and x265) this is no longer the case.

With 2-pass encoding you know what the file size will be but you don't know what the quality will be. With single pass CRF encoding you know what the quality will be but you don't know what the size will be. When the file size is the same the quality is the same.

[zanzar]

i've read that the main difference is that with 2 pass encode you get a -better picture for the same file size- (or same bit rate)

This is a fallacy based on the old style of single pass bitrate based encoding. With that method the encoder doesn't know what future frames will bring so it can't optimize bitrate distribution over the entire file. But with modern constant quality encoding (CRF in x264 and x265) this is no longer the case.

With 2-pass encoding you know what the file size will be but you don't know what the quality will be. With single pass CRF encoding you know what the quality will be but you don't know what the size will be. When the file size is the same the quality is the same.

i now noticed i cant lower to passes to 1 from 2 in the settings in the auto encoding settings ...
thats because only there i can set the file size i want ...

in short i can only set the wanted file size with 2 pass encoding with the 1 pass i just choose the quality (a number) and preset (which i dont know what is for and what it affects)

[jagabo]

Why do you care about the exact file size? The only time you really need a specific file size is when trying to fit a video on a CD or DVD. For example, if you need a 715 MB video to fit on a CD-R you want to use 2-pass bitrate based encoding to assure you have the right size with the best quality (for that size). Using CRF based encoding for that would take you several encodes to figure out the right CRF value to get that file size (and it will be different with every video).

But when you don't need an exact file size you should use CRF based encoding. You pick the quality you want and the encoder uses whatever bitrate is necessary to deliver that quality. Run a few test encodes of short videos at different CRF values to what CRF value delivers the quality you want.

[sneaker]

in short i can only set the wanted file size with 2 pass encoding with the 1 pass i just choose the quality (a number) and preset (which i dont know what is for and what it affects)

I believe it uses the encoder settings from the main window, i.e. you select "x265 *scratchpad*" -> "Config" and create a profile there.
A) You can set "ABR" for single-pass target bitrate.
B) Another tipp: you can set "Automated 2pass" and in the "Misc" tab add the extra option "--no-slow-firstpass". Then it will use a turbo first pass. It will save you time yet be almost as optimal as the "normal" 2 pass.
C) You can set CRF encoding there as explained by jagabo. I also recommend this.

[zanzar]

Why do you care about the exact file size? The only time you really need a specific file size is when trying to fit a video on a CD or DVD. For example, if you need a 715 MB video to fit on a CD-R you want to use 2-pass bitrate based encoding to assure you have the right size with the best quality (for that size). Using CRF based encoding for that would take you several encodes to figure out the right CRF value to get that file size (and it will be different with every video).

But when you don't need an exact file size you should use CRF based encoding. You pick the quality you want and the encoder uses whatever bitrate is necessary to deliver that quality. Run a few test encodes of short videos at different CRF values to what CRF value delivers the quality you want.

essentially there would be no difference in quality between 2 pass and CRF if i use high bit rate?

also can i use the "ABR" target bit rate option instead of "constant quality"?
with it , it woud be easier for me to hit the quality i want

so for short i should make "ABR" 1 pass encodes with high bit rate(not crazy bit rates but the ones that came out with the 2 pass encoding ,1500-4000) to save time ...?

[johnmeyer]

I am not an encoding guru, but I don't see how any single-pass encoder -- including "constant quality -- could ever allocate the bits anywhere near as intelligently as a two-pass algorithm could. For instance, if I have a ten minute video, the first half of which shows close-ups of the running of the bulls, and the second half shows a static shot, taken on a tripod, of a building, with no motion whatsoever, then the encoder that doesn't know about the total lack of motion in the second five minutes will under-allocate bits for the first five minutes. I don't see how it could be otherwise.

[jagabo]

essentially there would be no difference in quality between 2 pass and CRF if i use high bit rate?

There would be little difference at any bitrate. Of course, if you use very low bitrates they both will look like crap compared the original.

also can i use the "ABR" target bit rate option instead of "constant quality"?

No. ABR is the worst way to encode. Like 2-pass VBR it doesn't assure quality, only file size. Overall, it will deliver worse quality than 2-pass VBR. It will give too much bitrate to shots that don't need it, and too little bitrate to shots that do.

with it , it woud be easier for me to hit the quality i want

No it would not. It would only allow you to get the size you want. You can't predict the quality well because different videos require different bitrates to maintain quality.

[sneaker]

I am not an encoding guru, but I don't see how any single-pass encoder -- including "constant quality -- could ever allocate the bits anywhere near as intelligently as a two-pass algorithm could. For instance, if I have a ten minute video, the first half of which shows close-ups of the running of the bulls, and the second half shows a static shot, taken on a tripod, of a building, with no motion whatsoever, then the encoder that doesn't know about the total lack of motion in the second five minutes will under-allocate bits for the first five minutes. I don't see how it could be otherwise.

CRF doesn't try to hit a specific average bitrate (read: file size) so it won't under-allocate anything. It will put many bits into the first part and few bits into the second part.
For an algorithm that does want to hit a specific average bitrate in a single pass (--bitrate without multiple passes) you are correct. That's why they are usually not recommended. But luckily, your example is an extreme case that doesn't happen a lot with real-world movies.

[johnmeyer]

CRF doesn't try to hit a specific average bitrate (read: file size) so it won't under-allocate anything. It will put many bits into the first part and few bits into the second part. For an algorithm that does want to hit a specific average bitrate in a single pass (--bitrate without multiple passes) you are correct. That's why they are usually not recommended. But luckily, your example is an extreme case that doesn't happen a lot with real-world movies.

OK, I think I get it: constant quality doesn't care about file size. I think that was what I was missing. So, if I am now understanding correctly, a constant-quality video encoder will add however many bits are needed to achieve a certain level of quality. Therefore, if there is a massive amount of motion for the entire video, the resulting file will be much larger than if the same settings were used to encode a video that contained nothing but a static shot of a building, like what I described in my earlier post.

I guess the only question then is how well the algorithm works which has to maintain a level of quality. I guess the answer must be that it works pretty darned well.

Thanks for helping me understand.

[sneaker]

OK, I think I get it: constant quality doesn't care about file size.

--crf does not, correct. (Technically, multi-pass --bitrate is also constant quality. Just constant quality trying to hit a specific average bitrate.)

I think that was what I was missing. So, if I am now understanding correctly, a constant-quality video encoder will add however many bits are needed to achieve a certain level of quality. Therefore, if there is a massive amount of motion for the entire video, the resulting file will be much larger than if the same settings were used to encode a video that contained nothing but a static shot of a building, like what I described in my earlier post.

Correct.

I guess the only question then is how well the algorithm works which has to maintain a level of quality. I guess the answer must be that it works pretty darned well.

For x264 and I assume x265 the algorithms for CRF and multi-pass bitrate are almost identical. (Like said above: multi-pass bitrate is technically also constant quality.)

[_Al_]

OK, I think I get it: constant quality doesn't care about file size. I think that was what I was missing. So, if I am now understanding correctly, a constant-quality video encoder will add however many bits are needed to achieve a certain level of quality. Therefore, if there is a massive amount of motion for the entire video, the resulting file will be much larger than if the same settings were used to encode a video that contained nothing but a static shot of a building, like what I described in my earlier post.

I guess the only question then is how well the algorithm works which has to maintain a level of quality. I guess the answer must be that it works pretty darned well.

Thanks for helping me understand.

Those algorithms are the same for CRF and for second 2pass. It works the same for both cases. In the first case you have CRF value chosen, and for that second two pass, think of it that alghorithm calculates it for a given bitrate. You end up with the same result if both methods gives you file of the same size. Sure never to the last bits, but almost the same.

Also you described --qp, not --crf, crf increases quantizer while there is abrupt movement because to keep quality makes no sense , we humans would not register details anyway and encoding is a cover up business, if you do not notice, get rid of it. If you want to have quantizer kept the same even with those scenes, use --qp values. But you are going to have filesizes much larger if videos have lots of action in it.

[sneaker]

Sure never to the last bits, but almost the same.

The differences are bigger than what you would expect. There are adjustments going on constantly. Without those adjustments the target will be missed quite a bit. This also means: CRF is actually slightly better than multi-pass at distributing bits, unlike what many people believe.

[_Al_]

So first pass just calculates, say, a relative "coefficients" ( is that what is stored in STATS file? ) and does not work with average bitrate yet. Could also those "coefficients" mean a relative quantizer right away because there is a linear relationship? Is it second pass that gets target bitrate for a scene (based on average and that "coefficient" ) and gets CRF value to shoot to get a target hopefully. If it is not happening right away , how often does it controls that target? Does it have any loop control setup of this sort just having procedure to get quantizer as closer to bitrate as it gets (allowing certain number of attempts?) so statistically it overshoots or undershoots (a tiny bit) so overall it is again close to average? That seams unscientific though. Or that "coefficient" for a frame has a linear relationship with quantizer and basically we know those quantizers after 1pass right away and those "loops" are happening fishing for that correct "coefficient/quantizer" during 1st pass?

[sneaker]

You've got me there - I don't know it in that detail. I assume it constantly measures target bitrate and actual bitrate and re-adjust the CRF for every frame to adjust. How exactly? IDK.

[jagabo]

I am not an encoding guru, but I don't see how any single-pass encoder -- including "constant quality -- could ever allocate the bits anywhere near as intelligently as a two-pass algorithm could.

It's obvious once you know how a 2-pass encoder works. The first pass is a constant quantizer (or constant rate factor in x264) encoding at some moderate quantizer setting. The encoder then knows how much bitrate each frame needs relative to others. During the second pass it uses that information to allocate bitrate to meet the requested average bitrate, matching the CQ encode proportionally. Ie, if you ask for half the bitrate of the CQ encode it will shoot for half as much bitrate at each frame.

[sneaker]

The first pass is a constant quantizer (or constant rate factor in x264) encoding at some moderate quantizer setting

You can do that but most people use --bitrate xxx --pass 1, not --crf or --qp for the first pass.

[jagabo]

The first pass is a constant quantizer (or constant rate factor in x264) encoding at some moderate quantizer setting

You can do that but most people use --bitrate xxx --pass 1, not --crf or --qp for the first pass.

But it's still the same basic principle. It encodes the video once, keeping track of quantizers and and bitrate, then encodes again using that information to distribute bitrate to where it's needed. The end result will still be similar to the CRF encode even though the initial ABR encoding has worse bitrate distribution. Differences may be more pronounced if you work at very extreme bitrates.

Here's an example:


[Attachment 39901 - Click to enlarge]

Bitrate Viewer is in GOP mode so each bar represents one GOP. The source video is a silent film with lots of scratches, flickering, etc. But the titles have been replaced with noise free placards. The second and last GOPs are those noiseless placards, the others are the original film.

At the top of the image is a CRF23 encoding. You can see that it allocated very little bitrate to the placards, much more to the other GOPs. In the middle is the first pass of a 2-pass encoding using ABR encoding. You can see it under allocated (relative to the CRF encoding) bits to the first GOP, over allocated to the second GOP, over allocated to the third GOP, etc. At the bottom is the result of the second pass. You can see that it has "corrected" those over/under allocations and produced a bitrate distribution much more similar to the CRF encoding.

[_Al_]

So the question is, how does it get that constant quantizer relation throughout the whole video out of this, that is stored in stats file? I think, 1st pass gets discarded before second pass even starts.

Or how do they get that "coefficient" , not sure how to call it, value that establishes a scene relative complexity, that value that helps to calculate that local bitrate during second pass?

Is there a simple proportion like CRF(during 1st pass) / bitrate(during 1st pass) = CRF(known constant value) / bitrate(new) , to get that bitrate(new) out of this equasion to store in stats file?

And then just allocating actual bitrate during 2pass from that virtual bitrate(new) ? Simple proportion as well I guess.

[hello_hello]

Here's the best explanation I've found for x264's rate control methods. I re-wrote it a while back to help me get it straight in my head so it's not quoted as it was originally written. The link below provides the original, more detailed version. This is a summary.

A qualitative overview of x264's ratecontrol methods

Step 1, Determine Frame Complexity
2 pass encoding:
Before starting the 2nd pass, select the relative number of bits to allocate between frames. This pays no attention to the total size of the encode. The default formula, empirically selected to balance between the 1st 2 theoretical points, is "complexity ** 0.6", where complexity is defined to be the bit size of the frame at a constant QP (estimated from the 1st pass).

CRF and ABR encoding:
This is the same as in 2pass, except that instead of estimating complexity from a previous encode, we run a fast motion estimation algo over a half-resolution version of the frame, and use the SATD residuals (these are also used in the decision between P- and B-frames). Also, we don't know the size or complexity of the following GOP, so I-frame bonus is based on the past.

Step 2, Determine Scaling Factor
2 pass encoding:
Scale the results of step one to fill the requested total size.

CRF encoding:
The scaling factor is a constant based on the --crf argument.

ABR encoding:
We don't know the complexities of future frames, so we can only scale based on the past. The scaling factor is chosen to be the one that would have resulted in the desired bitrate if it had been applied to all frames so far.

Step 3, Overflow Compensation
2 pass and ABR encoding:
Now start encoding. After each frame, update future QPs to compensate for mispredictions in size. If the 2nd pass is consistently off from the predicted size (usually because we use slower compression options than the 1st pass), then we multiply all future frames' qscales by the reciprocal of the error. Additionally, there is a short-term compensation to prevent us from deviating too far from the desired size near the beginning (when we don't have much data for the global compensation) and near the end (when global doesn't have time to react).

CRF encoding:
No overflow compensation is done.

When I've compared CRF and 2 pass, the only time there's been perceivable differences in quality is in extreme situations.
ie Short sources that change in complexity quickly and are encoded at way too low a bitrate or using a way too high CRF value. In that sort of situation you might see 2 pass do a slightly better job than CRF (I assume because it doesn't have to guess regarding the I-Frame bonus) but it's not representative of normal encoding.
I'm not sure why, but single pass ABR doesn't always do as good a job at distributing the quality within a frame as 2 pass or CRF in extreme situations (check my previous link and scroll up a couple of posts for some pics).
At reasonable bitrates and CRF values though, there's virtually no difference between 2 pass and CRF in respect to perceived quality (at the same average bitrate). I've encoded both and run them side by side with ffdshow displaying the bitrates and they only vary by a tiny amount. 2 pass might be 20kbps lower than CRF for a few scenes, then it's 10kbps higher for a few, then it's a little lower again etc. I did notice the 2 pass bitrate increase by more than a tiny amount amount over CRF close to the end of one encode. I guess 2 pass saved too many bits and was busy spending them. At least the quality of the credits would have been high.