3-pass encoding question

[greyfax]

I apologize ahead of time if this is posted in the wrong place - this is my first post.

I used Handbrake to get familiar with the basics but now I am interested in experimenting with 3-pass encoding. There is no option for more than 2-pass in Handbrake, but is there a command you can type in the box under the Advanced tab to get it to do a 3-pass encode, or am I going to have to switch to MeGUI or StaxRip to do so?

:thanks:

[Slitheen]

There's no point in three pass encoding. Use a slower preset if you want better quality.

[greyfax]

Well that didn't answer my question at all. I wasn't asking whether or not it was worth it. The research and opinions I've gotten so far lead me to a different conclusion. Is it *much* of a gain? No. But is it zero gain? No.

I have a friend who is quite experienced in encoding who tests his results on 50" and 70" screens, and says that there definitely IS a difference when you're playing back on a screen that size and encoding at lower bitrates. I've also found several articles and threads that have indicated that a single pass might give you around 65% or so of the optimal quality outcome, 2-pass yielding 90%+ and 3-pass yielding 95%+. The consensus seems to be that a 4th pass seems to be the point of real diminishing returns, not 3. So, I've already decided it's something I want to try and at least find out for myself instead of taking someone's word for it.

So, is there anyone who can actually answer my question for me please?

[xooyoozoo]

I've also found several articles and threads that have indicated that a single pass might give you around 65% or so of the optimal quality outcome, 2-pass yielding 90%+ and 3-pass yielding 95%+

Those numbers have zero basis in reality. Edit: There are plenty of this forum who would gladly double their encode times for even a 2% bump in quality per bit. The reason they don't is because they can't: when the diminishing return wall hits, it hits hard. Slitheen was only trying to help you.

So, is there anyone who can actually answer my question for me please?

Handbrake won't be able to what you want through its GUI. Maybe it can do so through its CLI, but at that point, I'd just stop and take a look at ffmpeg instead.

[greyfax]

So what you're saying is (and I'm not being snarky here, honestly) is that Judas is just mistaken when he claims he can see a difference between an otherwise identical 2-pass vs 3-pass low bitrate (2250kbps) 1080p encode on a 50-70" screen? And that the multiple comments Ive seen that claim several percent improvement are either out of date or wrong? I'm fine with that if that's what you're saying. I'm not being defensive or sarcastic here. I just want to be absolutely clear about understanding what you're saying.

[Selur]

my 2 cents:
I have never seen a real life example where 2 vs. 3pass really made a visible difference.
Those who claim that they really can see a difference between a 2pass and 3pass encoding with x264 should post an example so others can judge for themselves.
Personally I only managed to create some visual differences with a short < 30 seconds sample which includes lots of randomly connected scenes, years ago.
-> tell your friend to post an example with settings that allow others to reproduce his findings.
(if there are examples where 3pass really helps, GUI developers will add support for 3pass encoding)

Cu Selur

[greyfax]

Ok, thank you.

I do have two other (hopefully) quick and easy questions.

1) I understand that using subme=10 requires aq-mode > 0 and trellis=2. There's a selectable setting in Handbrake for both subme and trellis, but I don't see anything for aq-mode, nor does aq-mode=1 appear in the command line when I set subme=10. So with Handbrake, do I have to type aq-mode=1 into the command line when I set subme=10 or does it do that automatically behind the scenes?

2) I was wondering about the "pass" setting and the difference between pass=2 and pass=3. I realize this is *not* a setting to differentiate 2-pass vs. 3-pass, but could someone explain what benefit, if any, there is to setting pass to 3 instead of 2 when doing a 2-pass encode? And will Handbrake recognize "pass=3" in the command line if I type it in manually? (Like aq-mode, there doesn't appear to be a selectable setting for this in Handbrake other than typing into the command line under the Advanced tab.) The description of this setting in the x264 wiki was a bit ambiguous which is why I'd like some clarification. All it says is that 2 means "Read the stats file. Use this on the final pass" and a setting of 3 means "Read the stats file, and update it as well."

[kypec]

Maybe I'm wrong but I'd suggest to try --slow-firstpass option in the first pass instead - perhaps the better stats gathered with this option turned on can compensate for additional "improvements" that --pass=3 would otherwise make during stats file update. The final visual quality of such slow 2-pass encode can probably reach that of the 3-pass encode...

[greyfax]

With Handbrake slow-firstpass is default unless "Turbo first Pass" is checked. I am already using manual settings that match up with the veryslow preset except for lower ref value to maintain more device compatibility.

I'd still be grateful for an answer to my pass=3 and aq_mode=1 questions though. :D

[sneaker_ger]

The description of this setting in the x264 wiki was a bit ambiguous which is why I'd like some clarification. All it says is that 2 means "Read the stats file. Use this on the final pass" and a setting of 3 means "Read the stats file, and update it as well."

If the stats file is not updated then the pass did nothing to improve the following pass. So if you want to do e.g. 5 passes you would use:

--pass 1
--pass 3
--pass 3
--pass 3
--pass 2 (or --pass 3)

That's all there is to it. But that's for x264(cli), no clue about HandBrake.

[Selur]

yup, sorry, no clue here either regarding the use of handbrake.

[greyfax]

If the stats file is not updated then the pass did nothing to improve the following pass. So if you want to do e.g. 5 passes you would use:

--pass 1
--pass 3
--pass 3
--pass 3
--pass 2 (or --pass 3)

That's all there is to it. But that's for x264(cli), no clue about HandBrake.

Thanks for this! If I'm understanding then, "--pass 3" wouldn't even be used unless you were doing more than 2 passes. Otherwise it would be --pass 1 for first pass and --pass 2 for second, yes?

Also, I think I figured out the answer to my aq-mode question. I took a look at the settings used by some of the better encoders out there and when looking with MediaInfo I see that there's no aq_mode=1 there when they use QPRD (subme=10) so I'm assuming that setting subme=10 automatically causes aq_mode to =1... but if someone knows differently please let me know. :thanks:

[detmek]

You can use --pass 3 command even in 2-pass encodeing mode. Difference between --pass 2 and --pass 3 is that pass 2 just reads stats file while pass 3 reads and updates stats file.

aq-mode 1 is default for x264, except for --preset ultrafast, so it is always on. Unless your encoder/GUI changes x264 defaults.

[paradoxical]

I've also found several articles and threads that have indicated that a single pass might give you around 65% or so of the optimal quality outcome, 2-pass yielding 90%+ and 3-pass yielding 95%+.

Then they are telling you nonsense. The only reason to use 2-pass over 1-pass CRF is to hit a specific size. The only benefit to 3-pass is if you might need an even more exact size than 2-pass would do. That's it.

Such figures might, and that's a big might, have been closer to reality with something like XviD, but it's not with x264.

[detmek]

Maybe in those articles they were comparing 1-pass ABR vs 2-pass mode.

[greyfax]

It wasn't CRF, it was with setting the bitrate manually.

I found the conversation I had with Judas and here is what he said about it. I'd be interested in hearing reactions.

"Yes I do use the slowpass command, but I also enable and run a n pass where N is 3... In total I actually do 3 full passes as well. The disadvantage of which means it takes obviously a full pass longer to finish up an encode, the advantage of which is overall a more accurate/better resulting encode. However using n pass is a diminishing return situation, the more passes you do, the less and less of an advantage/improvement you get. After doing several encodes, I found that moving from 2 passes to 3 passes produced on some still images up to about 15% more accurate images (pixel placement and color) as well as prediction, this is also shown quite a bit for high motion situations. Moving from 3 pass to 4 was basically just wasting time with only low single digit improvement using computer analyses to even detect the differences. To the human eye at that point it was totally unnecessary.

this is where it is usually argued by most encoders I've ran into that the human eye isn't likely to pick up a difference between 2 pass and 3 pass even, I beg to differ, specially when you start playing back a movie that is highly compressed at this level on something as larger as 55 inch or larger, I've already played back my encodes and yify's encode (as an example) on a 70" HDTV which makes Per pixel clarity a real necessity. Granted mine are nowhere near perfect.. they are very CLEARLY obviously superior to that of say yify's. But it's not much of a fair fight considering yify is using a lower video bitrate, and almost all if not near 95% of the yify encodes are sourced from publichd or other encoders files ranging from 6 to 12GB in size, where as mine are all DIRECT from bluray."

[greyfax]

You can use --pass 3 command even in 2-pass encodeing mode. Difference between --pass 2 and --pass 3 is that pass 2 just reads stats file while pass 3 reads and updates stats file.

aq-mode 1 is default for x264, except for --preset ultrafast, so it is always on. Unless your encoder/GUI changes x264 defaults.

Thank you detmek - that's what I needed to know. Does --pass 3 give you better results than --pass 2 though?

[paradoxical]

Maybe in those articles they were comparing 1-pass ABR vs 2-pass mode.

Even so those figures would still be wildly wrong.

this is where it is usually argued by most encoders I've ran into that the human eye isn't likely to pick up a difference between 2 pass and 3 pass even, I beg to differ, specially when you start playing back a movie that is highly compressed at this level on something as larger as 55 inch or larger, I've already played back my encodes and yify's encode (as an example) on a 70" HDTV which makes Per pixel clarity a real necessity. Granted mine are nowhere near perfect.. they are very CLEARLY obviously superior to that of say yify's. But it's not much of a fair fight considering yify is using a lower video bitrate, and almost all if not near 95% of the yify encodes are sourced from publichd or other encoders files ranging from 6 to 12GB in size, where as mine are all DIRECT from bluray."

And you did proper double-blind testing to reach your conclusions, right? Otherwise your results were most likely biased by you knowing which sample you were watching. People routinely see things that aren't really there by having a preconceived notion that one sample is going to be better than another. This is like making claims about how you can hear the difference between 96khz and 192khz audio without doing proper ABX testing.

[paradoxical]

And just to test I encoded both a 1-pass, 2-pass and 3-pass version of the HD version of Big Buck Bunny on a couple of 12-core servers I have. The only settings I used were --preset veryslow and --tune animation and a bitrate of 3000. The objective metric figures for each were:

1-pass fast
SSIM Mean Y:0.9676514 (14.901db)
PSNR Mean Y:40.532 U:43.742 V:45.038 Avg:41.404 Global:39.489 kb/s: 2880.78fast:

1-pass slow:
SSIM Mean Y:0.9752903 (16.071db)
PSNR Mean Y:41.821 U:45.011 V:46.287 Avg:42.694 Global:40.844 kb/s: 2878.21

2-pass:
SSIM Mean Y:0.9784479 (16.665db)
PSNR Mean Y:41.874 U:45.043 V:46.268 Avg:42.741 Global:41.545 kb/s: 2998.00

3-pass:
SSIM Mean Y:0.9784546 (16.666db)
PSNR Mean Y:41.876 U:45.047 V:46.272 Avg:42.744 Global:41.545 kb/s: 2998.72

Comparing images using the Subtract function of Avisynth gave basically almost perfectly gray images between 3-pass and 2-pass for the vast majority of frames. Slow 1-pass and 2-pass/3-pass was a slightly more visible difference depending on the frame but when compared with the original frames the difference was next to impossible when flipping between them. Fast 1-pass gave more visible when I subtracted, but when comparing the original frames again the difference didn't really show up unless doing more than a 4x zoom.

Most of the diff frames looked like this:

http://imageshack.us/a/img707/6250/testdiff.th.png (http://imageshack.us/photo/my-images/707/testdiff.png/)

The biggest difference frames looked like this when subtracted:

http://imageshack.us/a/img51/5162/testdiff2.th.png (http://imageshack.us/photo/my-images/51/testdiff2.png/)

Now that might look like a huge difference but here are the original frames that were used to make that diff image (note those aren't I-frames just to try to bias for the 3-pass version):

http://imageshack.us/a/img688/3290/testshotf.th.png (http://imageshack.us/photo/my-images/688/testshotf.png/)
http://imageshack.us/a/img35/328/testshotd.th.png (http://imageshack.us/photo/my-images/35/testshotd.png/)

There are differences but they aren't major and they are especially hardly noticeable at all when in motion even on a 65" TV which I then used to watch sample sections. Please tell me which you think is the 2-pass and which is the 3-pass if you think you can.

That person's claim just doesn't really seem to play out in reality. But if you're so convinced that a .003 average PSNR and .0000067 mean SSIM difference equates to 3-pass being "15% better" then feel free wasting your time doing 3-pass encoding.

[greyfax]

And you did proper double-blind testing to reach your conclusions, right? Otherwise your results were most likely biased by you knowing which sample you were watching. People routinely see things that aren't really there by having a preconceived notion that one sample is going to be better than another. This is like making claims about how you can hear the difference between 96khz and 192khz audio without doing proper ABX testing.

Well like I said, that wasn't what I said, it was a quote from an email exchange I had with Judas. And from this, "Moving from 3 pass to 4 was basically just wasting time with only low single digit improvement using computer analyses to even detect the differences" it sounds like he wasn't just relying on his eyes and did do some computer analysis. Point is well taken though.

I am a skeptic, so I understand and value the notion of eliminating subjectivity as much as possible and relying on evidence to base one's conclusions, so thank you very much for the data. It's very persuasive.

That being said, however, (and yes, this is totally subjective) I am one of those people who can hear the difference between 96 and 160 or 192. Not all ears are created equal, just like eyesight. Maybe most people can't tell the difference, but for some of us, its definitely noticeable.

That just leaves one question unanswered - if you're going to go with 2-pass encoding, would setting --pass 3 be better than --pass 2, and why?

[Slitheen]

If you're so tuned up to subtle differences in quality and quality is so important why are you making such heavily compressed files to play on very large screen sizes?

[greyfax]

This is like making claims about how you can hear the difference between 96khz and 192khz audio without doing proper ABX testing.

Hang on, I spoke in error. You said khz, not kbps. What I meant was that I can tell a difference between an audio channel encoded @ 96kbps compared to one encoded @ 160kbps. I was talking bitrates, you were talking sampling rates. My bad.

[greyfax]

If you're so tuned up to subtle differences in quality and quality is so important why are you making such heavily compressed files to play on very large screen sizes?

Good question. I'm "hoping" I can find a way to keep them looking good on screens that size, but I realize I may not be able to. YIFY was one of my inspirations for getting into encoding. He's able to to have perfect looking 720p encodes on smaller screens with a video bitrate of around 750-850kbps, and 1080's with bitrates averaging around 1850. But I have heard that they no longer look perfect when viewed on large screens, so my goal was to see if I could improve upon his methods and keep the file sizes down to around what his are while having a finished product that looked better on larger screens.

Judas seems to have done this, which is why I was taking his claims seriously, but it may have more to do with the fact that he encodes from physical blu-rays where YIFY does not, as opposed to being as a result of his other settings. That's what I'm trying to determine.

[paradoxical]

Well like I said, that wasn't what I said, it was a quote from an email exchange I had with Judas. And from this, "Moving from 3 pass to 4 was basically just wasting time with only low single digit improvement using computer analyses to even detect the differences" it sounds like he wasn't just relying on his eyes and did do some computer analysis. Point is well taken though.

I am a skeptic, so I understand and value the notion of eliminating subjectivity as much as possible and relying on evidence to base one's conclusions, so thank you very much for the data. It's very persuasive.

Yeah. The main issue is that there is lots of oft-repeated myths about encoding that tend to confuse people. Some that might have been true in the days of XviD/DivX, but are no longer true with x264. And some that have just been completely wrong from the get go. This is why there are so many posts made here where someone is asking how to improve this commandline they have set up that is usually full of redundant and even contradictory options because some "guru" on some other website, on an IRC channel, etc. said it was the best way to encode.

As I said above, the only real reason you ever need 3-pass encoding is if you possible need tighter file size control for your encodes than 2-pass would give you. That's basically it. And, honestly, if you don't have hard bitrate requirements you're just as good off using 1-pass CRF and your encodes will go faster. Or if you want some of the benefits of predictable file size but still use CRF, just do a couple of fast first passes with a couple of test CRF values and find one that ends up closest to the size you want and then just do a full encode with that. You'd save yourself more time that way then trying to squeeze out microscopic gains by using 3-pass.

[greyfax]

Got it. Thanks. I'll consider that part of the matter closed.

That just leaves the question about --pass 2 vs. --pass 3 (which has to do with what is done with the stats file and nothing to do with using 2 vs. 3 encoding passes.) Which is the default when doing 2-pass encoding, and which one is better and why? And lastly, will Handbrake allow for typing "pass=2" or "pass=3" into the command line under the Advanced tab or is that command not supported by Handbrake at all?

(If it's any incentive, I promise to shut up for a good while once this last topic is covered. *wink*)

:thanks:

[Selur]

As I said above, the only real reason you ever need 3-pass encoding is if you possible need tighter file size control for your encodes than 2-pass would give you.
And that can normally also archived by simply lowering qcomp from 0.6 to 0.5,... ;)

Which is the default when doing 2-pass encoding, and which one is better and why?
Default is --pass 2. Only difference between --pass 2 and --pass 3 routine is that --pass 3 updates the .stats file.

As always no clue about Handbrake.

[greyfax]

Well after several days of not being able to get a good answer here, I finally (in frustration) went over to the Handbrake forum and asked, and within 8 hours had my question answered concisely on the first reply. It's a REALLY good forum over there. Why do so few people here seem to know anything about Handbrake? The interface is (in my opinion) light years better than MeGUI or StaxRip. Those are two of the most user UN-friendly programs I've ever tried to use. They could both learn a thing or two from Handbrake's UI.

Anyway, here are the answers, in case anyone else would benefit from them (and I'll re-list the questions as they were asked over there):

1) Will Handbrake know the "pass" command if I type it in the text box under the Advanced tab? pass=2 or pass=3 And which is the default if you're using 2-pass encoding with a manually set bit rate?

A: Yes. pass=1 on the first pass, pass=2 on the second.

2) If the default is pass=2, is there any advantage in setting pass=3?

A: pass=3 is for any additional pass(es) taking place between the first pass (1) and the last, final encode pass (2).

3) Is there any way to force Handbrake to do a 3 pass encode, and if so, what would be the command for it?

A: In theory, yes (you would do 3 sequential single-pass encodes and specify pass=1, pass=3 and pass=2, respectively). In practice, it doesn't work, if I recall correctly. I may fix it at some point.


Now I'm just waiting for a reply back as to what he meant by it not working in practice.

[paradoxical]

Well after several days of not being able to get a good answer here, I finally (in frustration) went over to the Handbrake forum and asked, and within 8 hours had my question answered concisely on the first reply. It's a REALLY good forum over there. Why do so few people here seem to know anything about Handbrake? The interface is (in my opinion) light years better than MeGUI or StaxRip. Those are two of the most user UN-friendly programs I've ever tried to use. They could both learn a thing or two from Handbrake's UI.

Many of us just use the CLI interface directly. Others have just used one frontend and just keep using it out of habit.

2) If the default is pass=2, is there any advantage in setting pass=3?

A: pass=3 is for any additional pass(es) taking place between the first pass (1) and the last, final encode pass (2).

Which is as Selur told you. The reason you use pass=3 is to update the stats file with the information from another pass. It's not really an "advantage" just the difference in behavior.

[greyfax]

And you did proper double-blind testing to reach your conclusions, right? Otherwise your results were most likely biased...

Actually, he did. Got a reply from him several hours ago. And he had some valid objections to the comparison test on that animation. One, animation is the easiest thing to reproduce well. Secondly, if the results of the comparison weren't viewed on a very large screen, the comparison is meaningless since almost any decent encode looks perfect on smaller screens. Here was his full reply:

***********************************************

"Higher bitrates make less of a significant difference when doing multiple passes. Plus he used an animated movie... Resolution factored in. I need more details on what exactly the guy was doing.

I did blind test, and showed others the difference, Some of which didn't notice off hand viewing on their monitors.. but on a big screen 1080p TV... they picked up on it more. Sometimes the math says something but real world stuff is another thing entirely.

Animation is by far the EASIEST thing to encode, specially using the animation preset. Hell you can encode animated things at 1500kbps [at 1080p] and still produce a pretty good picture. It's Live action stuff that really starts to suffer the most.

The the way I compared was blind tests with a few people I trusted to have an unbiased view, I think it worked out that 5 out of the 7 people that didn't know which was which said the the 3 pass version was the best. The other 2 people said they couldn't tell a difference. Most of the apparent differences are in the darker enviroments, there was better dithering and in some of the harder details. Doing frame to frame comparisons/differences, using something like photoshop to do it, there were titled grids that were better "rounded" rather than actually tiled. The biggest improvement seemed to occur in high motion events, it was just more accurate. But would an eye really notice the difference? Really don't care, I've rather take the extra time to only have to do it once and come out with the best possible encode costing me a mear extra hour and a half to 3 hours to do the 3rd pass, rather than trying to take a shortcut just to shave of that time."

[paradoxical]

Actually, he did. Got a reply from him several hours ago. And he had some valid objections to the comparison test on that animation. One, animation is the easiest thing to reproduce well. Secondly, if the results of the comparison weren't viewed on a very large screen, the comparison is meaningless since almost any decent encode looks perfect on smaller screens. Here was his full reply:

***********************************************

"Higher bitrates make less of a significant difference when doing multiple passes. Plus he used an animated movie... Resolution factored in. I need more details on what exactly the guy was doing.

I did blind test, and showed others the difference, Some of which didn't notice off hand viewing on their monitors.. but on a big screen 1080p TV... they picked up on it more. Sometimes the math says something but real world stuff is another thing entirely.

Animation is by far the EASIEST thing to encode, specially using the animation preset. Hell you can encode animated things at 1500kbps [at 1080p] and still produce a pretty good picture. It's Live action stuff that really starts to suffer the most.

The the way I compared was blind tests with a few people I trusted to have an unbiased view, I think it worked out that 5 out of the 7 people that didn't know which was which said the the 3 pass version was the best. The other 2 people said they couldn't tell a difference. Most of the apparent differences are in the darker enviroments, there was better dithering and in some of the harder details. Doing frame to frame comparisons/differences, using something like photoshop to do it, there were titled grids that were better "rounded" rather than actually tiled. The biggest improvement seemed to occur in high motion events, it was just more accurate. But would an eye really notice the difference? Really don't care, I've rather take the extra time to only have to do it once and come out with the best possible encode costing me a mear extra hour and a half to 3 hours to do the 3rd pass, rather than trying to take a shortcut just to shave of that time."

1) The source type is irrelevant. I've done the same test with all sorts of live-action footage and got basically the same results. That objection is basically a red herring.

2) As I said, I watched on a 65" TV that had been professionally calibrated.

3) What he states is not a double-blind test.

4) The fact that he can only see the difference when he's looking at the frames in Photoshop is hilarious. No one watches movies via still frame.

But as I said, if someone thinks they are getting "better results" by wasting their time doing 3-pass encoding then they can go ahead. They aren't getting better quality. That guy is peddling you myths and nonsense.

And you don't even need to take my word for it.

What does actually the third pass add to the final video? The better ipb frames arrengment or the more exact final bitrate (size) or what?

Nothing. It's a placebo.

Who would you believe more? An x264 developer or some random guy on the Internet?

[Groucho2004]

@greyfax
Let's see if I get all this right:
- In almost every post you're citing what other people think about 3-pass encoding but you apparently have never tried it yourself
- You have received plenty of opinions here about it but they seem to conflict with your desire for 3-pass encoding being better than 2-pass
- You acknowledge but basically ignore the results from paradoxical's SSIM/PSNR test which proves that 3-pass is a waste of time and energy

So, how about testing it yourself?

[paradoxical]

Live action movie, pretty decent level of grain, HD resolution, plenty of dark scenes. Preset veryslow, tune film bitrate 2500

2-pass:

SSIM Mean Y:0.9395303 (12.185db)
PSNR Mean Y:39.609 U:45.489 V:46.664 Avg:40.842 Global:40.227 kb/s:2494.27

3-pass:

SSIM Mean Y:0.9395345 (12.185db)
PSNR Mean Y:39.610 U:45.487 V:46.664 Avg:40.842 Global:40.227 kb/s:2494.27

Yeah, results were just as I expected.

And the screens in no order:

http://imageshack.us/a/img341/8351/shot2q.th.png (http://imageshack.us/photo/my-images/341/shot2q.png/)http://imageshack.us/a/img29/7636/shot2c.th.png (http://imageshack.us/photo/my-images/29/shot2c.png/)

http://imageshack.us/a/img202/1651/shot1c.th.png (http://imageshack.us/photo/my-images/202/shot1c.png/)http://imageshack.us/a/img835/2407/shot1ln.th.png (http://imageshack.us/photo/my-images/835/shot1ln.png/)

Tell the guy you're talking to pick which he thinks is best quality and we can see if he picks the 3-pass over the 2-pass. Those shots are pretty representative of both the dark scenes in the movie and the more well-lit scenes. Artifacts are obviously different as in the 1st set of screens but in motion I had a hard time really spotting which was which. The artifacts are also more obvious on my computer monitor than on the TV because it's brighter than the calibrated TV.

All in all there was not a "15% better" output of the 3-pass. Nor was the first 1-pass at some ridiculous 65% quality. In fact when I did still frame there were a number of times when I chose the first pass as being better quality in dark scenes. Lighter scenes were far more closely identical between each version.

[greyfax]

@greyfax
Let's see if I get all this right:
- In almost every post you're citing what other people think about 3-pass encoding but you apparently have never tried it yourself
- You have received plenty of opinions here about it but they seem to conflict with your desire for 3-pass encoding being better than 2-pass
- You acknowledge but basically ignore the results from paradoxical's SSIM/PSNR test which proves that 3-pass is a waste of time and energy

So, how about testing it yourself?

1) I haven't tried it myself because I use handbrake, which doesn't support 3-pass encoding. I came here to get feedback to see whether or not it seemed like it was worth going to the trouble of switching to one of the other programs that I hate (MeGUI or StaxRip.)

2) I don't know where you're getting the impression that I have a "desire" for it to be better. If it's not, so much the better - I won't have to switch software or waste time trying it, or waste extra time encoding. Your perception of bias is incorrect.

3) I didn't ignore it at all. Again, you're reading things that aren't there. I've already stated that I'm a skeptic, which means I am influenced more by data and evidence than I am by anecdotes and testimony. I merely posted Judas' response to these objections because at least some of them (especially the part about animation not being a good basis of comparison) seemed to have merit. If the math was extrapolated from animation and animation isn't a good comparison to live action, then the math means very little.

And I answered your last question in part #1.

[greyfax]

Tell the guy you're talking to pick which he thinks is best quality and we can see if he picks the 3-pass over the 2-pass. Those shots are pretty representative of both the dark scenes in the movie and the more well-lit scenes. Artifacts are obviously different as in the 1st set of screens but in motion I had a hard time really spotting which was which. The artifacts are also more obvious on my computer monitor than on the TV because it's brighter than the calibrated TV.

All in all there was not a "15% better" output of the 3-pass. Nor was the first 1-pass at some ridiculous 65% quality.

I am mostly convinced at this point that his quality (over YIFY) is coming from other settings or the fact that he encodes directly from physical blu-ray and not from doing a third pass.

That being said, I would like to clarify a couple of points. First, he never said that he only saw improvements when viewing still frames. He said the improvement was noticeable by 5 of 7 people on a large screen in full motion. While you are correct that technically this isn't a "double" blind test, it IS single blind, and that's still fairly good, albeit it subjective. Secondly, Judas wasn't the one who listed those statistics - those came from threads that I found by searching. And it is entirely possible that they were several years old (maybe even referring to XviD and not x264) so don't attribute those claims to him. Lastly, he isn't just some random guy on the internet. He's someone I have been talking to off and on for months who turned down an offer to be on the YIFY encoding team because (short version) YIFY's quality requirements weren't stringent enough for him.

Oh, and one final thing: since the differences he noticed were only apparent on a huge screen, no differences would be visible in a screen shot even if they existed. I'm not sure why you felt like a screenshot comparison on a computer would have the same level of clarity as a 70" screen, which is what would be needed for an accurate comparison.

But yeah, for all practical purposes I consider the matter closed. I'm at least willing to say that it probably doesnt make enough of a difference to warrant switching to program with a UI that I cant stand. Thanks everyone for the input.

[detmek]

If you want good quality at lower bitrates you need extremely good preprocessing filter to prepare video. Check example and numbers in this thread (http://forum.doom9.org/showthread.php?t=167292).
3 pass encoding is waste of time as actual compression is done on the last pass. Previous pass(es) is/are just for rough estimation of needed bit-distribution and frame types. You can not achieve anything spectacular with more precise estimation.
If you don't use slowest settings for 2pass encoding then you will get better quality by increasing those settings compared to using 3rd pass with same settings.
Also, since you use Handbrake, compare 2pass encodings with fast first pass vs. slow first pass and see if you can see a difference from better estimation for last pass.

[paradoxical]

I am mostly convinced at this point that his quality (over YIFY) is coming from other settings or the fact that he encodes directly from physical blu-ray and not from doing a third pass.

I'd be willing to bet that his settings are like most of the encoding "gurus" use. They will be some big long string of redundant and contradictory options specified because he thinks turning every knob will do something. Yes, the quality is more likely due to the source itself and possibly any post-processing rather than 3-pass or magical settings.

Oh, and one final thing: since the differences he noticed were only apparent on a huge screen, no differences would be visible in a screen shot even if they existed. I'm not sure why you felt like a screenshot comparison on a computer would have the same level of clarity as a 70" screen, which is what would be needed for an accurate comparison.

*sigh* I've mentioned like 5 times that I've been watching these on a big TV. You seem to keep glossing over this. I never said my results came from purely looking at a few frames on a computer monitor.

But yeah, for all practical purposes I consider the matter closed. I'm at least willing to say that it probably doesnt make enough of a difference to warrant switching to program with a UI that I cant stand. Thanks everyone for the input.

It doesn't make ANY real difference. The blocking artifacts won't look exactly the same but that's about it. YOU DON'T GET ANY BENEFIT. As Dark Shikari said "I'ts a placebo".

[bxyhxyh]

@grayfax
2 pass vs 3 pass which is better?
In visual quality, no difference at all.

SSIM difference 0.0000042 means that overall gain is veeeerrrrrrryyyyyy liiittttllleee which is not really desirable in time that spent in 3rd pass.
And everyone is saying 3 pass will give you tight bitrate.

For example: if you want 2000 kb/s x264 doesn't give exact 2000 kb/s.

1st pass will give 2030 kb/s
2nd pass will give 2003 kb/s
3rd pass will give 2001 kb/s
4th pass will give 2000.8 kb/s
.
.
.
n th pass will give 2000.0001456452 kb/s
That's all.

-------------------------------
Sorry, my english is not good.