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?
+ Reply to Thread
Results 1 to 20 of 20
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.
Last edited by jagabo; 12th Dec 2016 at 09:29.
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)
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.
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.
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 ...?
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.
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.
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.
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.
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?
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.
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.
Last edited by jagabo; 18th Dec 2016 at 17:41.
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.
Last edited by _Al_; 14th Dec 2016 at 17:59.
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.
The scaling factor is a constant based on the --crf argument.
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).
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 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.
Last edited by hello_hello; 18th Dec 2016 at 12:20.