XviD-14052003-1.exe

[Koepi]

Ahoy mates,

since all of you can't wait until features are tested a little bit... here's a new build up. Don't complain about anything if something goes wrong! You have been warned! :)

Changelog:

XviD-14052003-1:
- Minor fixes & cleanups in the motion estimation routines.
- VHQ revised. Slower, but always increases PSNR.
- negative bframe threshold works.

Trellis based R-D quantisation
This feature on the debug-tab is at that location for a reason: it's more experimental. It only works with h.263 quantisation matrix.
It's supposed to set DCT-coefficients to 0 if the distortion introduced by that is lower than a weighted amount of bits saved (coding 0-coefficients is efficient.).
It'll introduce a slight drop in PSNR by it's nature, but the filesize gain overcompensates for that (in 2pass scenarios, that is.)

R-D based VHQ modes
This feature works on motion estimation. It means that the mode decision of a macroblock (intra, inter,...) is based on the weighted bits saved with using the distortion introduced by this decision.
It's slow, but effective (even in 1pass scenarios). PSNR always increases, file size shrinks.
It's a little less efficient in terms of file size saved compared to the "old" VHQ code at low quantisers (2), but saves more space and gives higher PSNR as the old code at higher quants (4 and up). This also means that VHQ is fixed for higher quantisers (was buggy before).

EDIT: in cvs, sysKin used a lambda value of 1.0 for weighting the bits saved in his R-D based VHQ code. I tweaked that value to 1.35 to achieve the abovementioned results - just that nobody can complain I don't spread the information about what's tweaked in my build vs. CVS ;)

I hope I explained the features satisfactory, hopefully sysKin will step in if something's inaccurate here. For not spreading all the useful info over 3 threads I'll close the other 2 threads where these features were started being "discussed".

Best regards
Koepi

[MoritzT]

Thx Koepi
keep 'em coming...........
:D

Cheers

eMpTy

[digitize]

Well done all xvid developers, including all the guys in the #xvid devel chan like cruncher, etc... The new vhq is very nice, vhq 4 is now the best, rather than 1, and although the compression gain isn't as nice the quality gain is better. Also with the lambda fix, compression and psnr are better at higher quants (if you're trying to compress a long movie onto 1 cd or something to that effect)(thanks to cruncher/koepi's work). Again job well done to all xvid developers!

[CruNcher]

Great work syskin & koepi :)
following Psnr tests where gathered till now :)


Devapi3
---------
New Vhq 4 Quant 2 Lambda 1.00 = 12,1 MB (12.728.320 bytes) PSNR = 46.3027
Old Vhq 4 Quant 2 Lambda 1.00 = 11,0 MB (11.609.600 bytes) PSNR = 45.9569
New Vhq 4 Quant 2 Lambda 1.35 = 11,8 MB (12.393.472 bytes) PSNR = 46.2397

New Vhq 4 Quant 4 Lambda 1.00 = 5,40 MB (5.671.424 bytes) PSNR = 43.8920
Old Vhq 4 Quant 4 Lambda 1.00 = 5,40 MB (5.670.912 bytes) PSNR = 43.8914
New Vhq 4 Quant 4 Lambda 1.35 = 5,11 MB (5.363.200 bytes) PSNR = 44.0136

Devapi4
----------
New Vhq 4 Quant 2 Lambda 1.00 = 12,4 MB (13.022.208 bytes) PSNR = 46.3102
New Vhq 4 Quant 2 Lambda 1.35 = 12,2 MB (12.804.608 bytes) PSNR = 46.2672

New Vhq 4 Quant 4 Lambda 1.00 = 4,27 MB (4.486.656 bytes) PSNR = 43.4467
New Vhq 4 Quant 4 Lambda 1.35 = 4,20 MB (4.405.760 bytes) PSNR = 43.3472


thx to md´ for his results too :)

EDITED by CruNcher: added Devapi4 New Vhq results

[Koepi]

@Cruncher:

Thanks a million for posting the results here as well. And thanks for testing the modified lambda.

I did nothing special here - kudos to you for mentioning the tweakable lambda (or was that sysKin himself? Ah, too lazy to check the log ;) ).

And of course a BIG thanks to sysKin for porting skal's/gruel's trellis code to cvs head, and for spending so much time to code fancy stuff like VHQ and r-d based VHQ :)

I hope this build is as good as the first tests promise.

Best regards
Koepi

[mf]

Originally posted by Koepi
I did nothing special here - kudos to you for mentioning the tweakable lambda (or was that sysKin himself? Ah, too lazy to check the log ;) ).

16:11 <@sysKin> Koepi: as you might remember, VHQ was computing number of bits and finding minimum. new vhq computes (lambda*bits + distortion) and minimizes that
16:44 <@sysKin_away> 'LAMBDA' #defined in motion_est.h
:D

[Koepi]

Thanks mate :)

[Selur]

Thanks for the new build!

[mf]

Originally posted by Koepi
Thanks mate :)
Lastlog to the rescue :).

[vinouz]

Damn cool work.... But it bugs...
[5 mn later...]
Lumi masking is (still ?) broken. [edit : on second pass]

So let's give it a try... !


Zou, Galinette

[Defiler]

I've read the relevant threads, but I haven't seen an answer, and of course it doesn't work as a search term.. What does "R-D" stand for?
Thanks for the new version.
Perhaps D stands for Distortion?

[Koepi]

Rate-Distortion

[HailMeBaby]

koepi, how do you know the word ahoy, is it german? coz it sounds czech

[mf]

Originally posted by HailMeBaby
koepi, how do you know the word ahoy, is it german? coz it sounds czech
It's a common greeting used at sea.

[TheXung]

Originally posted by HailMeBaby
koepi, how do you know the word ahoy, is it german? coz it sounds czech

ahoy is a nautical term and I believe it comes from old english.

[OBcecado]

Hi, thanks for the new build :)
I'd like to know if there is any more info about R-D quantization method, if not this link http://www.informatik.uni-freiburg.de/tr/complete_g.html (Report No.139, April 2000)


Thanks for listening :D

[MetaHiro]

It's taking me about 20 hours/pass with the new VHQ 4 to encode Lolita. This better make it better than the DVD itself ;)

[Sgt_Strider]

I wonder is it safe to use GMC now?

[cipher]

:)It's taking me about 20 hours/pass with the new VHQ 4 to encode Lolita. This better make it better than the DVD itself
Just for curiosity and a basis for comparison, what was it before? 16 or even 12 hours? :)

[cipher]

And yes, thanks for the new build!!!

[MetaHiro]

Originally posted by cipher
:)
Just for curiosity and a basis for comparison, what was it before? 16 or even 12 hours? :)

10 hours :P

[Koepi]

Ok, historical lesson:

"ahoy" is indeed the greeting used amongst sailors. "Ahoy" is historically czech, and it was used amongst christs there AFAIK. Not that I'm believing in anything (god, bible,... all such weird stuff).
Later on, the english adopted that as greet amongst sailors, too.

(I'm from the very high north of germany, a so called "Fischkopp". That's why I often use that. Even if i'm now living near the bavarian border and can literally smell the mediterrannian seas [Göttingen is in the south of nether saxony]) ;) .

@Sgt_Strider:
There's nothing in the changelog about GMC :P

Regards
Koepi

[Selur]

takes me something like 7 1/2 hrs for each pass on my dual athlon system (vhq4,chMo, chOpt, trellis, qpel) with 55-65 cpu usage,.. (it's the same speed if I need to ivtc, but then cpu usage is 100% ;))

Cu Selur

Ps.: Koepi: posted this also in the xvid.org forum, but are there any thoughts about optimising Xvid a bit for dual cpu systems? (there's still some cpu power left, if I don't ivtc :D)

[N_F]

@Koepi - I just got to ask. What's the deal with the "-1" on all your XviD releases?

BTW, is it just me who gets confused with the dates sometimes? I'd like to refer to the currect binary as 030514 (yymmdd), but I guess germans use ddmmyyyy. And some countries seems to use mmddyy which can be really confusing.

[mf]

Originally posted by N_F
@Koepi - I just got to ask. What's the deal with the "-1" on all your XviD releases?
There might be more releases on 1 day.

[N_F]

Originally posted by mf
There might be more releases on 1 day.
Ok. Has it ever happended or is it "just in case"?

[JagPanzer]

Yes it has. I have XviD-18112002-2 build on my disk. But I am sure that it happened more than just once. :)

[kilg0r3]

Originally posted by N_F
I'd like to refer to the currect binary as 030514 (yymmdd), but I guess germans use ddmmyyyy. I'd also opt for this file-name format. Although this is not a big issue.

[Blight]

Personally, I'd go with May14_2003 as to make it very clear, but then again, That's me.

[kilg0r3]

If we wanted to upset koepi we ought indeed continue this discussion about filenames. BTW, Blight, your alternative might cause artifacts in combination with Qpel and VHQ.:D

[iago]

Merhaba Koepi,

Thanks for the new build!

Btw, what about "XviD-thefourteenthofmaytwothousandthree-one" ? :D

regards,
iago

[vinouz]

it wouldn't burn with the entire name on an ISO archive of all the versions of Xvid codecs. (considering one doesn't want to use joliet for greater compatibility with old macs)

;o)

[Defiler]

Clearly,
XviD-TheFifteenthOfMay_InTheYearOfOurLordTwoThousandAndThree_LimitedEdition_FirstPressing.exe
is the most succinct and straightforward way to name these files.

[Selur]

for those who are interessted, seems like my problem is connected to:
VHQ 1: CPUusage 100%
VHQ 2: CPUusage 60-70%
VHQ 3: CPUusage 60-65%
VHQ 4: CPUusage 55-60%
(all other features don't change the CPUusage)

Cu Selur

Ps.: OS=Win2kpro

[CruNcher]

added Devapi4 Psnr results with New Vhq

[Koepi]

iago:

serefe dostum, it's a pleasure to serve new builds :)

Selur:

you mean while encoding on dual proc?

@all:

We had thos "name format" discussions more often. And just for the habbit of it, I won't change it, the ddmmyyyy-buildversion format is the most logical one :) (IMO of course. Please don't discuss that further as it simply doesn't gain PSNR or compression.)

Best regards
Koepi

[Defiler]

Selur: I've noticed similar behavior when encoding on SMP machines.
I'm doing one right now that's only using about 65%, with VHQ=4, Trellis, Chroma Enhancer, Chroma Motion, etc. However, the input Avisynth script is rather complicated, so take that value with a grain of salt. With VHQ=1, and simple Avisynth scripts, I usually see 100%, or close to it.

[Selur]

@koepi:
Yes, I get these values if I encode on my dual proc system.

using the following avs script:
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
mpeg2source("D:\mercury\m.d2v")
crop(0,76,718,424)
LanczosResize(672,272)

[Herculezz]

Beautiful New Build Love It :)

[HughMagoo]

for big rips (2CD, etc) is it recommended at this point to use H.263 in conjunction with trellis option, or just stick with MPEG or MPEG-Custom and wait for trellis to come into play later?

this would be in conjunction with b-frames,qpel,chroma opt, chroma motion, VHQ4, and either MPEG quant or something like HVS-Best..bitrate ~1300kbps.

thanks for any feedback.. build looks very sweet!

[symonjfox]

Hey guys, I discovered that if you stay on all options, the box has been updated ... it's more dettailed and is useful for newbies :o

PS: I was a newbie, but days on search on this forum ... made me happy :D

[bond]

huh it says that vhq 2-4 isnt recommended for low bitrates!?

[spyder]

@bond: The GUI needs revised. syskin's new VHQ will not hurt quality. It's safe for all bitrates supposedly. Unless of course a nasty bug has snuck in :)

Spyder

[R3g]

Sorry to ask it there, but I've been away for a while and couldn't find it anywhere : what about the compatibility between VHQ and other advance features (GMC, QPel and so on). And, by the way, is there still some feature combination that could lead to broken result for sure ?

EDIT : Oups, finally I found my answer about VHQ : it seems to remain uncompatible with GMC, but to work with other features.

[symonjfox]

Don't use VHQ+GMC

The rest hasn't changed.

[R3g]

Originally posted by symonjfox
Don't use VHQ+GMC

The rest hasn't changed.
Well, actually thet's my point : the rest hasn't changed, since when ?
The last time I came here, Lumimasking was broken, and, if I remember well, using GMC+QPel was at our own risk.

[mf]

Originally posted by R3g
Well, actually thet's my point : the rest hasn't changed, since when ?
The last time I came here, Lumimasking was broken, and, if I remember well, using GMC+QPel was at our own risk.
Don't use lumimasking or GMC, they're not effective. That's all you need to know :p.

[bond]

Originally posted by mf
Don't use lumimasking or GMC, they're not effective. That's all you need to know :p. or read the Newbie Settings (http://forum.doom9.org/showthread.php?s=&threadid=53136)

[Gazza]

I used the latest gknot to test this latest build from koepi. I used me, bframes (2/150/100/0), no qpel, mpeg, vhq=4, chroma optimiser everything else was at default.
The stream info file generated by DVD Decrypter showed delay for audio was zero. I generated an ogg file using the zero delay.

However, when muxing video & audio using oggmux (not Gknot)with zero delay, I noticed that the end result is not synched. I'm wondering if the 3 frames offset (-120ms) has crept in again. I am going to run another test later (when I have the chance) by manually altering the delay and see if this is it.

Anyone see this problem too?


[edit] koepi - video quality was very nice. Excellent job.

[edit] I adjusted the video/audio by 120ms and the result is good.

[Sharro]

Originally posted by Gazza

Anyone see this problem too?



Not in my last 10 encodes or so...
All the best,


Sharro

[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/)

[mf]

Originally posted by gino25
when there will be a new koepi version?
When there are new things that are worth compiling into a new public version.

[Lobuz]

So when will be VHQ for B-frames? :D I thought about slowing down encoding a bit more to compete with newest "unstable" DIVX Tahanea with "rate distortion" etc. Hmm movie in 2 weeks - I'm curious if it could boost video quality for example 10% more?

Regards
Lobuz

[symonjfox]

AFAIK, VHQ for BFrames won't increase a lot the quality (as the Pframe one does). Let's hope well :p

[mf]

Originally posted by Lobuz
So when will be VHQ for B-frames? :D I thought about slowing down encoding a bit more to compete with newest "unstable" DIVX Tahanea with "rate distortion" etc. Hmm movie in 2 weeks - I'm curious if it could boost video quality for example 10% more?

Regards
Lobuz

uuuuuh like... xvid has had like rate distortion for ages.. and then you like.. wanna encode with divx tanahanea or something.. that sucks.. huhhuhuhhhuhhuhuhuhuhuh

[-=Stan=-]

I have recently noticed that XviD encoding at lower resolution aint working fine.
The codec seems to introduce a lot of Noise even without Qpel .
Is there anyway i can reduce this noise.

Another thing i noticed was that the codec was encoding much slowly with B-frames disabled than with B-frames enabling .
for example - With B-Frames 3/150/100/50 ---> 24fps
Without B-Frames ---> 17fps

I wonder whats causing this .
BTW my other settings are - Chroma motion , Motion Search 6, H.263 , Vhq 4 .
I was trying to encode a VCD with resolution 352 X 288 .

[HomiE FR]

@-=Stan=- : You're using VHQ=4, and like mf and others said just above, VHQ is only working for p-frames. With no b-frames, there are only p-frames and i-frames, so VHQ is working very often. With b-frames, maybe the codec is a bit slower (I haven't tested since I only use xvid with b-frames enabled now) because of b-frames but VHQ isn't enabled for each b-frame (so it's enabled very less often than without b-frames).
I guess VHQ has a higher impact on speed than b-frames (since you use VHQ=4 the effect is visible).

[-=Stan=-]

Thanks HomiE FR
I get it now.

But what about that noise thingy anyway i can get rid of it .

[vinouz]

What bitrate do you use ?

[-=Stan=-]

Vinouz

Bitrate is about 700 .
However the movie is very compressible.
i was doing 2 pass .
And the second pass-stats edited with Koepi stats reader was set to compression ratio of 1.5:1
So dont think that bitrate matters much .

[Danzel]

Have you tryed to do your second pass using 2nd pass int. instead of stats reader?

Danzel.

[-=Stan=-]

Dint do an internal 2nd pass but 100% quality based mode gave the same result so dont think that internal 2nd pass wud matter much .

[Danzel]

I have just converted a vcd compliant mpg into xvid using the latest xvid and my results have been fine using your settings.

have a look at your source material, perhaps its already noisy and xvid isnt able to handle it well.

you might try run it through an avisynth script to clean it up a bit, head over to the avisynth forums for more info on that.

Danzel.

[-=Stan=-]

My video is noisy .
I cleaned it up using Conv3D

But the XviD bit is noisy .
It seems much better when is set the decoder in ffdshow to XVID than libavcodec .
Anyways think i can cope up with that much artifact and enjoy the extreme
compression using XVID and Vorbis in an OGM.

712 MB compressed to 287 MB .
What more can i ask for .

[cweb]

I cannot give you any panacea but have you tried not using the chroma motion option? I don't tend to use it in general and I don't see this noise. In fact I even compressed at much lower bitrates (320, even 220) and the quality is of course reduced but it is not too noisy (compared to an equivalent wmv file) - I did that for some DV clips I wanted to put online in a low bandwidth version.

Edit: Yes, I do encode with XviD at higher quality bitrates (minimum 920, or 2-pass encodes)..

[PowerMacG4]

I just did an encode with minimum i-frame spacing at 0, and there are WAY too many I-frames. I saw a block of about 40 I-frames in a row. I cannot force I-frame spacing when using B-frames. Is there any way to improve this overly liberal use of I-frames?

EDIT: Oooh. Stupid me. Thought I loaded defaults when I really didn't...

[Teegedeck]

Why did you change that default? You want to use a minimum i-frame interval of '1', not '0'... :scared:

[pan]

Hello everyone,

I ran some tests over the weekend on all the features of xvid.
They were all ran in 2 pass mode, using in the first test 3% of the movie (4042 frames) and in the second 5% of the movie (6737 frames). With both I aimed for a filesize of 22000.

The movie was a very clean source Joe Somebody, quite a bright movie but very little action.

The script used was just

Crop
LanczosResize(592,304)

B-frames settings were x-150-100-150 where x is the number of bframes listed in the bframes column.

Test 1

speed vhq bframes cm lumi gmc ch opt qpel r-d 1stpass 2ndpass comp psnr y psnr u psnrv psnr ave
1 14.9 0 0 0 0 0 0 0 0 45462 22004 53.16 39.95 43.74 44.84 42.84
2 12.1 1 0 0 0 0 0 0 0 48504 22006 49.82 39.52 43.21 44.18 42.31
3 7.5 2 0 0 0 0 0 0 0 46820 22004 51.62 39.67 43.39 44.38 42.48
4 5.5 3 0 0 0 0 0 0 0 46152 22006 52.36 39.74 43.42 44.42 42.53
5 4.2 4 0 0 0 0 0 0 0 45568 22008 53.03 39.83 43.49 44.51 42.61
6 13.2 0 1 0 0 0 0 0 0 33582 22010 71.96 40.10 44.12 45.32 43.18
7 12.6 0 2 0 0 0 0 0 0 30108 22014 80.27 39.99 44.19 45.43 43.21
8 12.3 0 3 0 0 0 0 0 0 28720 22018 84.15 39.87 44.17 45.39 43.14
9 13.2 0 0 1 0 0 0 0 0 45174 22006 53.50 39.97 43.83 44.98 42.93
10 9.7 0 0 0 1 0 0 0 0 46702 22004 51.75 39.79 43.71 44.80 42.77
11 14.0 0 0 0 0 1 0 0 0 45462 22008 53.16 39.94 43.75 44.85 42.85
12 15.2 0 0 0 0 0 1 0 0 45480 22004 53.14 39.95 43.74 44.84 42.84
13 12.3 0 0 0 0 0 0 1 0 40928 22006 59.05 40.23 43.97 45.12 43.11
14 12.6 0 0 0 0 0 0 0 1 43206 22004 55.93 40.10 43.62 44.72 42.81
15 12.1 1 2 0 0 0 0 0 0 30868 22028 78.29 39.90 44.10 45.30 43.10
16 9.8 2 2 0 0 0 0 0 0 30164 22014 80.12 39.99 44.16 45.39 43.18
17 8.2 3 2 0 0 0 0 0 0 29894 22026 80.84 40.02 44.17 45.40 43.19
18 7.0 4 2 0 0 0 0 0 0 29482 22016 81.97 40.08 44.22 45.46 43.25
19 8.5 0 2 0 0 0 0 1 0 27942 22014 86.49 40.22 44.33 45.61 43.39
20 6.7 0 2 1 0 0 0 1 0 27708 22018 87.22 40.25 44.40 45.73 43.46
21 6.6 0 2 1 0 1 0 1 0 27680 22018 87.31 40.26 44.40 45.72 43.46
22 5.2 0 2 1 1 1 0 1 0 28476 22014 84.87 40.08 44.37 45.66 43.37
23 5.2 0 2 1 1 1 1 1 0 28476 22014 84.87 40.08 44.36 45.67 43.37
24 5.1 0 2 1 1 1 1 1 1 27650 22014 87.40 40.15 44.31 45.61 43.36
25 5.1 1 2 1 1 0 1 1 1 34902 22004 69.24 39.38 43.67 44.78 42.61
26 4.3 2 2 1 1 0 1 1 1 34316 22012 70.42 39.47 43.72 44.85 42.68
27 3.8 3 2 1 1 0 1 1 1 34008 22006 71.06 39.51 43.75 44.87 42.71
28 3.5 4 2 1 1 0 1 1 1 33908 22014 71.27 39.53 43.75 44.89 42.72
29 4.3 4 2 1 0 0 0 1 0 27567 22014 87.67 40.30 44.36 45.65 43.44


Test 2

vhq bframes cm lumi gmc ch opt qpel r-d 1stpass comp psnr y psnr u psnrv psnr ave
1 0 0 0 0 0 0 0 0 73634 32.82 38.14 42.57 43.30 41.34
2 1 0 0 0 0 0 0 0 77822 31.05 37.70 41.98 42.58 40.76
3 2 0 0 0 0 0 0 0 75100 32.18 37.81 42.13 42.76 40.90
4 3 0 0 0 0 0 0 0 74110 32.61 37.87 42.16 42.78 40.94
5 4 0 0 0 0 0 0 0 73224 33.00 37.95 42.22 42.86 41.01
6 0 1 0 0 0 0 0 0 53740 44.97 38.49 43.15 44.03 41.89
7 0 2 0 0 0 0 0 0 47884 50.47 38.46 43.29 44.20 41.98
8 0 3 0 0 0 0 0 0 45598 53.00 38.34 43.29 44.20 41.94
9 0 0 1 0 0 0 0 0 73182 33.02 38.12 42.69 43.47 41.43
10 0 0 0 1 0 0 0 0 75606 31.96 38.06 42.54 43.28 41.29
11 0 0 0 0 1 0 0 0 73610 32.83 38.12 42.57 43.30 41.33
12 0 0 0 0 0 1 0 0 73662 32.81 38.14 42.56 43.30 41.33
13 0 0 0 0 0 0 1 0 65972 36.63 38.50 42.87 43.66 41.68
14 0 0 0 0 0 0 0 1 70084 34.48 38.24 42.45 43.19 41.30
15 1 2 0 0 0 0 0 0 49000 49.32 38.37 43.13 44.01 41.84
16 2 2 0 0 0 0 0 0 47828 50.53 38.45 43.21 44.12 41.93
17 3 2 0 0 0 0 0 0 47502 50.88 38.48 43.22 44.12 41.94
18 4 2 0 0 0 0 0 0 46850 51.58 38.56 43.28 44.20 42.01
19 0 2 0 0 0 0 1 0 44256 54.61 42.24 43.48 44.45 42.24
20 0 2 1 0 0 0 1 0 43876 55.08 38.79 43.58 44.60 42.32
21 0 2 1 0 1 0 1 0 43858 55.10 38.80 43.59 44.59 42.33
22 0 2 1 1 1 0 1 0 45148 53.53 38.69 43.54 44.54 42.26
23 0 2 1 1 1 1 1 0 45150 53.53 38.68 43.54 44.53 42.25
24 0 2 1 1 1 1 1 1 43898 55.05 38.73 43.42 44.42 42.19
25 1 2 1 1 0 1 1 1 55648 43.43 37.79 42.66 43.45 41.30
26 2 2 1 1 0 1 1 1 55450 43.58 37.92 42.76 43.54 41.39
27 3 2 1 1 0 1 1 1 54878 44.04 37.94 42.73 43.53 41.40
28 4 2 1 1 0 1 1 1 54262 44.54 38.02 42.77 43.61 41.47
29 4 2 1 0 0 0 1 0 43472 55.59 38.83 43.47 44.45 42.25



I havent entered in speeds into the second test as they were much the same as the first.
I haven't actually had time to visually check all of them yet but the ones I did look at honestly weren't that different from each other.

I used psnr4avi to compare the psnr values.

I'll let you draw your own conclusions from the results.

Any comments are appreciated, hope this helps some people when deciding their settings. If anyone can see any flaws in the tests I'd be happy to rerun them.


Pan

[sysKin]

Something wrong with VHQ _again_:( :( :(

[superdump]

Very interesting results. From what I can make out at a glance chroma optimiser and vhq actually lower the average psnr very slightly.

Lines 20 and 21 hold the highest psnr (unless i missed one :)) in both tests.

Thanks for running those tests pan.

I've read people saying psnr isn't the best measure of quality with regard to the human eye. So is there a better measure that's easy to do?

Thanks again.

[Nibor]

Yeah, lower your display resolution, open two encodes each in VDubMod, place the windows both on the same position, go to a frame, switch between the two windows and compare (with the human eye :D :D :D )

Just my 0.5 cents :p

[mf]

Originally posted by Nibor
Yeah, lower your display resolution, open two encodes each in VDubMod, place the windows both on the same position, go to a frame, switch between the two windows and compare (with the human eye :D :D :D )

Just my 0.5 cents :p
I usually do a StackHorizontal(), hold the right arrow button, and look left and right as fast as my eye muscles will let me :D. I recently did that with 3 clips, by doing

blank = BlankClip(clip1, $000000)
row1 = StackHorizontal(clip1, clip2)
row1 = StackHorizontal(clip3, blank)
StackVertical(row1, row2)
:D

Human eye comparing pwnz :P.

[Nibor]

Originally posted by mf
I usually do a StackHorizontal(), hold the right arrow button, and look left and right as fast as my eye muscles will let me :D
Hey mf you're a damn f****** cool guy!!! :D
I didn't know this method before! It's exactly what I looked for, to compare two clips while playing... Until now I had to watch a part of one clip close it and watch the same part of the other clip... This way it was really hard to tell the quality differences of the two clips!
You're good yo! Na na, you're good! You're better than good, you're real good! :)

[bond]

why dont you use avscompare (http://forum.doom9.org/showthread.php?s=&threadid=40675&highlight=avscompare)?

[mf]

Originally posted by bond
why dont you use avscompare (http://forum.doom9.org/showthread.php?s=&threadid=40675&highlight=avscompare)?
I'd say this is easier.

[Nibor]

Thank you guys...
(I'm proud of my 11th post :p *gg*)

PS: For those who understand German.. Did you know what "hand gelenke" means in English?? Babelfish says that it's "hand of joints"!! *lol* pretty off topic heh :D ...

[jang0]

Originally posted by Nibor
Thank you guys...
(I'm proud of my 11th post :p *gg*)

PS: For those who understand German.. Did you know what "hand gelenke" means in English?? Babelfish says that it's "hand of joints"!! *lol* pretty off topic heh :D ...

wrists.

Don't use Babelfish, it sucks hard. Use dict.leo.org instead.
Anyway, this is totally Offtopic.

Hmm, sad to hear that vhq still has problems. perhaps the psnr values are from 1st pass file instead of the final final :devil:

[pan]

The psnr values are for the second pass, not the first.
The only reason I left the first pass file sizes there was to show the different compressibility of each clip.

Pan

[Prettz]

Originally posted by mf
I usually do a StackHorizontal(), hold the right arrow button, and look left and right as fast as my eye muscles will let me :D. I recently did that with 3 clips, by doing

blank = BlankClip(clip1, $000000)
row1 = StackHorizontal(clip1, clip2)
row1 = StackHorizontal(clip3, blank)
StackVertical(row1, row2)
:D

Human eye comparing pwnz :P.
I used to do that, but it wasn't very useful for me. Use Interleave() instead, that way you can hit left, right, left, right over and over in vdub to compare frames instantly.


edit: isn't very useful -> wasn't very useful for me

[Didée]

Originally posted by sysKin
Something wrong with VHQ _again_ Could you tell us a little more?

[BoNz1]

Didée, I don't want to guess at what syskin meant but I can tell you what jumped out at me when looking at pan's test, just if anyone didn't spot this:
speed vhq bframes cm lumi gmc ch opt qpel r-d 1stpass 2ndpass comp psnr y psnr u psnrv psnr ave
1 14.9 0 0 0 0 0 0 0 0 45462 22004 53.16 39.95 43.74 44.84 42.84
2 12.1 1 0 0 0 0 0 0 0 48504 22006 49.82 39.52 43.21 44.18 42.31

PSNR goes down when using vhq 0 to 1, :( but 1-4 increases PSNR as it should. This occurs in the second test too.

[sysKin]

OK guys, VHQ has been fixed.
Thanks for your tests!

Radek

[Th3-S4int]

Originally posted by sysKin
OK guys, VHQ has been fixed.
Thanks for your tests!

Radek
And when will koepi release it?

[bond]

btw: where is koepi?
he only visits doom9 very rarely anymore?

[Koepi]

I'm here but i seldom feel the urge to add something to the current threads ;-)

I could make a new build available soon.

Regards
Koepi

[Sigmatador]

@koepi
is it possible for the next build to use de optimized trbarry simple idct code for decoding ? :D

[Selur]

@Koepi:
A new build would be cool :D

Thx in advance :)

[bond]

Originally posted by Koepi
I'm here but i seldom feel the urge to add something to the current threadsyeah but sometimes i really think that it would be great if you would answer ;)

[jang0]

Got a small question:

What is hinted ME? I remember it used to be a big no-no and now it's even greyed out. Will it be available in Xvid 1.0? What does it mean and what advantages does it have?

[sysKin]

Originally posted by jang0
What is hinted ME? I remember it used to be a big no-no and now it's even greyed out. Will it be available in Xvid 1.0? What does it mean and what advantages does it have? 'Hinted ME' means that motion estimation is only performed in 1st pass, and the information are written to a file. In second pass, instead of re-computing motion, the file is used.
The idea looks OK at first, but practice has shown that it completely doesn't work. Motion information in mpeg4 is not strictly dependant on real motion, it's rather something based on motion, reference picture (which depends on quantizer), current quantizer etc. Copying the motion information from first pass just looked horrible.

Hinted ME will not be available in 1.0, and is not planned in the future.

Radek

[bugsan]

some tests of bframes ...

xvid koepi 14-05-03, 2pass: 20000ko (650kbps)
avisynth 2.52
Athlon XP 2000+
Mpeg2Dec3 1.08
Xvid internal decoder (not ffdshow), no PP
---avs------avs------avs------avs------avs------avs---
mpeg2source("E:\Ripping\lotrcutted\lotr.d2v",idct=7)
Crop(4,80,-4,-80)
BicubicResize(640,256,0,0.5)
---avs------avs------avs------avs------avs------avs---
clip1 = mpeg2source("E:\Ripping\lotrcutted\lotr.d2v",idct=7)
.Crop(4,80,-4,-80).BicubicResize(640,256,0,0.5).ConvertToYUY2()
clip2 = directshowsource("xvid_bf_XX.avi",fps=25).ConvertToYUY2()
Compare(clip1,clip2,"YUV","psnr.log")
---avs------avs------avs------avs------avs------avs---

XviD default psnr : 41.9028

|---------|---------|---------|---------|---------|
| 1 - 150 | 1 - 190 | 2 - 150 | 2 - 190 | 3 - 150 |
|---------------|---------|---------|---------|---------|---------|
| bf thresh 0 | 41.8666 | 41.8749 | 41.7618 | | 41.7480 |
| bf thresh 25 | 41.8644 | 41.9009 | 41.7545 | | |
| bf thresh 50 | 41.8874 | 41.9208 | 41.7434 | | |
| bf thresh 75 | 41.9128 | 41.9268 | 41.7214 | | |
| bf thresh 100 | 41.9674 | 41.9607 | 41.7448 | | |
| bf thresh 125 | 41.9593 | 41.9678 | 41.7549 | | |
| bf thresh 150 | 41.9624 | 41.9689 | 41.7559 | | |
| bf thresh 175 | 41.9702 | 41.9749 | 41.7580 | | |
| bf thresh 200 | 41.9859 | 41.9799 | 41.7681 | | |
| bf thresh 225 | 41.9846 | 41.9652 | 41.7739 | | |
| bf thresh 250 | 41.9782 | 41.9784 | 41.7775 | | |
|---------------|---------|---------|---------|---------|---------|
| bf offset 0 | 41.8797 | | 41.8257 | | 41.8153 |
| bf offset 25 | 41.8885 | | 41.8300 | | 41.8217 |
| bf offset 50 | 41.8936 | | 41.8364 | | 41.8353 |
| bf offset 75 | 41.9046 | | 41.8481 | | 41.8485 |
| bf offset 100 | 41.8666 | | 41.7618 | | 41.7480 |
| bf offset 125 | 41.8687 | | 41.7651 | | |
|---------------|---------|---------|---------|---------|---------|

[Koepi]

Closing this thread as a new build is out :)

Thanks for your testing, make sure to retest with the new build as well, it should give more impressing results.

Regards
Koepi