Quote:
Originally Posted by SassBot
Which isn't possibly true if you really did encode with CRF and 2-pass with the same settings and both were at the same bitrate. 2-pass uses the CRF algorithm to encode it just selects the appropriate CRF value for the bitrate you specified. You've basically tried to claim that CRF is inferior to itself which is a nonsensical statement.
|
Quote:
Originally Posted by SassBot
And you don't have to take my word for it. From Dark Shikari's mouth:
There is no way your CRF encode looked worse than a 2-pass unless you didn't use equivalent settings or a CRF value that matched the bitrate you chose for 2-pass. If it did produce a noticeably different result despite everything being exactly the same between the two encodes you have uncovered a bug. |
So much for my plead to leave the CRF x 2-pass discussion out of this thread
.
Well, anyways Mr. Sass, I am very much aware of the point you made, having read extensively about this matter. Actually, I had even spent some good time reading the thread you quoted Dark Shikari's post from. Nevertheless, it seems a lot of people are still unconvinced with your claims. I for one am neither convinced nor unconvinced. I am skeptical, and I am running trials to find out myself.
Which brings me to my second point: both my CRF and 2-pass encodes were done with the same settings. I am using a GUI, but I am not aware of any settings it's hiding. So as far as I can tell, both encodes have the exact same settings.
Quote:
Originally Posted by SassBot
Either that or he's just convinced himself that he sees a difference where there isn't one which is not uncommon.
|
LOL. Typical arrogance form the "know-it-all"s!!
Anyways, I've ran an ABX test (15 trials), and I scored right 15/15, so trust me, I see a difference.
Anyways, I am willing to accept your claims if you care to explain them further. If 2-pass and CRF are the same, does that mean that the first pass of a 2-pass encode is simply running to determine the "n" needed for the given bitrate or size, and the 2nd pass is nothing more than CRF n ??
Also, what's the precision of "n"?? If it's an integer, then your whole claim is nonsensical. If it's a single float, then it might hold some truth to it, though that would still be inaccurate to hit a given target bitrate. So what is it? CRF n or n.x or n.xy or what?
In the GUI I use, I can only specify integer as CRF's argument. And before you even go there, this has nothing to do with my trial. I encoded in CRF first, and then used the output's bitrate in 2-pass, and not the other way around.