xvid: constant quantizer or 2 pass?

[M4ST3R]

Well I know 2 pass is especially recommended when targeting an output size but what about the quality itself between 2 pass and constant quantizer (of course with same output size)?

Indeed MEncoder doc (http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html) says
The problem with constant quantizing is that it uses the given quantizer whether the macroblock needs it or not. That is, it might be possible to use a higher quantizer on a macroblock without sacrificing visual quality. Why waste the bits on an unnecessarily low quantizer? Your CPU has as many cycles as there is time, but there is only so many bits on your hard disk.

With a two pass encode, the first pass will rip the movie as though it were CBR, but it will keep a log of properties for each frame. This data is then used during the second pass in order to make intelligent decisions about which quantizers to use. During fast action or high detail scenes, higher quantizers will likely be used, and during slow moving or low detail scenes, lower quantizers will be used. Normally, the amount of motion is much more important than the amount of detail.

If you use vqscale=2, then you are wasting bits. If you use vqscale=3, then you are not getting the highest quality rip. Suppose you rip a DVD at vqscale=3, and the result is 1800Kbit. If you do a two pass encode with vbitrate=1800, the resulting video will have higher quality for the same bitrate.

while StaxRip FAQ (http://stax76.wikispaces.com/StaxRip+FAQ) says
It's a common misconception that 2pass mode is more efficient than quality mode. The only benefit of 2pass mode is hitting a exact file size. Encoding in quality mode using a single pass will result in equal quality compared to a 2pass encode assuming the file size is identical of course.

So who is right?

[nurbs]

The StaxRip FAQ is talking about CRF mode in x264. CRF isn't constant quantizer and x264 isn't xvid. If you use constant quantizer in x264 it will turn of AQ (maybe other options as well) which will lead to inferior picture quality. I don't know if something similar happens with xvid.

[M4ST3R]

oops I weirdly thought it was about xvid. I guess I read too fast. Sorry.

Topic can be closed.

[grv575]

StaxRip FAQ is incorrect as well:
http://forum.handbrake.fr/viewtopic.php?f=6&t=848

[nurbs]

No it isn't. It has been stated multible times by the x264 developers (http://forum.doom9.org/showpost.php?p=1245120&postcount=20) that multipass encodes don't offer better quality than CRF.

[Dark Shikari]

Note of course that what is true for x264 is not necessarily true for Xvid.

[grv575]

No it isn't. It has been stated multible times by the x264 developers (http://forum.doom9.org/showpost.php?p=1245120&postcount=20) that multipass encodes don't offer better quality than CRF.

Yes, I've seen that:
"No, actually, it doesn't. If it does, it's a bug, because 2pass and CRF use identical ratecontrol algorithms. "

But crf uses a sliding window algorithm whereas 2-pass decides how to allocate bits based on the entire file.

Did you even read the link I quoted?

akupenguin, the x264 author:
"CRF and 2pass are at the same point on the CBR-to-CPSNR continuum, because they have the same target bitrate distribution. 2pass just ends up slightly closer to that target.)"

gpoirier, an important developer on projects like x264 and ffmpeg:
"Here's what _I_ think:
- crf provides very good quality and allows to make do without 2 pass,
which is cool.
However, you can't control how big the encode will end up.
- two pass both allow you to control the target bitrate, and allows to
make a smarter use of the bits you throw at it. Each now pass somewhat
improves quality over the previous one.
- qp is really meant to be used if you know what you do, if you need
to us lossless mode, or if you really want to _force_ low quants.

My ranking (in decreasing order of quality):
2-pass>crf>qp

In terms of speed:
crf,qp>2-pass.
"

also from akupenguin:
"benchmarking the existing implementations of crf vs 2pass on several movies. Result: 2pass was better by anywhere from .01 to .12 dB (equivalently, up to 2.5% bitrate at the same psnr). This includes both the effects of ratecontrol (smarter I-frame qp decision) and the fact that direct=auto only really works in 2pass."

So there's some statistics for you as well.

And visually, my 2-pass encodes come out better than the crf ones using the same bitrates and x264 settings.

[Dark Shikari]

But crf uses a sliding window algorithm whereas 2-pass decides how to allocate bits based on the entire file.Wrong. CRF doesn't use any algorithm at all for "bit allocation": it just completely ignores the question to begin with, because you didn't ask for a particular allocation of bits.
- two pass [...] allows to
make a smarter use of the bits you throw at it. Each now pass somewhat
improves quality over the previous one.This is not true, at least not in the context you're attempting to place it.
"benchmarking the existing implementations of crf vs 2pass on several movies. Result: 2pass was better by anywhere from .01 to .12 dB (equivalently, up to 2.5% bitrate at the same psnr). This includes both the effects of ratecontrol (smarter I-frame qp decision) and the fact that direct=auto only really works in 2pass."

So there's some statistics for you as well.This is likely quite outdated. Furthermore, the extra time you spent on the two passes could have been spent on better encoding settings for the CRF encode.

I just did my own test on a DVD source:

$ ./x264 --crf 25 --tune psnr --psnr "c:\olde\AQTesting\Black.Pearl.Sample.m2v"
--fps 24000/1001 -o NUL
...
x264 [info]: PSNR Mean Y:41.997 U:46.202 V:46.978 Avg:43.048 Global:42.892 kb/s:605.10

$ b=605;for p in "1 --quiet" 2;do ./x264 --pass $p --bitrate $b --tune psnr --p
snr "c:\olde\AQTesting\Black.Pearl.Sample.m2v" --fps 24000/1001 -o NUL;done
...
x264 [info]: PSNR Mean Y:41.961 U:46.183 V:46.949 Avg:43.014 Global:42.864 kb/s:608.99

Anyways, you're dragging this thread way off-topic. The original post was about Xvid, not x264.

[grv575]

Wrong. CRF doesn't use any algorithm at all for "bit allocation": it just completely ignores the question to begin with, because you didn't ask for a particular allocation of bits.


The point was CRF is a sliding window algorithm (or at least a non-global algo). As opposed to 2-pass. akupenguin can say it better than me:

"
19th October 2005, 22:48 #9 | Link
akupenguin
x264 author

Join Date: Sep 2004
Location: /dev/tty0
Posts: 2,327 x264 keeps track of the "complexity" of each frame, and then determines quantizer from that using the ratecontrol equation (rc_eq) and a quantity called "rate_factor". Assuming an ideal rc_eq, then constant rate_factor would be optimal perceptual RD (not constant quality, but allocating a little more quality in places where it doesn't cost much).
ABR and 2pass use the same rc_eq, the primary difference is in how they determine rate_factor. In ABR, we only have statistics about the past frames, so we continually update the estimate of the rate_factor needed to meet the target bitrate. In 2pass, we have all the stats, so we pick the right rate_factor to begin with.
To make a 1pass encode that is nearly identical to a 2pass, you'd need to specify rate_factor instead of bitrate or QP. (There will still be some differences: 1pass uses SATD for complexity, 2pass uses 1st pass's bitsize; I-frame quants are selected differently.)"

Maybe this isn't still relevant to today's CRF algo (post is slightly dated)? Also, I realize the post above talks about ABR rather than CRF, but assume it may still be applicable to CRF since it also has non-global information with which to make encoding decisions.

Edit: The rest of the thread does have some interesting discussion (it's when CRF was added) about CRF vs 2-pass decisions so I'll link it:
http://forum.doom9.org/showthread.php?t=101551

[Dark Shikari]

The point was CRF is a sliding window algorithm (or at least a non-global algo). As opposed to 2-pass. akupenguin can say it better than me:

"
19th October 2005, 22:48 #9 | Link
akupenguin
x264 author

Join Date: Sep 2004
Location: /dev/tty0
Posts: 2,327 x264 keeps track of the "complexity" of each frame, and then determines quantizer from that using the ratecontrol equation (rc_eq) and a quantity called "rate_factor". Assuming an ideal rc_eq, then constant rate_factor would be optimal perceptual RD (not constant quality, but allocating a little more quality in places where it doesn't cost much).
ABR and 2pass use the same rc_eq, the primary difference is in how they determine rate_factor. In ABR, we only have statistics about the past frames, so we continually update the estimate of the rate_factor needed to meet the target bitrate. In 2pass, we have all the stats, so we pick the right rate_factor to begin with.
To make a 1pass encode that is nearly identical to a 2pass, you'd need to specify rate_factor instead of bitrate or QP. (There will still be some differences: 1pass uses SATD for complexity, 2pass uses 1st pass's bitsize; I-frame quants are selected differently.)"

Maybe this isn't still relevant to today's CRF algo (post is slightly dated)?Correct, MB-tree deprecated the old complexity analysis method.

[nm]

And visually, my 2-pass encodes come out better than the crf ones using the same bitrates and x264 settings.
If you can actually see a difference, there's probaby something wrong with your settings or methodology. Could you throw us some samples?

[grv575]

If you can actually see a difference, there's probaby something wrong with your settings or methodology. Could you throw us some samples?

It wasn't a very scientific compare. My method was:
1. Encode using gordian knot & vdub (2-pass xvid/mp3). Quality came out very high (used a compression test to determine bitrate)
2. Wanted a way to automate similar quality encodes for lots of different source files
3. Downloaded almost every gui/cl encoder on videohelp and tried some encodes. Quality either wasn't as good as xvid encode, or didn't have a good way to batch lots of source files. Also decided I wanted to use AAC and the nero cl encoder is the best one right now (well better than FAAC)
4. Saw bat file encoding solution online as well as a powershell one. Adapted these two to my needs and hacked together a bitrate extracter by generating an avisynth script for each source

So I was comparing a MediaCoder encode to x264 using -crf 22 against the gnot encode and they came out to around the same filesize (tweaked crf until they did). The xvid encode was definatlely better. I know it's apples to oranges since I may have used AAC (don't remember bitrate).

I can do some more robust comparisons later. But I did a ton of encodes with many encoder gui/cl solutions and none came out as good as the gnot one (except the batch one I'm using comes out better). I'll try a side-by-side -crf encode of a bunch of the low quality ones (ones which had trouble getting good encodes for) against some 2-pass encodes using the same settings.

[nm]

So I was comparing a MediaCoder encode to x264 using -crf 22 against the gnot encode and they came out to around the same filesize (tweaked crf until they did). The xvid encode was definatlely better. I know it's apples to oranges since I may have used AAC (don't remember bitrate).
It's apples to oranges because you compared x264 encodes to an Xvid encode. This isn't the same as comparing x264 2-pass directly to x264 CRF. Anyway, you should be getting much better quality with x264 (in both CRF and 2-pass modes) unless the bitrates are so high that both encoders produce near-transparent results. Or were you using the Xvid file as the source for your x264 encodes?

[grv575]

It's apples to oranges because you compared x264 encodes to an Xvid encode. This isn't the same as comparing x264 2-pass directly to x264 CRF. Anyway, you should be getting much better quality with x264 (in both CRF and 2-pass modes) unless the bitrates are so high that both encoders produce near-transparent results. Or were you using the Xvid file as the source for your x264 encodes?

Source was rmvb, encodes were xvid, crf, 2-pass h264. Both crf and 2-pass were visually compared to xvid (which had no artifacts around text wheras crf did have blurry artifacts). I don't have the encodes anymore but my guess would be the audio was encoded at a higher bitrate in the crf one. Like I said I'd like to do a more scientific comparison. I'll try to post back if I have the time to do this.

Edit: Ok I did a reencode using crf 22 and 21 and then 2-pass for the same bitrates and they're very similar quality. The crf one does hand-wave during fast motion (loss of detail) but I guess that's the whole point. I can't say I liked either the crf or the 2-pass better in terms of quality of stills.

[creamyhorror]

Correct me if I'm wrong, but doesn't 2pass essentially just choose a ratefactor based on pass 1? Assuming the difference in complexity analysis has been eliminated by mb-tree, pass 2 is essentially a CRF encode using the ratefactor from pass 1. Is that right, or is there additional information from pass 1 that improves pass 2 relative to a CRF encode with the same ratefactor?

And visually, my 2-pass encodes come out better than the crf ones using the same bitrates and x264 settings.
So you didn't actually do any pair of encodes with the same "x264 settings" :rolleyes:

[Dark Shikari]

Correct me if I'm wrong, but doesn't 2pass essentially just choose a ratefactor based on pass 1? Assuming the difference in complexity analysis has been eliminated by mb-tree, pass 2 is essentially a CRF encode using the ratefactor from pass 1. Is that right, or is there additional information from pass 1 that improves pass 2 relative to a CRF encode with the same ratefactor?Advantages of 2-pass:

1) --direct auto works better
2) if the first pass used --slow-firstpass, it can do optimal reference reordering (~0.1-0.3% benefit)

Advantages of CRF:

1) 2-pass still attempts, during the encoding process, to tune the ratefactor up and down. It has to do this since the first pass wasn't a perfect predictor, especially if the first pass wasn't run with --slow-firstpass. CRF has no such issues.
2) It's faster, so you can get away with slower settings.
3) No heavily-lookahead-bottlenecked first pass that sits there using only two of your cores.

[M4ST3R]

To reply to my original question:
I encoded a movie in xvid at constant quantizer=3, read the bitrate using vdub and did a two pass encoding at this bitrate. Results:

PSNR SSIM
cq 3 43.25945 0.97651
2 pass 43.19016 0.97635

Then my conclusion is that two pass xvid encoding is useless when you don't care about the filesize

[grv575]

Just want to point out that crf encodes by definition takes away detail in fast scenes. Not everyone likes the output compared to a 2-pass encode.

[detmek]

I think that 2-pass also does the same thing in fast motion scenes.

[Dark Shikari]

Just want to point out that crf encodes by definition takes away detail in fast scenes. Not everyone likes the output compared to a 2-pass encode.2-pass and CRF use the exact same ratecontrol algorithm.

2-pass "takes away detail" in fast scenes in exactly the same way CRF does.

Since you clearly know absolutely nothing about how x264's ratecontrol internals work, please stop posting as if you did.

[grv575]

2-pass and CRF use the exact same ratecontrol algorithm.

2-pass "takes away detail" in fast scenes in exactly the same way CRF does.

Since you clearly know absolutely nothing about how x264's ratecontrol internals work, please stop posting as if you did.

Clearly I have videos that show exactly what I'm talking about. Maybe instead of pretending you know everything about all algos used in the project, you could do your own comparisons.

[Dark Shikari]

Clearly I have videos that show exactly what I'm talking about. Maybe instead of pretending you know everything about all algos used in the project, you could do your own comparisons."Pretending"? I wrote both default quality-distribution algorithms, adaptive quantization and macroblock-tree! :rolleyes:

Perhaps instead of acting like a complete fool you could upload a sample and relevant commandlines that generates your issue?

[creamyhorror]

Just want to point out that crf encodes by definition takes away detail in fast scenes.
Oh? Where is this definition?

[grv575]

Oh? Where is this definition?

crf removes quality from complex scenes with lots of motion in and adds it to low-motion scenes.

[grv575]

Perhaps instead of acting like a complete fool you could upload a sample and relevant commandlines that generates your issue?

Trying to reproduce :) I had an encode where a guy waves his arm really fast and the crf encode just robbed the entire sequence of detail (my earlier bad hand-waving joke) while the 2-pass preserved the detail. I deleted it in a moment of clairity. I'd rather not post clips from porn and get banned. In any case it's not easy to reproduce with surfing or karate videos on youtube :\

[detmek]

Maybe someone used CQ mode for those clips, not 2-pass. I think CQ doesn't "take details" from fast scenes.
Even Xvid 2-pass by default take bits from high motion scenes and applies it to low motion scenes.

[creamyhorror]

crf removes quality from complex scenes with lots of motion in and adds it to low-motion scenes.
And 2-pass doesn't?

I suggest you consider that other people here might very well know the details better than you do, before you make claims that you can't back up.

[detmek]

CRF does NOT take bits from complex scenes so it could ADD it low motion scenes. Every frame is encoded regardless the rest of the movie. 2-PASS encode DOES that.
CRF just uses higher quantizer for high motion scenes because it is hard to see details in such scenes, unless you watch it frame by frame. So, it is OK to sacrifice details because one would not be able to see fine details in fast moving scenes. Limitation of human eye and brain.

[Dark Shikari]

CRF just uses higher quantizer for high motion scenes because it is hard to see details in such scenes, unless you watch it frame by frame. So, it is OK to sacrifice details because one would not be able to see fine details in fast moving scenes. Limitation of human eye and brain.Closer, but not exactly right either. Ratecontrol uses higher quantizer for higher motion regions of a scene, using macroblock-tree. So if a basketball flew across a perfectly still sunset scene, it would only lower the quality of the basketball, not the sunset.

[detmek]

Right, sorry. Not that I want, but that can be avoided if I set --aq-mode 0?

[Dark Shikari]

Right, sorry. Not that I want, but that can be avoided if I set --aq-mode 0?You can turn that off with --no-mbtree, which will instead use the old algorithm (lower quality for higher complexity scenes).

[detmek]

Thanks.

[grv575]

2-pass and CRF use the exact same ratecontrol algorithm.

2-pass "takes away detail" in fast scenes in exactly the same way CRF does.

Since you clearly know absolutely nothing about how x264's ratecontrol internals work, please stop posting as if you did.

It may use the same algorithm but adherence to it is achieved better in 2-pass since it performs a more thorough complexity estimation for each P-frame (during the 1st pass).

CRF estimates complexities using a "poor-man's 1st pass" which estimates the motion vectors at half resolution. Clearly this is not as good as a true encode for the 1st pass. Note that fast first pass may use approximations but this is still a better job than the ultra-fast pass CRF performs.

MB-tree doesn't change the above since it simply breaks up the picture into macroblocks and assigns a QP metric to each macroblock. It can just be seen as applying motion estimation & bit alloaction not just at the frame level, but at the subframe level as well. It uses a (default) 50 frame lookahead for both 2-pass and crf and therefore has no bearing on the discussion above.

In summary 2-pass can do a slighly better job of QP allocation amongst the various frames in the movie and the dynamic adjustment of future QP values compared to actual compression sizes of the frames is better since it has both past and future complexity information to use for such scaling.

[Dark Shikari]

It may use the same algorithm but adherence to it is achieved better in 2-pass since it performs a more thorough complexity estimation for each P-frame (during the 1st pass).

CRF estimates complexities using a "poor-man's 1st pass" which estimates the motion vectors at half resolution. Clearly this is not as good as a true encode for the 1st pass. Note that fast first pass may use approximations but this is still a better job than the ultra-fast pass CRF performs.

MB-tree doesn't change the above since it simply breaks up the picture into macroblocks and assigns a QP metric to each macroblock. It can just be seen as applying motion estimation & bit alloaction not just at the frame level, but at the subframe level as well. It uses a (default) 50 frame lookahead for both 2-pass and crf and therefore has no bearing on the discussion above.

In summary 2-pass can do a slighly better job of QP allocation amongst the various frames in the movie and the dynamic adjustment of future QP values compared to actual compression sizes of the frames is better since it has both past and future complexity information to use for such scaling.But when using MB-tree, there is no complexity estimation: it's simply disabled. So your entire post is moot.

[grv575]

But when using MB-tree, there is no complexity estimation: it's simply disabled. So your entire post is moot.

So with mb tree enabled, the first pass of a 2- pass encode is just thrown out?

[Dark Shikari]

So with mb tree enabled, the first pass of a 2- pass encode is just thrown out?No, the first pass is used for:

1) Frametypes
2) MB-tree data
3) Bitrate estimation
4) Direct mode selection
5) Reference list ordering

It's not used for complexity estimation, aka qcomp. Bit usage information is used for bitrate estimation, of course, but that's not needed in CRF, since CRF isn't targeting any particular bitrate.

[grv575]

No, the first pass is used for:

1) Frametypes
2) MB-tree data
3) Bitrate estimation
4) Direct mode selection
5) Reference list ordering

It's not used for complexity estimation, aka qcomp. Bit usage information is used for bitrate estimation, of course, but that's not needed in CRF, since CRF isn't targeting any particular bitrate.

And how is "MB-tree data" so completely different than a complexity metric through motion estimation?

[Dark Shikari]

And how is "MB-tree data" so completely different than a complexity metric through motion estimation?It isn't: it's just that the MB-tree data is exactly identical in CRF and 2-pass mode, so they're doing the exact same thing.

The MB-tree datafile is not even actually a complexity data set: it's a simple dump of the frame delta quants! The second pass just blindly loads them and applies them to each frame in order to copy what the first pass did.

2-pass MB-tree was effectively an afterthought: I originally designed it solely for CRF and added the statsfile in order to make it not break with 2-pass. 2-pass does absolutely nothing extra with it beyond what CRF does.

[grv575]

It isn't: it's just that the MB-tree data is exactly identical in CRF and 2-pass mode, so they're doing the exact same thing.

The MB-tree datafile is not even actually a complexity data set: it's a simple dump of the frame delta quants! The second pass just blindly loads them and applies them to each frame in order to copy what the first pass did.

2-pass MB-tree was effectively an afterthought: I originally designed it solely for CRF and added the statsfile in order to make it not break with 2-pass. 2-pass does absolutely nothing extra with it beyond what CRF does.

Ok finally some definitive information on 2-pass vs crf. Trust me you won't find anything clear cut on google. Hopefully this gets indexed.

[detmek]

So, running CRF slow first pass to get stats file and average bitrate, and then use that bitrate to run second pass is useless, right?

[Asmodian]

So, running CRF slow first pass to get stats file and average bitrate, and then use that bitrate to run second pass is useless, right?


Advantages of 2-pass:
1) --direct auto works better
2) if the first pass used --slow-firstpass, it can do optimal reference reordering (~0.1-0.3% benefit)


It looks like there is a small benefit but you have to already be using the placebo preset for it to be a good idea from a time vs. quality perspective.