True Quality Compression

(a.s. Sorry - no matches. Please try some different terms..... ok? ) Constant quality compression, the topic is old, by this is meant using a constant compression quantizer along all the movie, the results of this is a lower quality in static parts and higher in fast motion parts, then the real quality is not constant, it should be called just "constant compression". The nearest way to true quality comp,and thus real variable bitrate, is using DRFs in nandub, i mean one drf(or quantizer) for each level of motion, es. drf 3 until motion 100, drf 4 until motion 270, drf 5 over 270, of course you lose size predictabily, but sometime that is not an issue. This is a feature of old nandub not still implemented in any new coded "post 3.11", any chance that it will be soon? i think that should be easy as useful to do. For my present encodes im still stick to 3.11+nandub, someone laugh at this, but as Doom says new codecs still dont have clearly surpassed sbc. However that will happen shortly, and i am already impressed from the xvid visual quality, i will pass to xvid as soon as play problems will get fixed and really would like to see that useful feature in it.

Quality is not necessarily a function of the quantizer for the entire movie, since it is also dependent on both image content and motion too ... I think that was what movmasty was trying to say. Ive never found the constant quality mode's name particularely descriptive.

"If you want constant quality, use 1pass quantizer mode." He meant: "If you want constant quantizer, use 1pass quantizer mode." What he meant should have been obvious, since in the statement before he said, "...constant quality does NOT mean fixed quantizer. It means AVERAGE quantizer." Anyway, cheers!

if he meant "If you want constant quantizer", he had to write "If you want constant quantizer" but What i meant should have been obvious, in my post is said that i dont want constant quanzier, cause doesnt give constant quality, i want constant quality by using different quantizers based on frame motion. This is a nandub feature that i will miss when passing to xvid, i just asked if 2-PASS "based on motion" quantizers could be implemented in the codec.

Movmasty, you may want to invoke the search function about "motion dependant quantizing". XviD simply doesn't need this as it has advanced motion search algorithms which do their job properly. DivX3 needed it as it only had _1_ motion search precision, no qpel,... and so on. So you needed to modulate the quanitizers in that manner you can save bits where it is less obvious - during high motion. Btw., we support external scaled stats files, you can simply write a program to scale the scenes differently. Some nandub techniques are not necessary for xvid, period. We won't do some weird hacks like motion adaption - the only thing which _might_ come into play would be a dedicated "scene complexity" analyse (which has nothing to do with motion btw.). Koepi

>XviD simply doesn't need this as it has advanced motion search algorithms which do their job properly. (6-ultra high,quant type "mpeg") more info on used codec and some screenshots: [note: both divx3 and ffvfw got this scene correctly and only xvid screwed.....i can provide more avi's that will prove this...] cheers Ivo

Koepi, if it saves bits and is not noticeable, why wouldn't it help, even with "advanced motion estimation algorithms"?

Dave, because the ME sees the motion correctly. What movmasty failed to see is that his "constant quality" approach isn't constant quality if he lowers it for high action scenes. And that solution is far from perfect: on the one hand, xvid uses higher quantizers for such scenes anyways on 2nd pass due to the bitrate overconsumation and the worse compressability. On the other hand _I_ clearly see if the quality is worse in "high motion". The high motion attempt is flawed in other ways as well - just imagine a movie like shanghai noon where people run around on a driving train. Will sure look horrible when increasing the quantizers.... Regards Koepi PS: I4004 - I watched that clip even if I didn't want to surf to your site (mad green you use...). Maybe _I'm_ the stupid one here, but decoding with ffdshow i can't see a problem. How old is the clip? Which build did you use? "Reporting" outdated bugs is really bad manners. Maybe you should try current snapshots.

>Maybe _I'm_ the stupid one here, but decoding with ffdshow i can't see a problem. lol! something told me that you were going to say that! if that looks fine to you,then....(huh i'm not gonna say some words that might offend..) anyhow,orange-ish and red-ish parts above and below the camera are completely distorted and look like some evaporation ocurred,and off course it didn't...(yes i watch with ffdshow too,as xvid's decoder is too slow for this res on my machine) >Which build did you use? [xvid:core2.1,13:44:06,Oct13 2002,Nic's build.......] >Maybe you should try current snapshots how many of them? i have other builds and they too have simillar problems.... you guys have come up with mpeg4 system that is sharper than divx3,but i keep seeing this ME problems....perhaps there's too much noise in my capturings ( but for hi-motion video there's no point in denoising ) so there's not much space (bitrate) left for MV's, but if divx3 can do it properly....... ok,cheers... (keep the good work (Nic especially) and i hope this bug was corrected/will be corrected.......)

It is strange that nobody experienced a problem like this before. Anyone else? Anybody at all? If not, I'm afraid the developers won't make much of a fuss about it. Sorry and good luck with your encodings. Well, only VDub-captures would be valid evidence of an actual bug, anyway. Otherwise it would point to problems of the DShow-filter. But, re-reading your post, you only use ffdshow to test? This is completely unreliable. Which build of ffdshow, anyway?