XviD-14022003-1

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