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?
+ Reply to Thread
Results 1 to 21 of 21
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...
Last edited by mike20021969; 15th Jul 2014 at 11:18.
They that give up essential liberty to obtain a little temporary safety deserve neither liberty or safety.
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.
Last edited by jagabo; 15th Jul 2014 at 12:17.
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.
Have a good one,
NEW! VideoHelp.com F@H team 166011!
Folding@Home FAQ and download: http://folding.stanford.edu/
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.
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.
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.
In short: Use CRF when you want to be assured of quality. Use bitrate when you want to be assured of file size.
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.Pull! Bang! Darn!
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.
^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.
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.
x264 in CLI interface constantly shows average bitrate for that sample updated at a time.
-> cleared, it's the average bitrate so far
Last edited by Selur; 16th Jul 2014 at 04:14.users currently on my ignore list: deadrats, Stears555
Last edited by manono; 17th Jul 2014 at 05:04.
Only reason 2pass crf was used a few years ago was because crf didn't support vbv.users currently on my ignore list: deadrats, Stears555