can vhq cause an increase in filesize?

[PerCIVaL]

I was just trying out different options of xvid to encode a 4 min. clip and compare them using 1-pass quality mode at 90%.

I must be breaking some kind of rule here, using 'vanilla' (i.e. no vhq) mode the filesize is 17022 KB.

When I set vhq mode 4, the filesize becomes 17040 KB.

I'm guessing vhq doesn't work in 1-pass, but it isn't mentioned in the vhq manual. If this is the case how is it possible that the filesize actually increased?

I'm using koepi's XviD-24062003-1 btw. And all other options are turned off.

[Koepi]

It can increase the filesize at fixed quant/quality - but the PSNR is seriously increased (means: the picture quality raises more than the file size).

In 2 pass scenarios this is better suitable, there you have your desired file size and "just" a PSNR increase.

Regards
Koepi

[sysKin]

Koepi is right, _but_ it should never happen. Maybe you're using old, buggy build? If not, give us full configuration - qpel setting in particular.

Radek

[PerCIVaL]

Syskin. I already mentioned the build in my post. As well as the fact that no other option was enabled.

You must've been in a hurry :D

-
ow, b-frames were enabled though. 2 150 75

[iago]

As far as I recall, Koepi's latest (2406) and uManiac's latest (2606) deliver different filesizes when the same vhq configuration is used. With one of them filesize increases, with the other it decreases parallel to the vhq level used, but I don't remember which one causes the increase and which one causes the decrease (I can't check it since I am not on my home pc atm).

Also, this might have been mentioned before (by yaz I guess) but -> with Koepi's build (I don't know if it's the same with uManiac's), when you wanna use vhq without b-frames you should set number of b-frames to "0" (new scd); with "-1" (old scd) you get keyframes only at the maximum keyframe intervals.

regards,
iago

[sysKin]

iago: can you confirm this? This should not happen, ever.
As for b-frame settings, you are right, but PerCIVaL used 2... so it's ok.

PerCIVaL: do you have a pentium 4? Also, (I just need to be certain), are you sure you haven't tried GMC with it.

If it's P4 problem again, I'll be really angry....

[PerCIVaL]

Syskin, yes it's a P4. GMC was off. I've doublechecked. In fact I'll check it again for you right now.

[PerCIVaL]

I did the comparison again. this time including the four different vhq modes.

these are the results:

vhq 0: 17022 KB
vhq 1: 17728 KB
vhq 2: 17490 KB
vhq 3: 17322 KB
vhq 4: 17040 KB

Odd behavior wouldn't you say? absolutely no other option was enabled. the settings were as follows:

Mode: 90% quality 1-pass
Motion search precision: 6
Quantizer: h.263
Min/Max KF interval: 1/250
B-frames: 2 150 75 0
B-VOP compatibility: ON

Furthermore, the debug dialog was set to automatically detect optimizations.

I'll try turning off sse2 and see if it makes a difference.
I tried vhq 4 again forcing sse2 optimization off. It made no difference.

[sysKin]

Not again ;_;

Yes, try without sse2 please ...

OT: Do you think P4 is evil and uses its unholy powers to pick on xvid?

[PerCIVaL]

nope, I turned off sse2 in the debug dialog but the problem still persists.

it's almost like as if just turning on vhq creates an overhead of some kind.

There's probably a really logical explanation to this, but I'm not sufficiently familiar with the inner workings of vhq to think of anything.

ideas?

[iago]

sysKin,

When I get home, I'll cross-check the two builds and try to provide some more detailed info.

But I have a couple of questions regarding the current status of vhq:

In a constant quant or one pass quality encode should vhq "normally" always "decrease" the filesize? And "normally" vhq4 should give a smaller filesize than vhq1, right?

If so, can it change depending on the source or depending on other features being enabled in addition to vhq?

iago

[JohnMK]

Let's be clear on this folks. There is no problem with the Pentium 4. There was however a problem in XviD programming when it comes to which functions to use on which instruction-set capable CPUs. I'm guessing sometimes when an advance in XviD was made, often times a P4-specific function might have been forgotten about and not updated like the generic functions (used by all other non-P4 CPUs). Much of this was fixed simply by castrating P4-specific functions and making P4's use generic functions. There simply aren't enough XviD programmers around with enough spare time to give us P4 users everything we may want. They'd rather program features than program performance, and I understand that trade-off.

The above is of course just an educated guess based upon what I've read here in the forums.

[iago]

Well, my memory has proven me wrong again. What I wrote in my first post regarding the two recent builds doesn't seem to be true. And the questions in my previous post have already been answered now ;).

Here are some short test results with Koepi's and uManiac's latest builds. 2000 frames the same source encoded with constant quant 2. B-frames = 0 (new scd) and all else default except vhq settings:

Koepi's 24062003-1 build:

vhq0 = 28982 kb
vhq1 = 28708 kb
vhq2 = 28310 kb
vhq3 = 28114 kb
vhq4 = 27958 kb
(31 keyframes in all clips)

uManiac's 26.06.2003.1100 build:

vhq0 = 28982 kb
vhq1 = 28440 kb
vhq2 = 28066 kb
vhq3 = 27900 kb
vhq4 = 27792 kb
(33 keyframes in all clips)

uManiac's latest build seems to be a bit more effective with vhq, despite two more keyframes! ;)

(Btw these results are from a non-P4 user with a poor celeron 900 ;))

regards,
iago

[RadicalEd]

I guess it's appropriate for the topic, recently I tested the two builds against each other and koepi's yeilded a higher psnr and lower size as far as I remember. Unfortunately, I can't find the files or my documented results anywhere ~_~

That was only with VHQ 4 though, and I'm on a tbird

[iago]

But here comes the interesting point. Same configuration as above -> B-frames = 0 (new scd) and all else default except vhq settings, and this time with MPEG quantization. Guess what! Both with Koepi's and uManiac's build, filesizes are even lower with MPEG quant than with h263! (I wonder if I should try once again with Andreas_78er matrix?!) ;)

The results:
------------

Koepi's 24062003-1 build:

vhq0 = 28564 kb
vhq1 = 28136 kb
vhq2 = 27746 kb
vhq3 = 27588 kb
vhq4 = 27422 kb


uManiac's 26.06.2003.1100 build:

vhq0 = 28578 kb
vhq1 = 28064 kb
vhq2 = 27680 kb
vhq3 = 27540 kb
vhq4 = 27388 kb


Well, these results are interesting for me, but the test is only a limited one. I really wonder if the results may be source/content specific (high-mo/low-mo, dark/light etc.) and how other parameters/options (b-frames, chroma motion, qpel) would effect this. But if it all goes like this, it means a taboo about h263 quant giving lower filesizes than MPEG is on the brink of collapsing - at least for me! :D

regards,
iago

[BoNz1]

iago, I saw this in the XviD mailing lists, http://list.xvid.org/pipermail/xvid-devel/2003-July/003209.html sysKin do you think the bug fix for BITS thinking that mpeg quant is used when h263 and vice versa is used is causing what iago's test has shown? I guess there is no way to tell (at least for me to tell) unless if we run another test with a new build, maybe I'll make an XviD build tonight and make some tests if I have some time and if I can get it to compile (I seem to have problems with the vfw and gmc lately). Anyhow regarding the P4 issues, I think we should get you XviD developers a really fast P4. I'm not suggesting you don't care about us P4 guys, but I think it would be a nice gesture for everything you guys have done plus it would benefit us too, :) :) :) Too bad I'm just a poor student. ;)

[Koepi]

Bonz,

sysKin was talking about dev-api-4. We're dealing with dev-api-3 here.

Koepi

[PerCIVaL]

Originally posted by iago

2000 frames the same source encoded with constant quant 2.

What I used was quality mode, not quantizer. I don't know to what quantizer 90%-quality averages out but could it be that there's something in the quality mode that causes the filesize increase?

Btw, no wonder there's still no v1.0 release. Who knows what other issues are hidden (if this is really an issue that is).

I'll try a a fixed quantizer to see if my results match iago's.

[PerCIVaL]

I tested again with b-frames -1 this time at fixed quantizer 5.

Vhq mode on still gives a larger filesize then when off. With filesizes decreasing with higher vhq levels (vhq off still has the smallest size).

now is this normal behavior or not? I'm completely baffled otherwise.

[sysKin]

Originally posted by PerCIVaL
now is this normal behavior or not? No it's not :/ The values iago posted would be concidered normal.

There is a bug I found today (thanks to you). I'm not sure, but it might be related. Can you please tell us what quant type are you using (mpeg/h263) and try again, with the other quant? If (and only if) you were using mpeg and h263 helps, I've solved the problem.

Radek

[PerCIVaL]

In the above tests I was using h.263.

I tried again using MPEG quantizer just now, and vhq mode 1 still had a larger filesize than with vhq off.

I haven't got a clue what's causing this. Could it be just an incident? It's just a music video shot off dvb-s from mtv.

I turned everything off except for vhq.