Const Quality or 2 Pass?

[killerteengohan]

I been using 2 pass and specific bitrates to get episodes to always be 300MB.

I hear using Const Quality aka VBR gives better results and then I also hear its not as accurate with bits and just randomly guesses in one pass, while 2 pass carefully calculates before it does its job.


I do like to control the file size in the end but I also want the better looking video results.

Would 17.0 const quality be better or would the specified bitrate and 2 passes to get 300MB be better?

Sometimes I see 17.0 being less bit rate than my 300MB amount I would use and under 300MB and sometimes I see it being more than 300MB and more bitrate than I would use to get 300MB.

Its totally random sizes and bitrates in the end.


Which is going to get me the better output video?

[mike20021969]

Its totally random sizes and bitrates in the end.

That's how Constant Quality works - more bit rate where it's needed, less where it doesn't.
I understand a value of 18~20 should be transparent with most sources.

Choosing 17 or less may bloat file size unnecessarily without any gain in (visual) quality.

Whether 2-pass or CQ gives better quality/file size is dependant on the content of the video.
e.g. cartoons may be better using CQ, an action movie may be better using 2-pass.

What is best for you can only be answered by one person...

[drjtech]

...just randomly guesses in one pass...

It does not "randomly guess". It calculates and sets the correct bitrate to maintain constant quality from scene to scene. The end result is not a random file size, but rather the optimum file size to maintain the desired quality.

[jagabo]

It's simple: 2-pass VBR gives you a known file size but unknown quality. Constant quality gives you a known quality but unknown file size. When the files sizes match the results are nearly identical quality.

2-pass VBR requires two passes because the encoder needs to know where the high and low bitrate frames are (the first pass). Then (the second pass) it the allocates bitrate to frames as necessary, low bitrate to frames that don't need a lot, high bitrate to frames that do need it. In the end, the average is the bitrate you specified.

Constant quality encoding doesn't need two passes. It just gives each frame the bitrate it needs as it encodes the video in a single pass.

[hello_hello]

If anything, I think 2 pass does the bitrate guessing, although it's not significant.

A couple of times I encoded video using a CRF value, then used the resulting bitrate for a 2 pass encode. I played both encodes simultaneously, watching the bitrates courtesy of ffdshow. If I remember correctly, the difference at any given time would only have been something like 10kbps or less, but I could watch the 2 pass encode sit consistently on a slightly higher bitrate than the CRF encode, then after a scene change it'd drop to a slightly lower bitrate for a while, then it'd switch back to a few kbps more later on, and so on....

I recall on one occasion the 2 pass encode used a noticeably higher bitrate on the end credits than the CRF encode, so I assume it was busy trying to hit the target bitrate by spending the extra bits it had saved. I guess the 2 pass encode would therefore have had better quality end credits.

[neomaine]

It's simple: 2-pass VBR gives you a known file size but unknown quality. Constant quality gives you a known quality but unknown file size. When the files sizes match the results are nearly identical quality.

2-pass VBR requires two passes because the encoder needs to know where the high and low bitrate frames are (the first pass). Then (the second pass) it the allocates bitrate to frames as necessary, low bitrate to frames that don't need a lot, high bitrate to frames that do need it. In the end, the average is the bitrate you specified.

Constant quality encoding doesn't need two passes. It just gives each frame the bitrate it needs as it encodes the video in a single pass.

The perfect sticky.

[killerteengohan]

I personally when playing side by side or pausing and taking screenshots for comparison am failing to notice any real quality difference between the two's output quality.

[manono]

The CRF 17 ones that are slightly larger than your two-pass encodes for 300MB will have a slightly better quality; the ones less than 300 MB will have slightly poorer quality.

I personally when playing side by side or pausing and taking screenshots for comparison am failing to notice any real quality difference between the two's output quality.

Then you might as well run single-pass CRF 17 encodes since you'll get results more quickly.

[_Al_]

It is NOT about that CRF is better than 2pass VBR or the other way. It is the same, same encoder, same settings. You are going to get the same result if both videos have the same volume.
The question - what is better, CRF or 2pass VBR, makes no sense, or maybe there are marginal differences, something like hello_hello observed. You need to encode to certain size, use 2pass VBR, you need to target quality use CRF and save time as well encoding. You work with certain kind of videos, and there is a chance you kind of find your CRF that gives you those roughly those 300MB. But think of it. To try to box every episode to strictly same volume makes no sense. Those are just numbers, you try to make it neat , humans might like it neat, orderly, but it makes no sense from quality point of view.

[jagabo]

In short: Use CRF when you want to be assured of quality. Use bitrate when you want to be assured of file size.

[fritzi93]

Regarding quality: if you encode to a target file size, you'll be under or over-compressing just about every time.

For example, I have all the Band of Brothers episodes encoded at crf20. File size varies from 4.36 to 8.48 GB. That's 9.9 Mb/s and 15.7 Mb/s, respectively (episode length varies). A considerable difference for similar material, shot the same way. So you can't *reliably* estimate how much bitrate is needed.

I've been meaning to re-do everything at crf18, but never seem to get around to it. It's not transparent at crf20, but it's not bad on a Sharp 70" at 8' viewing distance. It's only with something particularly demanding (like the last chapter of Zero Dark Thirty) that I can't help but notice.

Anyway, I'd advise experimenting with crf values to see what is acceptable for you.

[Kerry56]

What's interesting to me is that jdobbs seems to have found a way around this dichotomy in BD Rebuilder. It is possible to use his program in CRF mode and still hit specific target sizes. Granted, it may not be as accurate as a 2 pass encode, but still does well enough to remain under the limits of a single layer BD-R. If you screw with the settings and change the default CRF value, all bets are off however.

[poisondeathray]

What's interesting to me is that jdobbs seems to have found a way around this dichotomy in BD Rebuilder. It is possible to use his program in CRF mode and still hit specific target sizes. Granted, it may not be as accurate as a 2 pass encode, but still does well enough to remain under the limits of a single layer BD-R. If you screw with the settings and change the default CRF value, all bets are off however.

The program takes several CRF samples in this mode, tries to predict the size from the data

[Kerry56]

^Yes, I've read as much as I can find on his sampling technique, but it still seems a clever implementation, and something of a sidestep around the hard and fast dictum of CRF for quality and 2 pass for accurate sizes. But it is also a limited tactic, since the CRF value cannot be changed.

[jagabo]

^Yes, I've read as much as I can find on his sampling technique, but it still seems a clever implementation

It's probably the same thing that AutoGK did with Xvid: an AviSynth script using SelectRangeEvery() to sample a sequence of about 50 frames from about 20 different parts of the video. Old news.

[_Al_]

That is a way to go if someone is still rather focused on resulting bitrate and using CRF. Couple of brief samples, using avisynth or just some selected region using frame server from NLE.
x264 in CLI interface constantly shows average bitrate for that sample updated at a time. So there can be live feedback right on screen, so someone can very quickly terminate process if showing numbers are way off and then CRF can be corrected.

[Selur]

x264 in CLI interface constantly shows average bitrate for that sample updated at a time.

Does it show the average bitrate or the current bit rate? (thought it was the current bitrate)
-> cleared, it's the average bitrate so far

[killerteengohan]

The CRF 17 ones that are slightly larger than your two-pass encodes for 300MB will have a slightly better quality; the ones less than 300 MB will have slightly poorer quality.

I personally when playing side by side or pausing and taking screenshots for comparison am failing to notice any real quality difference between the two's output quality.

Then you might as well run single-pass CRF 17 encodes since you'll get results more quickly.

I don't see a 2 pass CRF choice in MeGui, its only been doing single passes.

[manono]

I don't see a 2 pass CRF choice in MeGui, its only been doing single passes.

You're quoting me as if I mentioned a 2-pass CRF option? If so you misread. CRF encoding is, by definition, single pass. The only 2-pass method I mentioned was your own bitrate/filesize-based one.

[Detmek]

I don't see a 2 pass CRF choice in MeGui, its only been doing single passes.

You don't need 2-pass CRF. Just use regular 2-pass. As already mentioned before, CRF and 2-pass at the same filesize (bitrate) will give you the same quality.

[Selur]

Only reason 2pass crf was used a few years ago was because crf didn't support vbv.