XviD-14052003-1.exe

[Koepi]

You should always use "dx50 bvop compatibility", else the delay is as much as your max bframe settings is (3frames in PAL (=40ms per frame)=120ms). [Well, this isn't totally true, the pad/delay frames can come much later, thus you have a varying delay as possibility too).

Regards
Koepi

[nexus]

Hi,

I'm not sure, but has the default setting for "payback" changed from "with bias" to "proportionally" in this build? And is there an reason for this, because I thought "with bias" was recommended?

--
nexus

[digitize]

Personally I like proportionally better, pays back evenly across frames. Bias only pays back to high bit rate scenes, which might be useful for a high-action movie, but usually I'd just use proportionally.

[lighty]

Originally posted by Gazza

Anyone see this problem too?


Do you use VDubMod 1.5.1.1.a? It introduced some muxing problems- try looking at the VDM forum.

[Kamui-Dash]

What do you mean by Bias only pays back to high bit rate scenes and proportionally pays back evenly across frames?

Originally posted by digitize
Personally I like proportionally better, pays back evenly across frames. Bias only pays back to high bit rate scenes, which might be useful for a high-action movie, but usually I'd just use proportionally.

[nexus]

@digitize: It seems that your explanation is not correct.

Payback proportionally gives saved bits to all frames. Each frame gets the same percentage of bits. Of course big frames get more bits absolutely than small frames.

Payback with bias prefers SMALL frames and therefore gives more bits to them and less to big frames.

So, if you go for high bit rate encodes it would be better to use "with bias".
I hope my explanation is correct.

P.S.: Thanx to Selur for his german guide. :-)


--
nexus

[kilg0r3]

Ok, since there are so few things to compleain about, I'll start whining about a small bug (I believe it is one) in the vfw interface.

In the Credits Encoding Tab, when you enter 0 as last frame for the end credits, it would be nice if xvid could interpret this as 'until last frame of movie'. ATM, when you enter something like 120000 in the end credits start field and leave the end field at 0, xvid discards the values on pressing the bug.

As you can see, this is a dramatic malfunction, which is prone to destroy many encodes _and_ pieces of hardware. So, I will not use Xvid again until this gets fixed! ;) As if anyone cared :D

[Didée]

After a long time of searching, I also found an extreme serious lack in this build:

Despite the fact that most of the tooltips have been updated very nicely (good work!), there is no tooltip at all (!) for the option "enable greyscale" !!!

IMHO it is unacceptable not to have a tooltip for this mysterious option. Could someone please explain what that crazy thing is doing?

:)


Great build.

[Gazza]

Originally posted by lighty
Do you use VDubMod 1.5.1.1.a? It introduced some muxing problems- try looking at the VDM forum.

Lighty,
Yes I used vdubmod 1.5.1.1.a but to video encode only. I used oggmux to do the muxing. I had a look at the VDM forum but couldn't see if the synch problems reported there was directly related to what I see. Or I've read it and not understood it (which could be the case).

Koepi,
I use "dx50 bvop compatibility" exclusively so does this mean I shouldn't see any b-frames related delay.

Anyway, nobody else has reported having these same issues so it could be something I've done either in my set-up or encoding..

Thanks for your help.

[Koepi]

That particular vdubmod build might not correctly drop pad(delay-)frames and as such introduce that delay.
Do as suggested, try again with a newer vdubmod-build.

Regards
Koepi

[Gazza]

Thanks Koepi, I'll give it a go and report back my findings....

[Gazza]

Koepi, is there a version of vdubmod later than 1.5.1.1.a? I've searched all over (forum, VDM project & sourceforge) and not having any luck with locating a new update (if there is one out yet).

Thanks in advance

Gazza

[Sigmatador]

a recent CVS snapshot
http://peque.homeftp.org/~dext/stuff/vdubmod-1.5.1.x-030519.zip

[Gazza]

That's great Sigmatador, I'll give it a go.

Gazza

[bkam]

Originally posted by Defiler
Clearly,
XviD-TheFifteenthOfMay_InTheYearOfOurLordTwoThousandAndThree_LimitedEdition_FirstPressing.exe
is the most succinct and straightforward way to name these files. People might think that that date is Julian and not Gregorian :). Even though Scotland and England have had the Gregorian calendar since 1752, if you're from Russia or Turkey it only changed in 1918! And 1923 for Greece. :D So people might get confused.

XviD-TheFifteenthOfMay_InTheYearOfOurLordTwoThousandAndThree_GregorianCalendarNewStyle_LimitedEdition_FirstPressing.exe

[nFury8]

originally posted by bkam

XviD- TheFifteenthOfMay_InTheYearOfOurLordTwoThousandAndThree_GregorianCalendarNewStyle_LimitedEdition_FirstPressing.exe
That's one hell of a way to give the developers Tendinitis or Carpal Tunnel Syndrome :D.

[Gazza]

Originally posted by nFury8
That's one hell of a way to give the developers Tendinitis or Carpal Tunnel Syndrome :D.

Considering the commitment of the developers, I thought that was a prior requirement before becoming a contributing xvid developer?

[MrBunny]

Sorry to bring us back on topic, but has anyone else noticed problems with VHQ and the scene change detection (keyframe) algo. I tried a few encodes with all the advanced settings off except VHQ (so no GMC, Qpel, b-frames, chroma motion...).

When I used VHQ=0 scene change detection seemed fine (as expected).
As VHQ was increased, the algo seemed to miss more and more scene changes. Using VHQ=4, I was basically only getting i-frames at the max keyframe interval.

I'm hoping someone might have some insight into this.
Thanks.

EDIT: Actually it seems to be only when using custom quant matrices (I tried the andreas 78er and HSV best matrices). It might or might not occur with basic h263 or mpeg, though my quick additional tests with h263 seemed okay. I will test further when I have more time.

[Koepi]

The HVS good matrix works fine, too.

Regards
Koepi

[Acaila]

@MrBunny:
I've seen that effect ever since VHQ was first introduced (with both H.263 and MPEG matrices), and never thought anything bad of it. As long the frames look good and total bitrate decreases I don't think there's anything to worry about...

[JimiK]

As long the frames look good and total bitrate decreases I don't think there's anything to worry about.
Well, I didn't test this, but after all, isn't that a strange effect? When there is a scene change, then the frames are completely different, so you can't get any useful vector even if you do a vast search.
Then there is the other point: you may want to cut on scenen changes. I think that's the main reason why sysKin fixed it (thought he fixed it??)
Best regards,
JimiK

[N_F]

Originally posted by MrBunny
When I used VHQ=0 scene change detection seemed fine (as expected).
As VHQ was increased, the algo seemed to miss more and more scene changes. Using VHQ=4, I was basically only getting i-frames at the max keyframe interval.

How did you check it for keyframes? VirtualDub seems to report XviD keyframes wrong for some reason. If you use that option in ffdshow which shows frame type the keyframes usually seems to be on place (though on second thought, that is only my experience with VHQ 1 as I don't use VHQ 4).

[sysKin]

Originally posted by MrBunny
[B]When I used VHQ=0 scene change detection seemed fine (as expected).
As VHQ was increased, the algo seemed to miss more and more scene changes. Using VHQ=4, I was basically only getting i-frames at the max keyframe interval.Yes, it's not a surprise for me. Once you perform a motion search which tries to decrease bits (this new R-D VHQ still does that, even if not that aggresively), you have a bigger chance to code a macroblock with small number of bits - smaller than intra coding (which can't be decreased in any way).
As you need 50% of all macroblocks to be intra coded before you have an i-frame, it's possible that you won't reach 50% after all, and the frame will still be a p-frame...

I don't know what I can do about it other that using a different value than 50%...

The good news is that all you have to do is to use b-frames (even max = 0) - a completely different scene-detection algorithm will be used, not affected by VHQ.

[N_F]

Originally posted by sysKin
The good news is that all you have to do is to use b-frames (even max = 0) - a completely different scene-detection algorithm will be used, not affected by VHQ.
Guess that would explain why I (and many other I guess) haven't noticed it.

[duartix]

I don't know what I can do about it other that using a different value than 50%... How can we change that? Isn't it hardcoded in the codec? Wouldn't it require a custom build?
Are there good reasons why that is not a parameter in the codec GUI?

[Defiler]

Originally posted by duartix
Are there good reasons why that is not a parameter in the codec GUI? Well, you know how XviD likes to cut down on the number of options users have to play with. One-Click Encoding, and all that. [/Sarcasm]
Heh.

[Acaila]

It used to be a parameter in the GUI but nobody changed it because 50% was the most optimal value IIRC. That was quite a while back.

[mf]

Originally posted by Defiler
Well, you know how XviD likes to cut down on the number of options users have to play with. One-Click Encoding, and all that. [/Sarcasm]
Heh.
Actually, we make jokes on IRC about adding more settings until the n00b's mind stack overflows. :D

[Sigmatador]

Originally posted by mf
Actually, we make jokes on IRC about adding more settings until the n00b's mind stack overflows. :D

ROFL2 :D

[crusty]

Ok, I just want to add something constructive here:

I made some test of this codec on two different clips.
The clips are the start credits and intro, and the end credits from the movie mad max 2.

It's a very noisy PAL progressive source so I used the following filter selection:

Cut&Paste from the avs:
Start credits+intro:
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\FluxSmooth.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Undot.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Cnr2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Unfilter")
mpeg2source("E:\ROAD_WARRIOR169\VIDEO_TS\max.d2v")
Killaudio()
trim(0,6053)
crop(4,80,712,412)
Undot()
LanczosResize(576,224)
Undot()
#Cnr2()
Temporalsoften(3,4,3,mode=2,scenechange=6)
(10,15)
Limiter()
Unfilter(-2,-2)

Note: I tried Cnr2 but I produced serious ghosting at it's defaults.

For the end credits:
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\FluxSmooth.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Undot.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Cnr2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\Unfilter")
mpeg2source("E:\ROAD_WARRIOR169\VIDEO_TS\max.d2v")
Killaudio()
trim(132599,0)
crop(4,80,712,412)
Undot()
BilinearResize(576,224)
Undot()
Temporalsoften(4,8,8,mode=2,scenechange=10)
Convolution3d("movielq")
FluxSmooth(10,15)
Limiter()
Unfilter(-2,-2)

I encoded this first to Huffyuv lossless avi.
Sizes were about 376 and 303 MB for a 4 min and 3 min clip
The first clip has no scrolling credits, the second a lot.

I then encoded both clips to Xvids using Vdubmod 1.5.1.1a and Avisynth 2.5 stable.
1-pass quantizer=2
Other settings that were common:
Motion Search = 6, QM=H263, 4CC=Xvid, Max/Min I= 200/1
Chroma Motion+Chroma Optimizer, NO Trellis,
B-frames at 2/150/100/different tresholds, DX5VOB=on
Alt-cc off and else at defaults.

First clip, start credits + intro:

Huffyuv=376 MB
B-frame treshold(BFT)=0 size=18.140 KB Average Q=3.16
BFT=255 16.070 KB AQ=3.32
BFT=255, VHQ=4 15.640 KB 3.32
BFT=255, VHQ=4, Quartel Pixel(QPel) 15.474 KB 3.32

Interestingly Qpel was very slow. It produced the smallest filesize, although only by a small margin, but it almost DOUBLED the processing time. I can't recall Qpel being that slow now really?
Now the end credits:
I decided to do some test with GMC, cause I figured GMC could work maybe to enhance compression on the scrolling credits.


Huffyuv=303 MB
BFT=0 size=23.782 KB AQ=3.05
BFT=0, VHQ=4 23.612 KB 3.05
BFT=0, Qpel 16.606 KB 3.04
BFT=250 19.740 KB 3.33
BFT=255 19.740 KB 3.33
BFT=255, GMC 19.888 KB 3.33
BFT=255, VHQ=4 19.604 KB 3.33
BFT=255, Qpel 13.030 KB 3.33
BFT=255, VHQ=4, GMC 20.082 KB 3.33
BFT=255, VHQ=4, Qpel 12.910 KB (!)3.33
BFT=255, VHQ=4, Qpel, GMC 13.842 KB 3.33

Again, Qpel was hella slow :(
Remember, all this was at Q=2.
I then did the end credits by 2-pass, using BFT=255, VHQ=4, and Qpel.
I found I could go to at least 5000 KB for filesize instead of 12.910 KB before even seeing any artifacts.
Note that all the different clips look exactly the same. I can't find anything wrong with all of them.
However, when I played these clips in WMP6 using ffdshow, I found them to stutter occasionally. I couldn't reproduce the effect on the exact same frame at all when I tracked back and watched it again.
I haven't seen this effect before with Xvid so I don't really know where to start looking, but I'll try different players and let you know.

Some conclusions.
-Qpel is slow, very slow. Up to 100% percent slower in these clips.
Qpel reduces filesize by a THIRD in the second clip! It only adds 1% compressability with the first clip. Weird..... :confused:

-VHQ=4 doesn't reduce size that much, the effect on the first clip was less than 3% and on the second clip less than 1% ! It doesn't add much processing time, but it's nowhere near 10% decrease in filesize.

-GMC Sucks. Period.

-BFT=255 helps a LOT in compressabilty, more than 10%
Only BFT changes the Average Quantizer.

Mind you, this test was with very particular footage..just credits.
The first clip has some real footage in it so I guess that's why Qpel didn't do a lot there.

Some stats for the 2-pass end credits:

2-pass AQ at given filesize:
11.026 KB AQ=3.60
9.026 KB 4.10
7.026 4.74
6.032 5.15
5.038 5.67


So I've now got a really GOOD looking end credits at a bitrate of 222kbps....LOL.
If you guys got any comments please mind that I'm only gonna keep these test files on my HD for a few days, a week at most.

I'm gonna post results on a fast motion torture testclip in a couple of days, so stay tuned.

[sysKin]

Crusty, could you please _not_ post "compressablity" tests? I wouldn't mind, but some people take it seriously, while the information you get from it is absolutely none.

Some people know more and will ignore it, others will be misguided - in any case this will be of no help to anyone.

Just let me repeat for everyone: FILESIZE at FIXED QUANT is filesize at fixed quant, absolutely nothing more. It does not say absolutely anything more than that. Period.
Some conclusions.
-Qpel is slow, very slow. Up to 100% percent slower in these clips.
Qpel reduces filesize by a THIRD in the second clip! It only adds 1% compressability with the first clip. Weird..... :confused:
No, it's not weird that qpel is slow :) The filters just need some computations, you can't help it. Nothing to be confused about.
-VHQ=4 doesn't reduce size that much, the effect on the first clip was less than 3% and on the second clip less than 1% ! It doesn't add much processing time, but it's nowhere near 10% decrease in filesize.VHQ stands for "very high quality", not for "10% off filesize". Old info about it, in "VHQ Manual" thread, is outdated :/ so don't take any numbers from there.
-GMC Sucks. Period.None of you tests shows that it sucks, you never said it was worse. It actually doesn't suck, but is _not implemented_. That's a difference.
-BFT=255 helps a LOT in compressabilty, more than 10%
Only BFT changes the Average Quantizer.So? Do your first pass using quantizer 20 and you'll get 500% compressablity. Nothing new.So I've now got a really GOOD looking end credits at a bitrate of 222kbps....LOL.Yes, that's an important thing you might all want to know: to encode credits, use max bframes = 5 and threshold = 5000. You can actually have your credits as small as you want, with no "smearing" behind it and with very reasonable quality.

Radek

[crusty]

could you please _not_ post "compressablity" tests? I wouldn't mind, but some people take it seriously

As far as I could tell, that seemed one of the principal ways to get a discussion going in this forum about the effects of certain options.....at least it's better than talking about build naming conventions now is it? :D

No, it's not weird that qpel is slow
It's just that Qpel 'seems' a lot slower in this build than in previous builds...but it could be my imagination.



VHQ stands for "very high quality", not for "10% off filesize".
In previous builds it did. Up to 10% decrease in filesize were the result. And in that thread it was also mentioned that VHQ could stand for anything you want...so this is new to me.
And I haven't seen anyone else mentioning the effects of the new VHQ, so here are my results, and I must say they differ from the previous effect of VHQ by a substantial margin. So I felt it interesting enough to post the results.
If it has changed so dramatically, perhaps the VHQ manual thread needs to be updated.

None of you tests shows that it sucks, you never said it was worse.
You're right, I've should have said "GMC sucks right now. period."
And my test show that filesize is increased everytime you use GMC up to several percent, without increased quality.
And that is on end credits, generally stuff that has a lot of 'general motion' in it.
use max bframes = 5 and threshold = 5000
Urmmm...right...you're not serious are you?
The end credits I have right now are perfect, they don't have ANY artifact.

I thought the effect of Qpel on this was worth mentioning though.
You don't get 30% reduction in filesize easily nowadays.

[sysKin]

Originally posted by crusty
[B]As far as I could tell, that seemed one of the principal ways to get a discussion going in this forum about the effects of certain options.....at least it's better than talking about build naming conventions now is it? :DYes that's right, and I'm doing my best to stop it. It might be more or less correct when the same options are used in the codec - but when you add qpel, bframes, different quant matrices etc it completely makes no sense anymore. Just imagine what would happen if we used quant 3 for first pass - the codec would remain the same, only "compressability" would change.

When you use bframes, or different quant matrices, or trellis quant similar thing happens: your first pass no longer has the same size _nor_ the same quality. Just as if it was something completely different now.
It's just that Qpel 'seems' a lot slower in this build than in previous builds...but it could be my imagination.Oh ok.... I dunno what's wrong.

In previous builds it did. Up to 10% decrease in filesize were the result. And in that thread it was also mentioned that VHQ could stand for anything you want...so this is new to me.Yes, but it also said that any VHQ bigger than 1 was decreasing quality. VHQ has been rewritten, it no longer has the old effect - now it improves quality rather then decreasing filesize.
If it has changed so dramatically, perhaps the VHQ manual thread needs to be updated.I wish we had some better way of explaining things than threads. It's difficult to tell what is absolete and what is not. Even our FAQ is absolete at places, and I can't just update it.
Urmmm...right...you're not serious are you?
The end credits I have right now are perfect, they don't have ANY artifact.Yes I am. And I mean it - you can even go below 222kbps and still have no artifact. That's pretty amazing imho, my LOTR (not-extended) credits were 1200KB in my last encode.
I thought the effect of Qpel on this was worth mentioning though.You don't get 30% reduction in filesize easily nowadays. Yeah, what I meant is that filesize is not a way to compare qpel and not-qpel. It just doesn't work this way.

Regards,
Radek

[crusty]

but when you add qpel, bframes, different quant matrices etc it completely makes no sense anymore.

? I thought I was adding this in a rather well-documented way....mentioned all the tools and settings I was using...it's not like I'm just blurting something out.
The whole deal of this kind of threads is to find bugs right?
:confused:
When you use bframes, or different quant matrices, or trellis quant similar thing happens: your first pass no longer has the same size _nor_ the same quality. Just as if it was something completely different now.
Like I said, h263 used, no other QM's. No Trellis used either.
And like I said, I watched all the clips and there was >no< difference in (subjective) quality.

Oh ok.... I dunno what's wrong.
That's what I meant. I can't recall Qpel being THAT slow. It adds about 80 to 100 % encoding time. Whereas VHQ=4 hardly adds any encoding time, at least on my system. I also tried with Vdub 1.5.4 and the result was the same on Qpel.

Yes, but it also said that any VHQ bigger than 1 was decreasing quality.
People got mixed results...some got artifacts while others didn't.
I guess it depends on the source.
VHQ has been rewritten, it no longer has the old effect - now it improves quality rather then decreasing filesize.
Well at least that's good to hear. ;)
Would you now consider it safe for general use even at VHQ=4?
And I'm glad to hear that VHQ now officially stands for Very High Quality. :D
BTW, it didn't add a lot of encoding time really...I found it hardly noticable.
In respect to the previous incarnation of VHQ, what exactly was changed that results in no artifacts and less compressibility?
I.e., did you just keep the 'safe' code, or did you do some other magic.
I personally found the extra compressibility of 10% well worth it. Just an opinion...
I wish we had some better way of explaining things than threads. It's difficult to tell what is absolete and what is not. Even our FAQ is absolete at places, and I can't just update it.
Always happy to rewrite some obsolete manuals.
Like I said before, perhaps we should try to get a documentation team together, who work together with the programmers.
I find Snowbeach's guide a good place to start, and I hope someone tells Doom9 to put it on his website.
We had this discussion about two months ago and I must say that a lot has changed since then...The thread about QM's, about B-frames, Snowbeach's guide, Nic's newbie settings....quite a lot of changes to the better I think.
Yes I am. And I mean it - you can even go below 222kbps and still have no artifact. That's pretty amazing imho, my LOTR (not-extended) credits were 1200KB in my last encode.
Geez...what bitrate? Did you use Qpel?

BTW, the stuttering I reported is probably something wrong with my PC....half my porn collection also suffers from it. :D

Yeah, what I meant is that filesize is not a way to compare qpel and not-qpel. It just doesn't work this way.
Uhm....I'm a bit confused now...filesize means a lot to people...everybody's trying to fit stuff on one or two CD's..so if you can encode something at a really low bitrate it's certainly worth mentioning, right?

And the clip with Qpel looked exactly the same as the clip without Qpel. It just was 1/3 smaller.
I already mentioned that these were test on some very particular stuff...end credits. I also mentioned that the first clip, which did have some real-world footage in it, didn't produve such a dramatic result. I can imagine people reading over that, everybody does now and then, but I did mention it.

I always encode end credits separately, because I want to have the best filesize possible for the real movie. So I try to stuff the credits into as little space as possible.
So for me the effect of Qpel on this particular clip makes it worthwhile enough to ALWAYS test end credits both with and without Qpel, even if don't use it on the movie as a whole.
Offcourse it could still introduce smearing or stuff like that, but there's only one way to know..encode it and find out. All I say it's worth the effort of trying. Well worth the effort with end credits.

PS: I mentioned the average quantizer to show newbies that some things do and some things don't effect AQ. I didn't expect anyone else to mind.

[Manao]

Uhm....I'm a bit confused now...filesize means a lot to people...everybody's trying to fit stuff on one or two CD's..so if you can encode something at a really low bitrate it's certainly worth mentioning, right? What Radek meaned was that you can't anymore encode a movie at quant 2 with different settings and assume that the settings which give the lower filesize are the best one. A proper test would be to make a two-pass encode for each settings, and run a PSNR test on the result ( or watch each clip carefully, but it's too subjetive )

I personally found the extra compressibility of 10% well worth it. Just an opinion... It's the same problem : if it gives a higher filesize at quant 2, it doesn't mean that it will give a lower quality in a two-pass encode.

[kilg0r3]

Originally posted by sysKin
[B]to encode credits, use max bframes = 5 and threshold = 5000. You can actually have your credits as small as you want, with no "smearing" behind it and with very reasonable quality.

Woah! So, we need some more fields on the credits tab :D!

[Gaia]

Just have to say this. Crusty tries to be ultimate vice guy who knows everything about encoding but seems to fail always.

[crusty]

A proper test would be to make a two-pass encode for each settings, and run a PSNR test on the result ( or watch each clip carefully, but it's too subjetive )
Like I said before, the quality looks the same for all the different clips. There were no glitches or artifacts.
I found the source of the stuttering and it has nothing to do with Xvid. It's a bug with creative soundblaster live and the Via kt400 chipset that's caused it. The pci latency patch fixed it hopefully.It's the same problem : if it gives a higher filesize at quant 2, it doesn't mean that it will give a lower quality in a two-pass encode.
So you're basically saying that the effect will be different when encoding with different quantizers?

Just have to say this. Crusty tries to be ultimate vice guy who knows everything about encoding but seems to fail always.
LOL ! :D
Well not always..... ;)
No problem m8 just learning here like the rest of us.

[JasonFly]

Originally posted by Manao

It's the same problem : if it gives a higher filesize at quant 2, it doesn't mean that it will give a lower quality in a two-pass encode.

That's what i'm wondering these days.For example, will an encode with hvsbest matrix would be better(visually) than an encode with andreas78er matrix which would have a higher average quant than hvsbest one's?

What I mean is that maybe with a qaunt 3 or 4 with andreas78er could be better than hvsbest at quant 2.

I haven't tested this yet but does anyone has ever tried?

[Acaila]

Do a two-pass encode and shoot for the same filesize. Compare the resulting files by PSNR and you've got your answer.

The differences between the used quantizer matrices make any prediction impossible, so you'll just have to test to find out.

[Defiler]

It is impossible (well, brain-combustingly tedious) to attempt to use the average quantizer to compare two encodes that used different matrices.
Divide all the numbers in a matrix by 2, and suddenly "q=4" is identical to the old "q=2"

[Acaila]

uhm, isn't that exactly what I just said? ;)

[JasonFly]

It's a shame that i didn't think to this before.
Thank you to have put me on the right way.

So, I have just to put my last matrix tests to the trash.
I have made tests at different fixed quant(q2,q4,q6) and i have studied the results(screenshots and psnr results).These test doesn't mean anything but at least I have an idea of visual quality of each matrix at these quant.

I have just to make an other process to redo my tests.

BTW, psnr results were strange.I have gfet them on the different channels and some psnr results with bulletproof HiQ or Hvsbest were lower than h263 ones.Isn't that strange? The strangst was that the visual quality of the screenshots were best with the two first matrix(as we could have exêcted)
The source was noisy and i didn't use any advanced option of xvid.

[mf]

That depends on your target bitrate. MPEG and HVS Best are designed for high bitrates, if you go too low, a low-bitrate matrix will give better results.

[AS]

Originally posted by JasonFly
BTW, psnr results were strange.I have gfet them on the different channels and some psnr results with bulletproof HiQ or Hvsbest were lower than h263 ones.Isn't that strange? The strangst was that the visual quality of the screenshots were best with the two first matrix(as we could have exêcted)
The source was noisy and i didn't use any advanced option of xvid.

There is no direct relation between preceived quality and psnr.

[JasonFly]

I thought that psnr give an idea of the closing of the encoding clip faced to the source?

I also did psnr test on the source(d2v faced to d2v) and the result was higher than 100db.Is this ok?

[sysKin]

Originally posted by JasonFly
I also did psnr test on the source(d2v faced to d2v) and the result was higher than 100db.Is this ok? In theory, the result should be infinity, but computers are not that precise ;)
Anyway, 100dB is such a huge number, it just doesn't matter.

Radek

[gino25]

when there will be a new koepi version?

[MoonWalker]

Originally posted by gino25
when there will be a new koepi version?

There will be a new version when there will be a new version...If you want you can go to the CVS of XviD, download the sources and make you own build :).It's easy...You can also have a peak at dev-api-4 (as I had and experiment with it :p)...

MoonWalker

[bond]

you can also get the latest available sources always from uManiac (http://umaniac.leffe.dnsalias.com/)