True Quality Compression

[movmasty]

(a.s. http://forum.doom9.org/search.php, 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.

[Koepi]

If you'd at least read something yourself (i.e. the help-file that ships with the xvid binaries or the XOE) you'd know that constant quality does NOT mean fixed quanitzer.

It means AVERAGE quantizer.

If you want constant quality, use 1pass quantizer mode.

Man, i was glad the last few months that such posts didn't come up here.

Movmastyroccosi, please think about your sound in your mails. It's still that old "i know everything better" attitude which really is disturbing as you clearly DON'T know anything better.

This isn't vcdhelp or Divx.com. Behave this way over there, you sure will find people that you can impress with these posts - here you won't find them.

Koepi

[movmasty]

ummmmm....
Originally posted by Koepi
...constant quality does NOT mean fixed quanitzer.
It means AVERAGE quantizer.
If you want constant quality, use 1pass quantizer mode

something sound strange there,since 1pass quantizer mode uses a constant quantizer.....

But since you wrote a nandub guide you know what im talking about.

Btw,roccosi...roccosi..want you really know where that nick comes from and why i changed?
That was a joke with my friends, roccosi haevent never been my nick,
Rocco Siffredi is an italian pornostar, i just had that nick on irc the first day i looked in this forum,
i didnt know i would became a regular(almost)
nor to meet a friend like you. :)

Another thing....
I tried to install your bins(unstable) here....
it said:
"movmasty computer detected-installation aborted-PRRRRRRRRRRR)
any idea about how i could get rid of that :confused:

[MfA]

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.

[Wormz]

"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!

[movmasty]

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.

[Koepi]

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

[^^-+I4004+-^^]

>XviD simply doesn't need this as it has advanced motion search algorithms which do their job properly.


http://free-zd.hinet.hr/ikostic3/
(6-ultra high,quant type "mpeg")

more info on used codec and some screenshots:
http://free-st.hinet.hr/ikostic3/video_/video.htm

[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

[SirDavidGuy]

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

[Koepi]

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.

[^^-+I4004+-^^]

>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.......)

[Teegedeck]

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?

[MoonWalker]

Just downloaded an there is NO problem at all. Looked at 2x with vdub.. (well,my eyes have now some problems)....

1)Do you have the same colour in you desktop as in your webpage?If so, it's logical to see those errors..

2)Maybe you super resolution can't display correctly the colours

MoonWalker

[sillKotscha]

Hi ^^-+I4004+-^^,

all I can see is a crappy analogue input source or at least a crappy analogue capture...

to try some [avisynth] filter_settings I've encoded with xvid 1pass_qbased and all fancy stuff turned on (GMC, Lumi, Qpel and Chroma motion). It is a bit too smoothed but related to Fluxsmooth and not to xvid...

if you're interested how xvid handles (my crappy) analogue [composite] input source, than you may want to have a look ;)

some dirty stuff encoded with xvid (http://www.sahnau.de/skotscha/Dirty@Pro7.avi)

I can't see any of your complains about xvid...

cheers Sill

[^^-+I4004+-^^]

take a look at divx3 version:
http://free-zd.hinet.hr/ikostic3
sure is lil bit smoother,blurrier than xvid with mpeg quant
,but it doesn't have a problem....

>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?

Teegedeck,why are you so stiff on opinion that xvid is THE BEST
codec?
i have presented you you with one xvid issue,and as soon as "xvid" and
"bug" is mentioned you're saying that i alone (what does that mean?that i modify source code of xvid to present it in bad light??LOL!)
have this problem,and that only VD captures are reliable evidence of bug....( somehow,someway this reminds me of Acalia's(is it Acalia?) post where he says that he compared xvid to divx3 (if i'm correct)
but as he couldn't spot difference in playbcak he did frame by frame analysis and said that xvid won..... what's that???? )

to answer your question ( although your immediate xvid defending tone doesn't deserve any answer really....) i use recent (i think 13.1.'03) ffdshow and it kicks ass if you ask me...( it seriously kicks xvid decoder's ass! )
furthermore i think ffdshow and milan cutka is the best thing that happened lately to mpeg4 scene....and ffvfw is already very decent codec....

>@MoonWalker

?
your post reminds me of your avatar:real funny!
you're really funny guy!

@sill
>@if you're interested how xvid handles (my crappy) analogue [composite] input source, than you may want to have a look

your scene is almost still camera.......my sample is real tough on encoder (much detail,noise,moving camera versus still graphics etc.)
[ and i said myself:DON'T dload sill's samples as you have did with
that "mjpeg flaw" stuff....i really burned myself dloading 5-6MB in vain.....insted you could post 2 jpeg's as i did.......and yeah,thanks for responding to few requests to explain mjpeg faults...
you're a sport! ]

don't misunderstand me:i don't want any codec wars : my intention was to show you graphically some things....i think you should see differences between divx3 and xvid's handling of this scene.....
i think i can provide more samples like this on demanding materials.
( let me just say this: toons are not demanding stuff.... )

and sure,i too would like sharpness of xvid without ANY problems,
and will dload recent build to see if stuff improved (i stil have this
source video...) and play with ALL functions of encoder...i hope this stuff will be ok on that builds.( not that build i used is vintage,is it ? )
if not i'll see you in another 6 months to see how are things going..


Cheers

Ivo

[Teegedeck]

*sigh*

Originally posted by ^^-+I4004+-^^
Teegedeck,why are you so stiff on opinion that xvid is THE BEST
codec?
i have presented you you with one xvid issue,and as soon as "xvid" and
"bug" is mentioned you're saying that i alone (what does that mean?that i modify source code of xvid to present it in bad light??LOL!)
[...]( although your immediate xvid defending tone doesn't deserve any answer really....)

*sigh*
OK, I'm guilty on this one; it's because we just had some very stressy experiences with some notorious spammer. No excuse for perhaps being too harsh with you.



i use recent (i think 13.1.'03) ffdshow and it kicks ass if you ask me...( it seriously kicks xvid decoder's ass! )



The thing is, it's not about which decoder is best, but it's about getting to the source of a potential problem. If you don't use XviD's decoder, technically you can only say that probably something doesn't decode well with ffdshow. But you can have no idea whether it's an ffdshow- or an XviD-problem. If you don't use VDub captures, you can't say whether it's a directshowfilter-problem or a decoder-problem.

You got the point? Good. And mind your tone.

[sillKotscha]

Originally posted by ^^-+I4004+-^^
your scene is almost still camera.......my sample is real tough on encoder (much detail,noise,moving camera versus still graphics etc.)
[and i said myself: DON'T dload sill's samples as you have did with
that "mjpeg flaw" stuff....i really burned myself dloading 5-6MB in vain....

huh :confused: what about my 2.8mb compared to 3.6mb from your GREENish site - but anyway, who cares...

Originally posted by ^^-+I4004+-^^
[and yeah,thanks for responding to few requests to explain mjpeg faults...you're a sport! ]

sport?? - repeating myself on 'n on isn't sport, it's just dull or at least Xtreme sport :D .
As I said in this peculiar thread - read through things before complain about them ;) [and btw, as you requested a thread about it I gave you a link... went through it??]

cheers Sill

[Nic]

Sorry guys, cant help but feel this thread isnt going to go anywhere good with this kind of tone.

@^^-+I4004+-^^: Thanks for your apparent bug, im sure it will be looked for and solved if found.

End of thread.

-Nic