Single pass VS 2nd-pass, something not quite right...

[State of Mind]

I am using the most recent version of the XviD Codec. I deal with home videos (DV format). I prefer the XviD codec over the DivX codec because DivX tends to smooth the converted image too much. XviD maintains a certain degree of sharpness at less filesize and I appreciate this. However, when I do 2nd pass conversion processes in VirtualDub, the 2nd-pass video always looks worse in quality than a single-pass attempt. With a 2nd-pass, the image seems to have small burred out chunks "hovering" over the image. I thought 2nd-pass would result in slightly improved quality at less filesize due to the conversion being more organized thanks to the help of a second pass. I am using default settings. I went into the Decoder Options and selected three boxes that weren't checked and played the video again (I use Media Player Classic) and the picture was somewhat better, though hovering chunks remained. Can anyone help me out? Because I am starting to love XviD and would hate something like this to let me down. I tend to become loyal to software that pleases me. Thank you kindly in hopeful advance. :)

Jeremy

PS: Ok, I took a screenshot of both near the same area of the video and placed them side-by-side in Paint and compared them. The second pass video looks a bit blurrier than the first-pass and the chunkiness is more noticable also.

[Ark]

If you post your settings (sigle-pass and 2pass) we can try to understand your "problem".

And 2pass mode is *not* always better than single-pass...

[Sirber]

Not always? If we talk about quality, IMO 2-pass will always win. The rate control has more data to do it's task.

[State of Mind]

Well, your opinion seems to be incorrect because 2nd passes are turning out worse for me, therefore, they aren't winning.

My settings? Is this the video.pass file?

[Tommy B.]

No, settings are the options enabled in XviD.

Question: Is "Discard 1st pass" enabled? If you compare the 1st pass
file to the 2nd, you should notice at least that the 1st pass file
is usually larger. Why that? Because if you have "discard 1st pass"
disabled, the 1st pass file will be written to HD and thus the whole
file is being coded with Quant 2 (and 4 for B-Frames).

When encoding the 2nd pass, the quants are higher if Q2 can not
be achieved due to a too low bitrate.

If you want your encodes to stay sharp, encode in single pass mode
with Q2. Two pass encoding is for people who aim for a specific
size of their encode (and therefore might lose quality should Q2
require a bitrate which is higher than the one used).

[Koepi]

Also note that you need to run a "2pass-first pass" before a "2pass - 2nd pass". "single pass" is _no_ first pass. (I hope this isn't the error you're observing.)

Then make sure you enter the target size (or bitrate) correctly:
the traget size is in kbyte, i.e. if you want to reach 700 mb it should be something like 700000kb, do not just enter 700.

Please read the post about reporting bugs, it gives you some hints which data we need from you to actually help you.

Regards
Koepi

[Leak]

Originally posted by Koepi
Also note that you need to run a "2pass-first pass" before a "2pass - 2nd pass". "single pass" is _no_ first pass. (I hope this isn't the error you're observing.)

Since I haven't tried it yet - what happens if the stats file doesn't exist? I'd hope that XviD reports an error and refuses to encode anything in such a situation...

np: Amen Andrews - Remember This (Rephlexions! A Celebration Of Braindance!)

[Koepi]

I think I added an alert message for such cases, but that's long time ago and I don't know if that made it into CVS at all - my mind is playing tricks on me.

Regards
Koepi

[Ark]

Originally posted by Sirber
Not always? If we talk about quality, IMO 2-pass will always win. The rate control has more data to do it's task.

AFAIK if you don't care about filesize the best choice is single-pass@Q2 with a good matrix (60f9, Sharktooth's high bitrate matrices...).

Also developers said several times that 2pass "logic" isn't necessarily better than single-pass in those situations...

[akupenguin]

Originally posted by Leak
Since I haven't tried it yet - what happens if the stats file doesn't exist? I'd hope that XviD reports an error and refuses to encode anything in such a situation...

Sure, but what happens if you have a stats file laying around from the previous time you encoded something in 2 pass mode? AFAIK, there's no way to tell that it's the wrong movie.

[Leak]

Originally posted by akupenguin
Sure, but what happens if you have a stats file laying around from the previous time you encoded something in 2 pass mode? AFAIK, there's no way to tell that it's the wrong movie.

Well, the default path for the stats file is "\video.pass", which just screams "pure madness" at me - why one would EVER want to put a file into a drive's root directory is waaay beyond me; especially when ".\video.pass" (i.e. put the stats-file in the current directory, which in almost all cases is right next to the output file) makes so much more sense, and reduces the chance of getting a stale file *IF* you create separate directories for each job.

But anyway, AFAIK the codec at least knows how many frames it'll get from the application that's using it, so if the number of frames doesn't match the number of frames used in the first pass it's probably quite a good guess that we're using the wrong first pass file.

np: nix

[sysKin]

Originally posted by Leak
But anyway, AFAIK the codec at least knows how many frames it'll get from the application that's using it(...) No it doesn't. There is completely no way of knowing if pass file is correct or not.
Perhaps it's worth to do something about it - at least resolution and settings (especially max b-frames) could be written there, and compared.

Or maybe some md5sum of the very first frame?

[Leak]

Originally posted by sysKin
No it doesn't. There is completely no way of knowing if pass file is correct or not.

Augh... come to think about it, you're right... :(

Perhaps it's worth to do something about it - at least resolution and settings (especially max b-frames) could be written there, and compared.

Or maybe some md5sum of the very first frame?

I don't know, but I'm almost always using the same settings (especially if I encode several epsiodes of a series).

But how about calculating an MD5sum every n frames? (Assuming that you can error out of encoding at any time...)

np: nix

[Koepi]

Nah, md5sum thingy is overkill. Also it doesn't properly serve it's goal, imagine you did a fast first pass with a speed-tuned avs script (i.e. for the first pass you leave a denoise filter away).

That would work now, but with md5-summed frames comparison that would be a no-go.

While I think of it, I like that. md5sum + removal of fast first pass is what i dream about, no approximations for curve scaling, but pure good data ;) And no way to get around a proper full first pass!

Regards
Koepi