XviD-14022003-1

[Koepi]

Ahoy!

Good news everyone: sysKin played around again and hacked in some baaaad things ;)

Changelog:
- Activated experimental AC-HQ-PREDICTION by gruel.
- Added vfw support for sysKin's revised DCT ME (VHQ mode).
- Preliminary hack against dark blocks in bframes by sysKin.
Be warned: this is not a real fix! It might break things.

The warning is meant for real. It can seriously f*ck up your encode by adding new artefacts.

Still, please test!

Best regards
Koepi

[Mango Madness]

first reply!

Test: The Matrix
2 Pass encode
HQ Modulated
Mode 1 VHQ
Motion Search 6
Chroma, Lumi, and B-frame (3/150/100)
Using avisynth 2.5 beta with the latest virtualdubmod aiming for 650meg video plus a 150meg mp3 file (encoded with lame 3.94 alpha 11 vbr preset medium)

New toys are always appreciated.

[Koepi]

Please don't use modulated quantizers, they don't work correctly with bframes enabled. In that scenario i'd prefer H.263 quantizer matrix or even hvs_good_picture-matrix.
Mode 4 VHQ gives a better result in 2pass mode btw., the PSNR drop introduced is overcompensated by the filesize gain.

Regards
Koepi

[Sigmatador]

LOL a Saint Valentin's build :D

going to play with VHQ :cool:

thx ;)

[OUTPinged_]

the PSNR drop introduced is overcompensated by the filesize gain
err... what is "AC-HQ-PREDICTION"?


LOL a Saint Valentin's build
You noticed it too! Very, very suspicious. Gotta check the codec for hidden surprises..

[iago]

Yes, time to play with the new toy! Let's try to discover what the "AC-HQ-PREDICTION" is ;).

[Zarxrax]

Koepi, could you mind please explaining to us what those first 2 things do, the "experimental AC-HQ-PREDICTION" and the "vfw support for sysKin's revised DCT ME (VHQ mode)"?
Thanks :)

[Tommy Carrot]

AC-HQ prediction is linked to the keyframes (maybe all of the intra blocks?). Basicly the keyframes will be shorter about 1-2%.
(Don't hate me if i'm wrong. :D This is what i could understand from the dev-list)

[Koepi]

TommyCarrot's explanation is a bit simple, but mainly hits the point.

vfw-support for syskin's "dct ME" (old name, since it's all in CVS he changed it into bits ME as this is exactly what it does ;) ) is in CVS already and is another search refinement which reduces filesize by optimizing i.e. intra/inter macroblock decision based on the bits used and the higher VHQ modes (look into the VHQ manual thread) do another search to minimize the block size even more.

Regards
Koepi

[MaTTeR]

Originally posted by Koepi
Mode 4 VHQ gives a better result in 2pass mode btw., the PSNR drop introduced is overcompensated by the filesize gain. Has something changed? SysKin stated level 1 gives better quality and filesize overall. Maybe he was only speaking about the uManiac build?

[Koepi]

No. Mode1 improves 1pass quantizer/quality mode as well while modes 2-4 introduce a small drop in PSNR. In 2pass mode the filesize is so much less that with the additional space the PSNR after 2nd pass is higher than without those modes.

Regards
Koepi

[MaTTeR]

Cool..thx for explaining and the new build.

[Zarxrax]

This build just seems to crash vdubmod when I enable the VHQ. I tried VHQ level 1 and 4, and they both crashed, but it encodes fine when I disable the VHQ. I'm using h.263, motion search 6, and none of the extra options.

[Koepi]

Doesn't crash here and on other machines. What setup do you have? Did you push "load defaults" first?

Regards
Koepi

[csr2000]

I have the same crash,both on Koepi's and uManiacs' build.
OS is W2K Sp3
P4 2.4GA
Intel850
Samsung Rambus 800 512MB
WD 800JB * 2 @ Raid 0

Fisrt: load default, Crash
Second: Uninstall XviD,delet all reg key,reboot, reinstall XviD, the same Crash

I also heard someone suggest to disable sse2 in VDM,but always the same Crash.

Now I can only use XviD-02022003-1.exe

[Koepi]

Hum. P4 seems to be a freaky processor :-/

Anyhow... the good news:
Suxen_drol made chroma optimization an xvid-option via flags, so I added VfW support for it (see the debug-tab). Chroma optimization interpolates colour information in very bright or dark areas which helps stair effects on edges a bit.

XviD-15022003-1.exe (417kb)
Changelog:
- Fresh CVS checkout.
- Added vfw support for suxendrol's chroma optimizer.

Best regards
Koepi

[vinks]

both umaniac's and koepi's current build seems to have broken sse2 optimizations, both build crash on my p4 when sse2 is enabled. disabling it makes it all work :)

i guess its wait a few days till someone finds out whats broke and fixes it.

[csr2000]

please kindly tell how to disable SSE2?
in VDM,I disable SSE2 in options\perferance\cpu, but it seems not work

[Snakeisthestuff]

I have tested the 14022003 build on a short movie clip, which includes much movie-noise and where in later builds much dark blocks were produced by the use of b-frames.

my settings:
Motion search prec.: 6
quant type: h.263
VHQ mode: 4
use chroma motion, use gmc, use Qpel checked
max bframes: 2
b-frame quant ratio: 150
b-frame quant offset: 100
DX50 B-VOP comp. checked

results:
great! the dark blocks are gone, but like Koepi mentioned there are therefor some other artefacts :(

here a screenshot of some artefacts.

[Lefungus]

I also have a p4. If i want to use xvid, i must force cpu optimisations and disable sse2 instructions in xvid config box. The bug was here before (January) only if I got ref'divx lumimasking checked, but now it doesn't matter.

(Sorry for my poor english)

[zulu]

i just did a short clip and noticed artifacts in several scenes.
settings:
resoltion 512x272,
2 pass,
motion search 6,
quant type h.263,
vhq 1,
max I 250,
min i 1,
chroma motion,
qpel,
_no_ gmc,
b-frames 3,150,100
dx50 b-vop compatibility

screenshot attached.

[Sigmatador]

could you try the desativate each feature (one by one :cool: ) to find which one it is ? (only for this piece of video :D )

edit: what's your script and your xvid build ? ;)

[sysKin]

Originally posted by zulu
i just did a short clip and noticed artifacts in several scenes.
settings: Could you confirm that this is a b-frame? Use ffdshow's OSD. Well, I bet it is.

The warning at the very beginning, saying that this build can make such artifacts, was very real.

Radek

[csr2000]

Motion search prec.: 6
quant type: h.263
VHQ mode: 0
chroma motion on
gmc off
Qpel off
max bframes: 3
b-frame quant ratio: 100
b-frame quant offset: 200
DX50 B-VOP comp. checked

also can find the block like the picture show above

[OntzA]

It's because of bframes for sure. Yesterday I did some tests with and without bframes, and there always appear artifacts in bframes.
sysKin could you explain briefly why does VHQ fail with bframes?

[zulu]

Originally posted by sysKin
Could you confirm that this is a b-frame? Use ffdshow's OSD. Well, I bet it is.


you're right :D
ffdshow identifies this frame as "B QPEL".

[Koepi]

Erm. This isn't VHQ related. People, finally learn to read please.

That artefact derives from the hack which was meant to suppress dark blocks in bframes and VERY LOUD and CLEARLY got marked as HACK WHICH WILL PRODUCE ARTEFACTS.

_Nothing_ in conjunction with VHQ. Read me.

Regards
Koepi

[HarryM]

I found bug.

I use b-frames, q-pel. No WHQ (actually).
In b-frames are disordered blocks, mainly at high-speed, contrasted edges...
Koepi's build 02022003 is O.K., 14022003 and 15022003 are buggy.

I think, syskin's hotfix for darkblocks in b-frames is buggy possibly (see snap from xvid movie)...

[HarryM]

Ehhhh. Late. Zulu reported this bug too... :(

[angelyote]

I'm still getting the SSE2 crash in the 15022003 build. It's also in Umaniac's build and in the 14022003 build.

Same as with everyone else I can get rid of this by disabling SSE2 in the codec.

I know this has been reported already but I didn't see any response other than P4s being freaky processors.

@csr2000
In order to disable SSE2 you go into the debug panel of your xvid codec's advanced options and change 'automatically detect optimizations' to 'force optimizations' and uncheck SSE2.

Dave

[Koepi]

The SSE2 bug is known in the meantime. Unfortunately nobody has a real idea where it comes from.

Might be that noone of the developers owns a P4.

Koepi

[Lobuz]

It look's like this white pixels bug isn't in umaniac's 15.02.2003.0900 developer's version.

[BoNz1]

Alright, with all the talk about VHQ I have decided to do some testing myself. I am very impressed. The tests were done on the matrix reloaded trailer. The really cool thing about VHQ is that it is simple profile compatible which makes it very valuable. This is what I wanted to test, the reduction in bitrate using only simple profile features and VHQ. I used Koepi's 14022003-1 build. So here are my settings, everything I used was the same except for VHQ for each of the five times I did this, using res of 704x320:
Motion Search Precision 6
Quantization Type MPEG
Max I frame 300
Min I frame 1
DX50 B-VOP Compatibility
Now, here are the filesizes for the first pass the first one used VHQ 0, the second VHQ 1 and so on:
1. 33,019,904 bytes
2. 32,071,680 bytes
3. 31,381,504 bytes
4. 30,996,480 bytes
5. 30,767,104 bytes
Now, I really cannot see the difference between VHQ 0 and 4, I might use 4 for a 1-cd rip and 2 for a 2-cd rip since I get a substantial drop in fps. But as I was doing my testing I ran into something wierd. It has been reported here several times that there are problems with b-frames they get little blocks all over the place. Well, I didn't use b-frames or anything else for that matter and I still got this problem. When I did use b-frames, quarter pixel, chroma motion the problem was definitely worse though. I will attach some screen shots to show this. The first is from the source, the second is all advanced options disabled and VHQ 0, the third is with b-frames, quarter pixel, chroma motion, and VHQ 4. Hopefully, this will help to sort out this problem, I will test more if needed. I am also getting the problem with SSE2, disabling it everything works fine as reported earlier. Aghh, you can't attach much here. Oh well, I uploaded to a webpage so you can check it out here, http://www.geocities.com/bonzi5252/

[BoNz1]

Hmm, I was thinking about this again and I looked at my settings again. I could swear that I turned off b-frames but I think that I may not have. I am _very_ sorry if I caused any problems or misconceptions. If anything I guess it proves that 1/4 pixel seems to really amplify this problem as Keopi said before. Sorry again.

[Koepi]

XviD-17022003-1:
- Fresh CVS checkout.
- Better fix for dark blocks in bframes by sysKin.

It works perfectly for me now :)

Thanks for the code sysKin! :)

Best regards
Koepi

[sillKotscha]

thanks for your efforts but unfortunately it is not available...

but I can choose my meal (e.g. Halbes Grillhähnchen (3,4) an Paprikarahm, dazu Pommes frites und Broccoli, Dessert) by viewing the mensa menue of Studentenwerk Göttingen :D

[NuclearFusi0n]

We <3 you, Koepi.
You too, sysKin!

BTW, 404 on the new binary. You screwed the file name on the page link. ;)

EDIT by koepi:
DON'T spoof for downloading, I'll hit you with a foam bat(c)(r)[tm] ;)
/EDIT by koepi
EDIT BY FUSi0N: sorry man, i was too excited about the new build. like a child with a new toy! :D
question: since there are no ads on your homepage, how do you benefit from people visiting your page before downloading?




edit2: nevermind fixed, thanks koepi!!!

[Koepi]

OOpsi, sorry for the mess, i incidently hit "insert" button and thus deleted some characters which are vital ;)

Fixed!

And now guess what I'`m having for lunch today - i only have to walk 20 meters from here ;)

Best regards
Koepi

[NuclearFusi0n]

here goes testing

The Matrix
VHQ 4
QPEL
BFrames 3/150/100
MPEG quants
Chroma Motion
Rest on defaults


I'll update when it's done :)
currently have 9 hours remaining on pass 1, on my Athlon XP 2000+

[sillKotscha]

Originally posted by Koepi
And now guess what I'`m having for lunch today ;)

den Salatteller für eine Stamm2-Marke :D

/end of [german] chatting

[NuclearFusi0n]

Originally posted by sillKotscha
/end of [german] chatting
thankfully ;)


:p

[hayami]

Just tried the new build and the white artifact for bframe introduced in the last build is gone now. Thanks =D

[fraatz]

Hi Syskin & Koepi!
I just tested Koepis todays build and I still get dark blocks, the bright blocks are much more visible than with the original unmodified xvid code, too.
Anyway, thanks Syskin for looking into it!!!
fraatz

[Koepi]

You must be kidding, fraatz.

Please recheck your system, the build (17022003-1),...

I get no such problems anymore, really. I use my hardcore test which makes those blocks very easy visible, and it's more than fine now. The remaining "slightly darker blocks" which now pop up frmo time to time are dependant on the source.

Regards
Koepi

[Mgz]

Koepi, Would you like to put Xvid 0.9.1 offical on to your site. I really want to try it but I can't complie it :( (it said something about NMake,libxvidcore.mak,etc)


PLZ

[Koepi]

ß-9.1 isn't out yet. uManiac's scripts checkout the HEAD branch, not the appropiate 0.9.0 or 0.9.1 branch.

There's nothing stable yet, so i'll wait for that.

Regards
Koepi

[ookzDVD]

Just test Koepi's 17022003-1 build, with small clip.
VHQ=1 and ChromME enabled, B-Frame : 3/100/200.
The result is good as usual :)

[drebel]

Ok.Some more testing with Koepi's build (17022003-1) and syskin's VHQ
Results with 3 b frames 150/100,croma me,mpeg quant and 1st pass filesize :

-mode 0ff :9,08 mb
-mode 1 :8,78 mb
-mode 2 :8,63 mb
-mode 3 :8,56 mb
-mode 4 :8,46 mb
-mode 4+qpel:8,70 mb
-mode4+qpel+GMC:8,71 mb

and -mode 4 nob-frames,noqpel,nogmc : 12,1 mb

And some conclusions :

1. I couldnt find any of the "fast dark luma blocks" i mentioned the first time to syskin (nice job!!) ;)
2. I couldnt even see the "slightly darker blocks" that Koepi mentioned,even with 100 %zoom and full brightness.So,to my eyes,what i cannot see,doesn't exist :D
3. Each mode makes a filesize decrease with no jumps involved(mode1>mode2>mode3>mode4).So,is that a "hidden" bugfix? :confused:
4. The use of qpel increases filesize a bit (and decreases the effect of VHQ),but adds a lot to visual quality.So,it's really worth trying tha combination
5. Even though Syskin suggested not to use GMC with VHQ,the final avi was decodable with no probs at all.But the use of GMC didnt decrease the filesize any more.Visual quality was about the same
6. The use of b-frames helps a lot more to compressibility than VHQ alone.So, VHQ with NO b-frames is a waste of time and fps(my humble opinion ,sorry).But VHQ WITH b-brames adds a little something when it's really needed ...

Impressed by the innovations,
regards,
george

[Koepi]

VHQ doesn't work with GMC yet. You're lucky the encoding session didn't crash. :) But sysKin emphased that often enough for you to know this. ;)

Regards,
Koepi

[drebel]

Yea,i know...I was only playing around with the options . No crashes,however :)
And a question : does the stable build from umaniac (newest cvs ) has the same options as yours and working bugfree (as possible)?

[TheXung]

Originally posted by Koepi
The remaining "slightly darker blocks" which now pop up frmo time to time are dependant on the source.


Are you implying the "slightly darker blocks" is not a bug? They're less noticable than how it use to be but these slightly darker blocks have begun appearing in clips that didn't have them before VHQ. I hope they're related to the dark blocks bug such that when syskin applies a properly fix, it fixes both.

[Franko30]

Originally posted by Koepi
VHQ doesn't work with GMC yet. You're lucky the encoding session didn't crash. :) But sysKin emphased that often enough for you to know this. ;)



Hmmmm,

in the "VHQ Manual" thread I read about VHQ being not campatible with GMC yet.

Ignoring this warning (as it already is a few days old ;) ) I encoded several movies on two different WinXP/AMD machines and one Win98/Celeron machine without any crash and excellent visual results.

I used VirtualDub1.4.13, Koepi's XviD-17022003-1 with VHQ2, Chroma Motion, GMC, 2 B-Frames, and the new Chroma Optimization.

So - and please don't misunderstand this question - what exactly is the problem?

If it is a "might crash" problem, I guess everybody could live with a warning.

Or if it is a MPEG4-spec-compliance problem, why not just say it is?

All I've been reading so far about VHQ and GMC have been some vague warnings and no explanations.


If it really is forbidden to use VHQ with GMC, why not just disable the GMC checkbox when enabling VHQ instead of having dumb questions like mine?:confused:

Cheers

Franko30

[Koepi]

VHQ vs GMC:

if a frame is S_VOP (thus GMC gets used)VHQ _can't_ be used as there is no code added.
(or it's exactly vice versa, if VHQ is enabled the GMC routines don't get used...)

This can result in weird results or bad quality. Read exactly. CAN.

Why do you draw conclusions like mpeg4 compatibility broken? Did I write that anywhere? Or sysKin? No.

If it really is forbidden to use VHQ with GMC, why not just disable the GMC checkbox when enabling VHQ instead of having dumb questions like mine?

Well, if you ask me that way: i can't spend the hours it needs to code that. Maybe you want to pay me the hours? :p Honestly I find that question disrespectful.

Regards
Koepi

[Franko30]

Originally posted by Koepi

Why do you draw conclusions like mpeg4 compatibility broken? Did I write that anywhere? Or sysKin? No.

Well, if you ask me that way: i can't spend the hours it needs to code that. Maybe you want to pay me the hours? :p Honestly I find that question disrespectful.



Great! I did it! Finally, Koepi is mad at me, too. What an honour.

And I didn't draw conclusions - I just was guessing, as the insight you gave in your post wasn't available before.

Cheers

Franko30

[Koepi]

I'm not mad at anyone. :)

It's just that you throw in something which means a bit of work as if it is usual that someone does that - you can't demand things that way if people code that stuff in their rare spare time :)

Regards
Koepi

[Franko30]

Hi Koepi,

If the lines you wrote don't classify for "being mad at someone" then what does?

I guess one problem here is due to the fact that we all are not native speakers of the English language and so most of the expressions concerning our feelings are quite rude.

And another problem is, that every suggestion someone makes is misinterpreted by you as a "demand". I've been noticing this for quite some time now.

Just try to relax and "keep cool" - although I don't like the term "cool".

Nobody's trying to hurt or offend you - maybe it's just the language barrier of - in this case - two Germans chatting in English.

And concerning my "demand":

As I don't code (really, some people still don't do it) I didn't know that connecting two switches might be such a hassle... Sorry for that. Maybe you could post a sticky with "how many lines of code does a Koepi-Build contain" and "the main problems of dumb questions like those of Franko30" :D


Franko30

[sungey]

hmm...just finished playing around with xvid-17022003-1
testing the VHQ mode = 0 with bframe ( without gmc and qpel ),
chromaMe=ON and chroma optimization = ON

min KF =2 max KF = 240, default bframe settings

evrything seems good here ... very satisfying... except
theres a part where there's no KF for 10 minutes ... but i guess
that's an old issue ... :)

[unmei]

there seems to remain a crash problem with 17-02-2003 / VDmod and VHQ (tried mode 1 and 4) using a Pentium III (not 4) . only way to use it was load default alone - as soon as i changed some stuff in advanced it crashed on 1st frame of 1st pass (strange enough VDmod crashes, ususally it was the Xvid codec itself who used to break).

the system should be set up about properly (26-01-2003 never crashed), but i dint force/disable any optimizations, thus SSE is probably used.

i didnt enought testing too see what works and what not , but VHQ seems to impose some problems on P3 too, not only P4.

P3-600mhz / 512MB SDRam / XP pro / few background tasks (but IIS web server running)

[and dont tell me i should use a newer PC :) its testing only and a codec shouldn't be limited to latest CPUs after all.]

[sysKin]

OK just an answer about VHQ + GMC.
Yes, it will not crash. Yes, it won't cause artifacts. Yes, it will still look good.
When GMC is active, there is a comparsion made for each macroblock. The sum of absolute difference between motion-compensated macroblock and original is compared against a sum of absolute difference between GMC-ed macroblock and original. If GMC-ed macroblock seems to be better, GMC-ed macroblock is chosen. If not, we just use normal motion compensation.

When VHQ is active, we no longer store sum of absolute difference - we store number of bits needed to code the macroblock instead. When it comes to GMC decision, _ number of bits is compared against SAD _ which is completely wrong. Usually SAD is much higher and GMC is not used.

It's not ok, because the decision is stored as a single bit in every macroblock. This bit always says 'no' and is simply wasted, so you're just wasting bits (and time) when trying to use GMC and VHQ together.

Radek

[sungey]

just a suggestion for Koepi :)

i think it would be great if we can have Tooltips that tell
us which feature is mpeg4 compliant ( like GMC isnt , chroma ME is compliant ) because newer dev builds of xvid has many valuable features, and some users like me would like to make sure the encode is mpeg4 compliant especially when the encode will be distributed publicly. If its mpeg4 compliant, it can be safely played using Divx5 filter (while waiting for Xvid with bframe stable to come out :) ). Personally i like using DX50 fourcc for public encodes with bframe since its easily playable using ffdshow and Divx5 filter.

Just my 2 cents.

[NuclearFusi0n]

Originally posted by sungey
just a suggestion for Koepi :)

i think it would be great if we can have Tooltips that tell
us which feature is mpeg4 compliant ( like GMC isnt , chroma ME is compliant ) because newer dev builds of xvid has many valuable features, and some users like me would like to make sure the encode is mpeg4 compliant especially when the encode will be distributed publicly. If its mpeg4 compliant, it can be safely played using Divx5 filter (while waiting for Xvid with bframe stable to come out :) ). Personally i like using DX50 fourcc for public encodes with bframe since its easily playable using ffdshow and Divx5 filter.

Just my 2 cents.
if you want 100% mpeg4 compliance, use stable builds.
nuff said.
i hate to be so curt, but the issue has been brought up before. XviD will ALWAYS be MPEG4 compliant, but occasionally something is screwed up in a developer/unstable build. that's why it's called unstable. anything you do with it is done at your own risk.

[Lobuz]

I just made some different configuraton tests. The result is that chroma optimizer produce grup of block flickering in very dark areas. It can be seen clearly when will the gamma be set for example to 2.

tests with VDubMod, AVS 2.5, mpeg2dec3,
in avs crop, lanczosresize no filters

quantizer2
Chroma optimizer - flickering black and darkgrey groups of MB
+ vhq 1-4 - not flickering but not exackly black !!!
+ chroma motion + quoterpel + lumimasking + B-Frames
flickering black and darkgrey groups of MB

After disabling Chroma optimizer area is almost black

Beside chroma optimizer and GMC the rest is great especially VHQ.

Another thing after filtering with Convolution3d(preset="movieHQ")
video with b-frames is more fluent. Without it it just stoped in some places (5 I-frames at range?) and now plays fine.

Regards
Lobuz

[sungey]

Originally posted by NuclearFusi0n
if you want 100% mpeg4 compliance, use stable builds.
nuff said.
i hate to be so curt, but the issue has been brought up before. XviD will ALWAYS be MPEG4 compliant, but occasionally something is screwed up in a developer/unstable build. that's why it's called unstable. anything you do with it is done at your own risk.

Yeah, i know xvid stable is 100% mpeg4 compliant, its just
a good extra feature so uninformed users dont say "hey waht is this error, VHQ break mpeg4 compliance ?" or something like that ..
( im pretty sure u have seen many posts like that before ).

p/s : stable builds isnt enough for my work though =( .. need smaller file sizes ... thanks to bframe ^^

[Blight]

Is it just me or is the latest build has issues with VHQ and L-Mask? If either of these are enabled in any form, VirtualDub terminates (no error message, just closes itself).

I'm on a P4/WinXP clean machine.

[Assault]

@Blight

I think you have to deactivate sse2 optimization in Xvid. Then it should work. ;)

Regards
Assault

[ookzDVD]

@Forum

Anyone have tested the latest Koepi's 17022003-1 build with
the dark movie, ie. Panic Room, The Others, or etc. ?

[vinks]

yes i have tried it with "the ninth gate". and the result was ok for a 2hr film on 1cd at a 576xXXX res. the settings were 250kf, 1mkf, linear curve scaling, VHQ4, h.263 both passes, (no bframes). ran c3d(moviehq) and unfilter(-5,-5) as well. i did get some shimmering at certain places where there seemed to be over compression. but in general it was good in comparison to not using VHQ.

[hellgauss]

I have a bug while using uManiacs(21Feb) or Koepi(17Feb) builds (I didn't try Nic's one):
VDub/VDubmod crashes if i use BOTH B-frame and VHQ and if I use 'autodect cpu'. If i disable the SSE2 it's all OK.

I have a P4Mobile with 512Mb DDR and an NVIDIA GeForce4 440 Go with 32Mb. I use WindowsXP HomeEdition

HG

[Sigmatador]

xvid can't use SSE2 optimization, it's a known bug.

[Franko30]

Hi,

as there still is no thread for Koepi's XviD-17022003-1, I guess we just keep on using this one ;)

Alright, here's my problem:

Is ist possible, that the greyscale-mode is broken?

I'm using Koepi's XviD-17022003-1 on a black and white movie I recorded (see signature). As I didn't encode b/w movies since I switched to the new builds (after using Koepi's XviD-03122002-1 for quite some time), so I don't know if this is limited to the current build.

Here's what happened:

I encoded the movie in greyscale-mode using VHQ2, Lumi Masking (LM) and (thought I might try this) Chroma Optimization (CO) and Chroma Motion (CM) enabled, 2 B-Frames at 150/100.

The resulting movie showed slight "purple-noise", see picture links below, the lines of the circle, whereas the rest is greyscale. It is visible in clouds, too - not limited to motion areas. As you see, it is barely noticeable in a still picture, but very annoying in the movie, as the purplish areas move around a little.

After that I switched off CO and CM, to have only VHQ2 and LM in greyscale mode, B-Frames as above.

The "purple-noise" persisted.

Finally I encoded again (as in the other two examples: new first and second pass) switching off the greyscale mode, using VHQ2, CM, CO and LM, B-Frames as above.

The movie got back it's "colors" being a slight brownish tint now and then from the old film material - but the "purple-noise" is gone.

Does anybody have the possibility to try and reproduce this?

Here are the links:

http://www.schwarzwaldstuben-berlin.de/frank/b_w-mode.jpg

http://www.schwarzwaldstuben-berlin.de/frank/color-mode.jpg


Anyway - it doesn't matter too much, as the average quantizer in color-mode was 0.5 lower than in greyscale mode (without CM and CO).

Cheers

Franko30

[AndyP]

Hi

This might be a stupid question but can I confirm if Koepi's latest (17/2) build uses referencedix's new lumimasking code or not as it is not mentioned in the changelog (but then a changelog only refers to changes...... :confused: )??

Many Thanks,
Andy

[sillKotscha]

Originally posted by Franko30
Does anybody have the possibility to try and reproduce this?

yes, I noticed that as well but didn't spend to much heed on it... but now, as you mentioned that too, hmm.

these are the basic lines of my script:


Cnr2()
LumaFilter(-2,1)
tweak(cont=1.05)
Unfilter(5,5)


and my xvid_settings (as far as I can remember) ;) :

- 2pass
- vhq4
- LM/CM
- b-frames: 3/100/200
- chroma optimizer
- quants_default and rest as usual as well

I thought it was related to my script and didn't even thought about xvid...

but for now I only have these screenshots...

- http://www.sahnau.de/skotscha/slightly%20pink01.jpg (left site of the picture slightly pink_blurred)
- http://www.sahnau.de/skotscha/slightly%20pink02.jpg (obviously noticable)

unfortunately I've deleted my captured files - otherwise I could test if it's only xvid (I doubt that - we're the only ones who noticed that) or xvid in relation with on of the script lines...

we'll see

regards Sill

P.S.: Hi Hansen, "Schwarzwaldstuben" definitvly rock!! worth a go... for everyone :)

[sungey]

using 17022003

i made an encode with h263 quant, bframe default, CM, VHQ=1 ...
it seems like the wall is more "solid" (no swimming pixel) ?
My eyes could be playing tricks on me though ... is that something related to VHQ ?

[iago]

@sungey,

I guess Koepi has already mentioned several times that with VHQ you get a more solid looking background.

[kilg0r3]

is there a reliable qpel decoder by now?

[NuclearFusi0n]

Originally posted by kilg0r3
is there a reliable qpel decoder by now?
still waiting on the next ffdshow build :(

[cult]

I had mention it earlier when someone asked for settings for b&w movies.I used greyscale() from avisynth because the option in xvid was giving the same results.It was a time that there was no vhq and didnt use lumimasking

[MoonWalker]

Recenlty I did an encode and ended up with 2050360 bytes overflow!!!

00269243 24246.52650379 [2024] 2nd-pass: quant:31 MPEG bframe stats1:8 scaled:8 actual:8 overflow:2050360 credits
00269244 24246.54626887 [2024] 2nd-pass: quant:31 MPEG bframe stats1:8 scaled:8 actual:8 overflow:2050360 credits

I used 4/150/100 B-frames , vhq 4, MPEG quant the rest at defaults using XviD-17022003.

MoonWalker

[sillKotscha]

Originally posted by sillKotscha

and my xvid_settings (as far as I can remember) ;) :

- 2pass
- vhq4
- LM/CM
- b-frames: 3/100/200
- chroma optimizer
- quants_default and rest as usual as well


sorry for diggin' out this issue again :rolleyes:

I guess, I know what caused this "purple-noise" Franko30 and me were talking about...

in this thread [http://forum.doom9.org/showthread.php?s=&postid=271671#post271671] sysKin is questioning the use of CM and chroma optimizer together

Originally posted by sysKin

Originally posted by Dark-Cracker
- automaticly enable Chroma Optimiser when u select chroma motion in Xvid.

Any reson for this? They don't work together, the only thing which they have in common is that they have something to do with chroma (ie color). That's it.

Radek


well, regarding his answer guess what I have done wrong ;)

cheers Sill

[sysKin]

I have nothing against using them together - optimizer does its job (preprocessing), CM does its (in motion estimation).

They might work together or not, they are independant. Therefore putting them under one checkbox is just weird - just like that ;)

Radek

[sillKotscha]

Originally posted by sysKin
They might work together or not, they are independant. Therefore putting them under one checkbox is just weird - just like that ;)

Radek

thanks Radek,

weird is the right term of use - weird as my results :D

with kind regards

Sill

Edit//

my [quote] concerning your proposal was the first time I've read about the weirdness of using them together - did you mentioned that before? If yes, it would be kind of you if you could point me to your (?) post... and maybe than I'm also able to find an answer for myself when it does make sense of using one of them.

Thank you Sir

[Koepi]

Well, since CM and CO are independant, the use of both together _should_ have no problems. They must come from something else. Maybe CO itself isn't working correctly all the time, it's highly experimental and thus in the debug-tab - at least that was my reason to place it there.

Regards
Koepi

[sillKotscha]

Originally posted by Koepi
it's highly experimental and thus in the debug-tab

well, talking about experimental behaviour... that's the way you guys developed this great codec. ;)

as I said before, wouldn't Franko30 pointed me to his observation I really didn't thought about xvid could have caused this issue in first place... most of the time it is the misuse of the codec and false avisynth_script settings.

Who am I, that I could blame you guys about wrong development - I thought it was stupid me not able to use your gift in the right way...

regards Sill

[vinkes]

He everybody,

The first thing I wanted to say is that the latest xvid-builds are great, thanks to all the xvid-developers.

I did some extensive testing with koepi's latest xvid dev-build (18-2). To test extra compressibility I did some test using vhq.
For these tests I used the movie "Path to war". I encoded the first 10.000 frames using the different vhq-modes.

As you would expect, vhq-mode 4 (wide search) gave the best compressibility (7% better than vhq-mode 0). So I used this mode to encode the movie. After I was finished encoding, I encoded the movie again using vhq-mode 0.

After this encode was finished, I did a compressibility check in Gknot. And now comes the strange thing: the encode using vhq 0 had a 3% better compression than the encode using vhq-mode 4.

After looking at both encodes, I would conclude that the movie encoded with vhq-mode 4 looked better. But I thought that vhq would always give extra compressibility? Or am I mistaken?

O BTW: I used virtualdubmod 1.4.13, avisynth 2.5beta

Regards

[BoNz1]

Well, vhq reduces the bitrate in the first pass so in the second pass you will use lower quants than if you were not using vhq. This may be why you are seeing this, or I may be completely wrong.

[kilg0r3]

hi everybody,

i am trying to compile a known-bugs list for the latest koepi build. her follows what i could find. please feel free to comment:

- possible smearing artefacts with vhq 2-4 (together with qpel only?)
- vhq + gmc does not work = waste of time and bits
- chroma optimization seems to be unstable - macro block flicker
- greyscale mode seems to be broken (pinkish hue)
- sse2 optimization does not work, makes machine crash
- max iframe interval not taken into account
- iframe quant ranges are being ignored with bframes [edited]

[sam_b]

I frame quant ranges being ignored with B-frames?

[cult]

Too bad about the greyscale bug because I have to use the function in avinsynth.About the vhq havent mentioned any smearing but with qpel yes.Would you enlighten us about the chroma optimizer bug as its not mention by anyone?

[kilg0r3]

@cult

lobuz' post on page 4 of this thread seems to mention some unstable behavior.

[cult]

thx kilg0r3.I had missed it.