Is it time we look into multi-pass

[TheXung]

Does anyone feel the need for a multi-pass in XviD like divx 5.03 has? I'm thinking it should take the average quantizer from the second pass and use that as the seed for the next pass. Alt CC could still use the average quantizer as the seed for the next pass as well.

[NuclearFusi0n]

uh...no.

XviD's current linear curve is just great the way it is. ;)

IMO this whole nth-pass BS is just soooo stupid. that is, unless, there is some magical way to make it work better than the way it's working right now for DivX

[Kyo]

Yep, I also think that the nth-pass is a nth-lose-your-time ;)

[Selur]

Same here,..
Better fix current bugs than thinking about n-pass that nobody needs and wants
(and that doesn't really help)

Cu Selur

[Koepi]

Please stop thinking of XviD as a DivX clone. It's not. It's different. It's more.

Regards
Koepi

[NuclearFusi0n]

Originally posted by Koepi
It's different. It's more.
Official XviD motto material here, folks.

:)

[Evil Andy]

n-pass: Instead of the DivX developers spending a little time sorting out their bitrate distribution algorithms, we get to psend twice as long encoding.

What galls me is that they call this a 'feature' rather than a work-around.

[TheXung]

Not to diss the work of people working on 2 pass but n-pass is a real thing. If 2-pass were perfect and I want to do a linear 2 pass without any max bitrate constraint, then my encode should have nothing but the two quantizers above and below the average quantizer. It shouldn't span quants from 2 all the way down to a typical 6 or 7. Just because XviD 2 pass is better than DivX 2 pass doesn't mean we should think that there isn't anything to be learned from them. Perhaps we should stop thinking that its perfect and accept that the competition might have come out with something better.

[Selur]

maybe you are right, and maybe n-pass is a good thing, but as far as I know there a still some bugs which should be dealt first instead of trying to implement some new feature,..

So maybe it's better to speak of this after Xvid 1.0 hits the road. :)

Cu Selur

[kempodragon]

I've been using xvid exclusively for my encodes now, and quite frankly 2 passes works beautifully as is. The only type of encodes that might benefit from a n-pass are very old movies or movies that Mpeg4 already has trouble with, like SPR. I did an encode of Akira Kurosawa's "Throne of Blood" to one cd, from a Huffyuv capture. This movie is VERY noisy and 4:3 to boot!! While it came out very nice indeed, I had to use a smaller resolution than I would have liked. Perhap n-pass could be used to fine-tune sources like these? Either that or the developers can optimize the code even more. VHQ sounds like an alternative to n-pass and I can't wait to try it once the developers make it work on a Pentium 4. Maybe that's the real test, VHQ vs n-pass? I guess I'll have to wait until Doom9 does his next codec comparision. Hopefully, VHQ will be ready so it finally claim its rightful place as THE successor of Divx3.

[Teegedeck]

Originally posted by TheXung
If 2-pass were perfect and I want to do a linear 2 pass without any max bitrate constraint, then my encode should have nothing but the two quantizers above and below the average quantizer. It shouldn't span quants from 2 all the way down to a typical 6 or 7.

Do I understand you correctly in that you want all frames in second pass to be compressed at the average quant+/-1? Isn't that exactly the result you get with alt.cc at 'low agression'??? It's also been the way for XviD's two-pass under Linux since the beginning, I believe. Not that I think it's better than 'linear' scaling, but hey, if that's what you want...

But perhaps I didn't get you.

[TheXung]

There seems to be a misconception that the only benefit to multi-pass is improved quality. The main point of multi-pass isn't to sqeeze the very last bit of quality out (in fact by it's very nature, it's designed to take bits from a larger number of good looking scenes and give them to a smaller number of bit-starved scenes), it's to ensure that all scenes are at the same quality. But since people don't seem to notice or have any complaints about or simply choose to ignore the varying quality in a 2-pass encode, then I guess I've just been talking into the wind.


Originally posted by Teegedeck
Do I understand you correctly in that you want all frames in second pass to be compressed at the average quant+/-1? Isn't that exactly the result you get with alt.cc at 'low agression'??? It's also been the way for XviD's two-pass under Linux since the beginning, I believe. Not that I think it's better than 'linear' scaling, but hey, if that's what you want...

But perhaps I didn't get you.

No alt.cc at low agression doesn't give you that. I just tried it. Within the first 5000 frames of Minority Report, the quants ranged from 2 to 6. In fact achieving average quant+/-1 using the current xvid api is pretty much impossible. Since many of you don't ever visit the DivX forum, I'll leave you with this well written explanation by Temporance about why it's impossible.


Running a single pass with q=2 does not obtain every single bit of information about a clip. In the second pass, xvid still needs to guess which quantizer to use for each frame, especially when that quantiser is not close to 2.

To simplify greatly, VBR rate control has one aim - to discover a constant quantizer that, when applied to every frame, will hit the desired filesize. Xvid does not achieve a constant quantiser for the 2nd pass, it varies a lot. I haven't tried 5.0.3 Pro yet.

If you have the compressed frame sizes for a whole video encoded at q=2 (which produced, say, 1645kbit/s), how would you set the quantizer in order to achieve 710kbit/s? When you ask yourself this question you realise that encoding the clip with q=2 does not give you enough information. There is an approximation, compressed_frame_size = f(q), but even this leaves you guessing and will result in varying quantizer during the 2nd pass.

[Bulletproof]

Why don't you just cap the quantizers if you dont want them to vary alot? Or use the CBR mode if u want a specific datarate. VBR means Variable Bitrate, it's going to vary by nature, it's not ABR.

[ProfDrMorph]

You know that constant quantizer doesn't mean constant quality, don't you?

I don't think that all quantizers should be nearly equal to achieve what you want. We need another measurement which represents the difference between every encoded frame and it's original. This difference should be equal. But since some errors are more visible than others such a measurement isn't easy to find.
When we've got a measurement to see how far away XviD 2-pass is from constant subjective quality we can talk about n-pass again because only then we know if we need it or not.
IMO 2-pass does work very well and I don't see why we need even more passes.

[Didée]

Uh, where to start?

First, for DivX explicitely, n-th pass is a useful feature. From start, DivX has no clue at all how to distribute quantizers, since it uses "simple" CBR. In next passes, it still has no clue what is really going on in the clip, but with the approximation method, it gets to the point in the end. That is simple maths, more or less.

As for XviD, the current 2-pass method is very good and mostly sufficient - in principal. It is true that XviD still has to do kind of guesswork on which quantizers to use, since it is not possible to calculate the exact framesize at quant-X out of the framesize at quant-2. But the general approximation for that is good enough, and along with XviD's wonderful overflow handling and the default buffer of 250 frames, it works out.

Now, when using linear compression [hi=0, lo=0], the quantizers should indeed only vary between the two different values at each side of the average quant (and that is what I get in most cases, when I use linear compression). Quantizers spreading from 2 to 6-or-7 with linear compression is pretty strange ... either it was not linear CC, or the payback delay was set very short - too short. A quantizer range like that should be obtained with some (real) asymetric curve compression, but not with a linear one. But, admittetly, single high quantizers could also result out of the I/P/B-problem, see further below.

IMHO, for automatic curve compression, we don't need (much) more than what we have now. Perhaps something like "I want to use the exact quantizer range from x to y, please scale accordingly!", because that is hard to achive currently. With normal CC, it's try-and-error, and with alt-CC you need to know exactly what you're doing, it's a little tricky.

The problem for now is that, speaking exactly, XviD's 2-pass control is broken ATM, when B-frames are used. The fact that I/P/B-decision "lives its own life" in 2nd pass, produces some strange things. Look close at the DebugView output of a 2nd pass for some time, and the problem gets obvious very soon ... but again, because of XviD's very good rate control, this doesn't matter too much in the end: the error compensates itself. (Apart from the "too-few-Iframes - problem, but that's another story).

What I would like to see, beyond automatic curve compression, is some kind of editing tool that allows manual curve editing. The users of CCE know what I mean ;)

A further improvement could be the sometimes mentioned measurement of scene complexity: using higher quants on big frames is OK if the frame is big because of high motion. But it's not so OK if the frame is big because of very much detail with low motion. I hope the XviD developpers still have that topic in mind.

Finally, I want to mention that, for my very personal taste, I don't scale linear no more. For me, the good old finding that you can't easily notice errors and light artefacts in hi-motion-scenes, is still correct. On hi-mo-scenes, I don't see so much difference between q4 and q5, but on still scenes, I like q2 much more than q3 ... therefore, I'm back to some light compression, somewhere around hi=20, lo=10 for standard CC. I'd like to do more testing with the - almost forgotten - alt-CC, but there's only so little time for me :mad:

@ ProfDrMorph: oh yeah. Measurement of perceived image quality would be a very good thing, indeed. Alas, no-one suceeded in finding a formular for that, up to now ;)


Regards

Didée

[temporance]

Originally posted by Didée
First, for DivX explicitely, n-th pass is a useful feature. From start, DivX has no clue at all how to distribute quantizers, since it uses "simple" CBR. In next passes, it still has no clue what is really going on in the clip, but with the approximation method, it gets to the point in the end. That is simple maths, more or less.

What do you mean by "simple" CBR? I don't agree that DivX has no clue on quantizer distribution...

IMHO, the second pass of DivX nth-pass performs better than xvid's second pass. I judge this by watching the quantizer fluctuation in both cases. (DivX modulation = 0.0, xvid linear)

DivX has the advantage of having the option to perform more passes. You don't have to do more than two and most times you won't need to. I'd guess that you get within 10% of the "perfect" quantizer vector after the 2nd pass and within 2% after the 3rd.

[unmei]

speaking strictly from the point of viewer, not watching into changing Quantizers, but how good the picture actually look to me : so far i've done 3 full OVAs with 3 pass and the only way i could tell a difference to the second pass was comparing frames on the TFT...no way to see a noticable difference while playing normally or on CRT. Well there must be a difference ;) but i wouldn't recommend using the 3rd pass not even in DivX, except you PC is fast (so to speak) and you dont use filters, otherwise it's a nice try to steal your clockcycles and sell that as improvment....well it might sound harsh, but the guys at DivXnetwork have to make some big steps before i turn the 3rd pass back on...