VAQ: Making Xvid's Adaptive Quantization Not Suck

[Dark Shikari]

I was bored, so I spent 15 minutes and wrote this patch to port x264's new VAQ to Xvid.

I haven't tested it much (only on this video (http://mirror05.x264.nl/Dark/force.php?file=./Touhou_Short.mp4)), but it seems to work surprisingly well, despite MPEG-4 ASP's drastic limitations on quantizer deltas.

Patch (http://pastebin.com/f1718874b) [updated with minor fixes]

Xvidcore.dll (http://mirror05.x264.nl/Dark/force.php?file=./xvidcore.dll) [updated with latest patch]

To use it with Virtualdub or any VfW interface, just overwrite the XvidCore.dll in your /Windows/System32 or similar with the one I have provided.

To activate VAQ, just check off the Adaptive Quantization box; it replaces the normal luminance masking.

Note that I could not get it working correctly with mencoder; for some reason libavcodec seems to have its own lumimasking library that's overriding my patch. It works with xvid_encraw and VfW though...

Have fun!

[squid_80]

If people want, I can add it to my xvid_encraw as a new option. Unfortunately I have no time to do my own tests at the moment.

[Dark Shikari]

If people want, I can add it to my xvid_encraw as a new option. Unfortunately I have no time to do my own tests at the moment.In the patch's current form it overwrites lumimasking, so one would need a separate version (it uses the same commandline as lumimasking).

[Zep]

I was bored, so I spent 15 minutes and wrote this patch to port x264's new VAQ to Xvid.

I haven't tested it much (only on this video (http://mirror05.x264.nl/Dark/force.php?file=./Touhou_Short.mp4)), but it seems to work surprisingly well, despite MPEG-4 ASP's drastic limitations on quantizer deltas.



can you link to the without patch encode for comparison? :)

[elguaxo]

:thanks:

[Dark Shikari]

can you link to the without patch encode for comparison? :)That is the x264 version of the video :p

Do Xvid test encodes yourself.

[Ranguvar]

Awesome!

But I SO wish you had done this before I backed up a bunch of stuff to Xvid :p

Squid_80, please do. I will test if I get any time, which is most likely as I have this week off.

Dark Shikari, can this Xvidcore be used against any version of the Xvid codec? I have a recent build of 1.2.-127.

[Dark Shikari]

Awesome!

But I SO wish you had done this before I backed up a bunch of stuff to Xvid :p

Squid_80, please do. I will test if I get any time, which is most likely as I have this week off.

Dark Shikari, can this Xvidcore be used against any version of the Xvid codec? I have a recent build of 1.2.-127.This is the latest CVS snapshot of Xvid + my patch.

[squid_80]

In the patch's current form it overwrites lumimasking, so one would need a separate version (it uses the same commandline as lumimasking).

The beauty of the xvid's plugin system - I can add however many plugins I want to encraw and xvidcore.dll doesn't need to be updated.

[G_M_C]

I was bored, so I spent 15 minutes and wrote this patch to port x264's new VAQ to Xvid[...]

OMG

I'd allmost wish you'd be bored more often.

.... But on the other hand ...

If you do things like these VAQ-patches for X264 & Xvid while bored ... i'd hate to think of things you could do while really interested :eek:

:p

Anyway,just a question; Could this same patch / idea be ported to Hank's HCEnc MPEG2 encoder ? I use that one quite often to make (author) DVD's.

I use Hanks luminance-adative code, wich works surprisingly well. But that code works only on "darker" scenes, not on flat(ter) scenes like the VAQ does. I would be really interested in such a feature :)

[Dark Shikari]

Anyway,just a question; Could this same patch / idea be ported to Hank's HCEnc MPEG2 encoder ? I use that one quite often to make (author) DVD's. I don't see why not... :p

All I need is a link to the source.
If you do things like these VAQ-patches for X264 & Xvid while bored ... i'd hate to think of things you could do while really interested :eek:Well x264's took quite a while--but once I had it working I can easily port it to any other similar encoder with very little work.

[hank315]

I'm already working on it for some time, the general idea is about the same, variance based.
Will be in the next HCenc release.

Just had a look at the implementation in Xvid, well, I'm a C n00b but when I do something like this in Fortran it will overflow on high luminance values:

for (k = 0; k < 16; k++)
for (l = 0; l < 16; l++)
{
int val = ptr[k*data->current.stride[0] + l];
sum += val;
sum_of_squares += val * val;
}

/* Variance = SSD - SAD^2 / (numpixels) */
int variance = sum_of_squares - sum * sum / 256;

[elguaxo]

Edit: I accidentally left a debug statement in there, so if you're using xvid_encraw... well... you might notice "THISISATEST" constantly printing ;)

I'm using xvid_encraw. I have no idea how to compile this myself. Could you or somone else post a binary without the debug text? Thanks in advance!

[TheRyuu]

I think that patch isn't really proper (at least it didn't work for me).
After some slight editing of it though I managed to get it to work (with a fuzz with the last hunk, but I checked the luminance_masking.c and everything was patched correctly)

Now off to test. I think the patch doesn't have that debug line Dark was talking about so I'll post a build in a bit I guess and see if that helps (it's only a debug line though so does it really matter?)

Edit:
Build:
http://www.fileducky.com/qRILYtae/

It's built with pthreads enabled.

[Dark Shikari]

I think that patch isn't really proper (at least it didn't work for me).
After some slight editing of it though I managed to get it to work (with a fuzz with the last hunk, but I checked the luminance_masking.c and everything was patched correctly)

Now off to test. I think the patch doesn't have that debug line Dark was talking about so I'll post a build in a bit I guess and see if that helps (it's only a debug line though so does it really matter?)Yes, I removed the debug line in the patch so that people didn't accidentally include it :p Only my build has it.

[Dark Shikari]

I'm already working on it for some time, the general idea is about the same, variance based.
Will be in the next HCenc release.

Just had a look at the implementation in Xvid, well, I'm a C n00b but when I do something like this in Fortran it will overflow on high luminance values:

for (k = 0; k < 16; k++)
for (l = 0; l < 16; l++)
{
int val = ptr[k*data->current.stride[0] + l];
sum += val;
sum_of_squares += val * val;
}

/* Variance = SSD - SAD^2 / (numpixels) */
int variance = sum_of_squares - sum * sum / 256;The maximum value that sum_of_squares can reach is (255 * 255 * 256), or a bit under 2^24, so it is not a problem.

The maximum value that sum can reach is 255*256... so yes, you are right; sum*sum could overflow a signed integer.

The correction would be to make sum and ssd unsigned integers.

[squid_80]

If the product is going to be divided by 256, why not bitshift before the multiply?

[Dark Shikari]

If the product is going to be divided by 256, why not bitshift before the multiply?Rounding error. Same problem occurred in x264; that was the fix between 0.46 and 0.47.

[squid_80]

Divide by 256, with rounding:
(x+128)>>8

No good?

[Dark Shikari]

Divide by 256, rounding upwards:
(x+128)>>8

No good?It won't give the same result as multiplying before shifting, IIRC.

Patch updated with unsigned fix.

[Brother John]

This is fantastic news! Thx for that patch, Dark Shikari. Now, there’s no chance you might get super-bored and port CRF to Xvid? :p

I did some tests with wizboy11’s binary and short clips (10000 frames) from five PAL DVDs.

-cq 2 -qmatrix "Heini MR.xcm" -bquant_ratio 100 -bquant_offset 100 -qpel -bvhq -zones 0,w,1,O
-lumimasking added for VAQ encodings.

File sizes (in Matroska container)
| size (KByte) | Diff. | Diff. by frame type (%)
sample | VAQ off | VAQ on | % | I | P | B
-----------+---------+--------+-------+-------+-------+--------
1 dialogue | 100958 | 87338 | -13.4 | -11.3 | -23.0 | +7.5
-----------+---------+--------+-------+-------+-------+--------
2 night | 186572 | 169400 | -9.2 | -8.6 | -14.2 | +2.7
-----------+---------+--------+-------+-------+-------+--------
3 CG | 180319 | 156962 | -13.0 | -9.5 | -19.9 | +5.1
-----------+---------+--------+-------+-------+-------+--------
4 action | 246899 | 218558 | -11.5 | -8.1 | -16.3 | +2.0
-----------+---------+--------+-------+-------+-------+--------
5 noisy | 460090 | 403804 | -12.2 | -10.9 | -18.6 | +2.9

Not much to say about visual quality. There’s hardly ever any significant difference between VAQ clips non-VAQ ones. And then only when comparing still frames. So ~10% smaller files without quality or speed drop. I think I might like that. ;)

[Dark Shikari]

This is fantastic news! Thx for that patch, Dark Shikari. Now, there’s no chance you might get super-bored and port CRF to Xvid? :pCRF wouldn't work in Xvid except at high quantizers; if your video is mostly QP2, the only thing you can do is drop a frame to QP1 (waste of bits) or raise it to QP3; not much leeway. H.264's logarithmic quantizer gives one vastly more room to do such a thing.

Xvid has really really nasty restrictions on quantizers. From what I recall:

1. A "DQuant" block is a block that has a different quantizer from the previous block. In the case of VAQ, this would be an edge block, for example.

2. DQuant blocks cannot have a difference of more than +/- QP from the frame QP (I think).

3. DQuant blocks cannot use 4mv. (WTF? Why?)

4. DQuant blocks cannot use GMC. (WTF? Why?)

5. B-frames have even weirder restrictions on quantizers.

6. The quantizer scale as a whole is crap. It has less quantizer resolution at high qualities, and high quantizer resolution at low qualities (i.e. the difference between 1 and 2 and 3 is much bigger than the difference between 25 and 26 and 27). The only real reason other than simplicity to lower quantizer resolution is to save bits when encoding QP_deltas... but this means you spend more bits on QP_deltas at lower bitrates, where it actually matters, but fewer bits at higher bitrates, where it hardly matters at all. How senseless.

[Inventive Software]

Holy s**t Dark Shikari! This is great news. :D

And are those weird restrictions you refer to specific to Xvid, or do they exist in MPEG-4 ASP as a spec?

[Dark Shikari]

Holy s**t Dark Shikari! This is great news. :D

And are those weird restrictions you refer to specific to Xvid, or do they exist in MPEG-4 ASP as a spec?ASP :mad:

[Inventive Software]

That's a shame. No wonder you like to program for AVC so much! :p

[Didée]

Regarding (2) - AFAIR for DQUANT blocks, QP may not differ more than +/-2 from the previously coded block. So theoretically the full quant range from 1 to 31 can be used in a frame, just the difference between "adjacent" blocks is limited. Dunno, perhaps it's a restriction to make implementations of HW decoders easier? Could also be the reason for not allowing 4mv for DQUANTS, but again dunno.
GMC is "WTF" anyway - major effort, minor gain. There must be a reason GMC isn't in the spec's for AVC ...

[Dark Shikari]

There must be a reason GMC isn't in the spec's for AVC ...Because the vast majority of the gain of GMC can be simulated simply by using better MV prediction, basically.

[Ranguvar]

Yeah, even in animes where there's lots of panning+zooming, I see very little benefit with GMC. And it breaks many, many standalones and portables. Same thing with QPel. Not enough benefit to break the chance that I will use the video on one of those later on.

[Prettz]

Holy s**t Dark Shikari! This is great news. :D

And are those weird restrictions you refer to specific to Xvid, or do they exist in MPEG-4 ASP as a spec?
ASP I don't think was ever intended for the kind of high-quality videos Xvid initially allowed to be produced. And because of that, the ASP standard fought against the Xvid devs every step of the way towards increasing its quality. When you take a step back and look at the situation, it's not surprising that Xvid development hit an extremely flat plateau many years ago. It's not the Xvid developers' faults.

In the grand scheme of things, Advanced Simple Profile was a very transitory standard, and the current state of hardware has actually made ASP's initial purpose totally irrelevant, while the standard at the same time severely constrains any further development. Practically since 2004 there hasn't been anywhere to go except H.264.


GMC is "WTF" anyway - major effort, minor gain. There must be a reason GMC isn't in the spec's for AVC ...
Basically put, the MPEG-4 group learned from the early experimentation in ASP that GMC was a great idea that, unexpectedly, totally failed to produce results in practice. Didee, I know you were around during the earliest Xvid days to see this proved before your own eyes.

Yeah, even in animes where there's lots of panning+zooming, I see very little benefit with GMC. And it breaks many, many standalones and portables. Same thing with QPel. Not enough benefit to break the chance that I will use the video on one of those later on.
I can't believe there are still standalone players that can't handle either GMC or QPel. Especially considering how little potential ASP has without QPel. Who are these people who own such incredibly old DVD players yet haven't thrown them in the trash yet?

[kypec]

If people want, I can add it to my xvid_encraw as a new option. Unfortunately I have no time to do my own tests at the moment.

Yes, I'd really appreciate that xvid_encraw version with separate VAQ option. The current state where it overrides lumimasking option is not a good solution IMHO. One could easily forget about it and be VERY confused with outcoming encodes later :mad:

[Brother John]

@Dark Shikari
I see. So VAQ basically is about as close to CRF as Xvid can get. Those bad quant restrictions indeed are one of the reason why I’d like to abandon Xvid. There are more important ones making me stay, though. And VAQ is definitely one more of those.

Same thing with QPel. Not enough benefit
QPel usually doesn’t even improve compression but lowers it! However it makes the picture look a bit grittier. It’s a kind of pseudo-detail and if you like the effect, QPel is a good thing.

ASP I don't think was ever intended for the kind of high-quality videos Xvid initially allowed to be produced.
When reading the MPEG-4 Visual specs I get the impression that MPEG was more concerned with the whole non-rectangle video/compositing thing than plain old movie encoding. Maybe the restrictions make more sense from that point of view.

[Ranguvar]

I can't believe there are still standalone players that can't handle either GMC or QPel. Especially considering how little potential ASP has without QPel. Who are these people who own such incredibly old DVD players yet haven't thrown them in the trash yet?
Sweetest little portable on the market :p
http://www.archos.com/products/gen_5/archos_605wifi/tech_specs.html?country=global&lang=en

QPel usually doesn’t even improve compression but lowers it! However it makes the picture look a bit grittier. It’s a kind of pseudo-detail and if you like the effect, QPel is a good thing.
Yep, to my eyes, not enough benefit to make up for lost compressibility.

[Ranguvar]

tested with VDub 1.7.8. The new AQ shaves 9MB off a formerly 54MB video. CQ 4, little over 3mins. This is Gears of War footage.

I couldn't tell a difference playing at full speed. Frame-by-frame, no AQ was better overall, but only very slightly. Some frames it actually seemed to help.

One thing I did notice was in the beginning, I had some text that was in a special font. It was a deep red, with small black holes in the letters. Just interesting.

No AQ:
http://img337.imageshack.us/img337/1057/aqch7.png (http://imageshack.us)


AQ:
http://img297.imageshack.us/img297/7836/aqen0.png (http://imageshack.us)



It's a lot easier to see a difference flipping between them :p

[Dark Shikari]

...
Note that AQ is *designed* to decrease quality on sharp edges, such as text like that, so you can clearly see the difference there.

The idea is that generally such sharp edges and complex text takes such a large amount of bits that the bits are probably better used elsewhere.

As you can tell, AQ lowers quality slightly at the same QP, but of course can improve quality if you try to keep to the same bitrate.

[laserfan]

I'm sorry, I'm having some trouble understanding the benefit of VAQ and wonder if someone can explain it in layman's terms?

My usage of Xvid these days is mostly HDTV profile w/single pass target 2.00 quantizer and I don't care about filesize--will I see a benefit anyway to VAQ? Or is text the only place one should see a difference? :confused:

[Dark Shikari]

I'm sorry, I'm having some trouble understanding the benefit of VAQ and wonder if someone can explain it in layman's terms?

My usage of Xvid these days is mostly HDTV profile w/single pass target 2.00 quantizer and I don't care about filesize--will I see a benefit anyway to VAQ? Or is text the only place one should see a difference? :confused:It raises quantizer in the highest detail areas, where you won't notice it, and lowers quantizer in the flatter areas, where blocking/blurring often occur.

Text is an extreme example of the former.

[Ranguvar]

NVM :p

[salehin]

What a great addition. I'll definitely give it a go. Thanks a lot, DarkShikari :D

(Apart from our eyes ofc,) similar to x264 encode (SSIM, Avg QP, etc), are there any numbers that should look which would tell us something about the xvid quality?

[Dark Shikari]

I suppose I should have looked before I posted--the "with VAQ" encoding I made looked considerably "washed-out" compared to the non-AQ one. Or maybe I should say the non-AQ had more contrast (and less visible detail). I'll have to look later using my player and big screen--not sure my monitor is the best judge of this. So I don't know yet which I like better...

The attachments should at least give you a sense of it (lowered the res and output as jpg).Use Tinypic/similar for images so we don't have to wait for attachments.

And save as full-size PNGs.

[laserfan]

Dark, I somehow managed to get the videos OPPOSITE from what they actually were!!!???!! Man, dunno how I did that--the non-AQ video is the washed-out one; the VAQ has better contrast. I will edit my other post, sorry...

[laserfan]

OK here are the images again; this first is using VAQ:

http://i29.tinypic.com/yj535.jpg

The next one is w/AQ unchecked; it looks washed-out. Sorry for getting this wrong the first time!

http://i31.tinypic.com/wl3y28.png

I will report again later after I've had a chance to look at these on my media player/10' wide screen!

[Dark Shikari]

That's because you opened both at once in two separate media players, but since only one could use the overlay renderer, the other didn't get the proper TV->PC brightness level conversions.

It has absolutely nothing to do with Xvid or AQ.

[laserfan]

Oh my; that would never have occurred to me. I haven't looked at the vids outside of Media Player Classic yet, but I have no doubt you are correct about this, because indeed, in order to make certain I selected the same frame for comparison/screenshot, I opened two incidences of MPC! :o

Sorry for the bandwidth!

:veryembarrassed:

I guess at least I can take some solace re: how my original post was "wrong"--I simply opened in a different sequence each time.

[20-40]

check off the Adaptive Quantization box
I feel stupid, because I cannot see any changes neither in file sizes or quality.
Because I've never grasped concept of some people's ON and OFF, be so kind and tell me what "check off" in your sentence means. Marked box or not? You know... is it yes... or not...
UN-checked or checked as un-marked and - marked.
Have fun!
Later, for sure.

Thanks in advance.
:eek:

[Brother John]

For VfW: Enable “Adaptive Quantization”
For Encraw: Add -lumimasking to CLI

[20-40]

So... in this case OFF means ON - as YES, as "marked", as checked.
Thanks brother, it's nice to see that off means yes.
OK, "radio" box of “Adaptive Quantization” stays enabled, as always.
Encraw will chew later on.

"Saying: Go to this people, and say to them: With the ear you shall hear, and shall not understand; and seeing you shall see, and shall not perceive." :stupid:

[Ranguvar]

Cool saying :p

[Sharktooth]

already heard that saying... it's religion related...
however, i think VAQ can be more effective with quantization matrices like 6of9 and similar purpouse matrices...

[20-40]

Maybe it is, Sharky, I've added this saying as absolutely relevant to my previous post - namely - and if you can pass personal "connotations" in it - it IS about UNDERSTANDING and PERCEPTION, two most valid things in this matter.
Next time, look without filtering, it was uncalled for, sayings as this one have been part of our civilization log before we were born. So respected man and Doom's forum member, as you are, don't need someone as me to tell you that.

[Gromozeka]

dark Shikari you is hero!
Thank you very much/ i'm testing your VAQ - its perfect
XviD forever! You can continue this proekt?

[Dark Shikari]

dark Shikari you is hero!
Thank you very much/ i'm testing your VAQ - its perfect
XviD forever! You can continue this proekt?Well I don't care much about Xvid, so... perhaps if someone else feels like looking at it, or advising me on a bit more about Xvid's internals with regards to dquant ;)

[Ranguvar]

The only possible way of improving VAQ, at least IMHO, would be to implement a sort of rough detection of text, so advanced subtitles could look better. Probably some weighting that if the possible text is near the bottom of the video, it is more likely to be text.

To me, especially with stylized anime subtitles, clean subs are very important.

Minor, and will most likely be shot down, but I'll throw it out there just in case. :thanks:

[Dark Shikari]

The only possible way of improving VAQ, at least IMHO, would be to implement a sort of rough detection of text, so advanced subtitles could look better. Probably some weighting that if the possible text is near the bottom of the video, it is more likely to be text.

To me, especially with stylized anime subtitles, clean subs are very important.

Minor, and will most likely be shot down, but I'll throw it out there just in case. :thanks:I have an improvement of VAQ in the works... it may improve ringing on edges while keeping most of the benefit now :cool:

Of course, if you want clean subs, just use softsubs, seriously :)

[Gromozeka]

Dark shikari
Speak that will be new AQ - 2.0? :)
It's true?
But XviD will be have AQ 2.0?

[plugh]

Xvid has really really nasty restrictions on quantizers. From what I recall:

1. A "DQuant" block is a block that has a different quantizer from the previous block. In the case of VAQ, this would be an edge block, for example.

2. DQuant blocks cannot have a difference of more than +/- QP from the frame QP (I think).

3. DQuant blocks cannot use 4mv. (WTF? Why?)

4. DQuant blocks cannot use GMC. (WTF? Why?)
Over in the HVS plugin thread, similar comments were made about AQDisadvantages

needs bitrate (2 bits per block)

limits modes for motion estimation

the quantizers of neighbouring blocks may only differ by two

works not woth B-frames
Is there a definitive reference on the above?

Point three in particular, since 4MV is on by default for basically all the profiles. Which takes precedence? Is a block coded with MODE_INTER4V precluded from dquant? Or does dquant force interv4 off?

I scanned through the code looking for both elements 'together', and find stuff like:
encoder.c/MBSetDquant
if (next->mode != MODE_INTER4V && next->mode != MODE_NOT_CODED)
/* mode allows dquant change in the future */
if (abs(next->quant - prev->quant) <= 2) {
/* quant change is not out of range */
estimation_pvop.c/ModeDecision_SAD and SearchP
estimation_rd_based.c/xvid_me_ModeDecision_RD
int inter4v = (VopFlags & XVID_VOP_INTER4V) && (pMB->dquant == 0);
It sort of looks like AQ inhibits 4MV - on sort of a block by block basis? (excluding b-frames of course, which AQ doesn't apply to?)

[Dark Shikari]

It sort of looks like AQ inhibits 4MV - on sort of a block by block basis? (excluding b-frames of course, which AQ doesn't apply to?)Yes, since a dquant block cannot have 4MV.

[Ranguvar]

I have an improvement of VAQ in the works... it may improve ringing on edges while keeping most of the benefit now :cool:

Of course, if you want clean subs, just use softsubs, seriously :)
Awesome! As for the softsubs comment, pretty much the only reason I use Xvid nowadays is for hardware players... and those tend not to have soft-sub support. When I do make backups of stuff for PC viewing, it's x264 MKV with ASS softsubs :)

[plugh]

a bit of a tangent, but did anything ever come of this?

New lumimasking code from ReferenceDivX (http://list.xvid.org/pipermail/xvid-devel/2002-November/001359.html)

[ToS_Maverick]

out of interest: are you able in MPEG4 ASP to change the quant. matrix on a frame/gop basis like in MPEG2?

if so, you could lower the matrix in cricital areas with VAQ.

[squid_80]

Technically no but it is possible with avi and the xvid decoder (not sure about divx) will handle it ok.

[Sharktooth]

not spec compliant.

[kypec]

@squid_80: any plans on updating xvid_encraw so that there'll be new separate CLI option switch for VAQ instead of lumimasking one?

[Sharktooth]

you cant have VAQ and lumimaksing togheter... and lumimasking sux... so why you need a "separate" option?

[plugh]

Sort of prompted by this thread, I've been pondering lumi-masking, and experimenting via the HVS plugin (http://forum.doom9.org/showthread.php?t=114811&page=6).

In the process, I came across something that makes me question the basic approach of the various implimentations, which is to act on the basis of (ie as a function of) the 'Y' component. 'Y', the luma component, is generally thought of as the gray scale part of an image, where large values for Y are brighter than small values.

But a simple experiment I did the other days makes me wonder. I was looking at scenes where xvid seems to produce blocky results (darker colored areas) on my TV and adjusted the TV settings to turn color off.

Now my thinking was that doing this would allow me to 'see' the luma component. Further, my thinking was that this would simply remove the coloration from the image, leaving me with just the (I'm grasping for words) lumimance / intensity / brightness / part of the image.

And finally, my thinking was that the above two sentences say the same thing. When I turned the color off it became immediately apparent that they are NOT.

One case that comes to mind was a segment from the movie Event Horizon, showing the ship in the clouds of Neptune's blue-tinted light. This was a darkish scene, everything shades of blue, the clouds of varying brightness - until I turned the color off.

Doing so made a large portion of the (blocky) clouds basically disappear. Huh? I said.

I tried similar experiements with other scenes - primarily blueish and redish images showing blockiness - and the results were quite consistant. Turning the color off made these areas largely black, rather that some low intensity gray as I expected.

This led to another experiment which was simply to watch some xvid encodes with TV color turned off vs on. What I observed was that nearly all the blockiness, moving walls, contours, etc, in my encodes vanished when the color was suppressed.

These observations triggerred a slew of thought processes, among them:

-The 'gray scale' 'Y' luma component does not strictly relate to the perceived brightness of a color TV picture. As such, using the 'Y' value as the basis for Adaptive Quant may be missing the boat.

-My efforts to combat 'blockiness' in my xvid encodes needs to focus on the chroma components rather than the luma...

Comments?

FYI - I'm toying with the idea of using the 'L' value from the HSL colorspace (http://en.wikipedia.org/wiki/HSL_color_space) rather than 'Y' for AQ decision making...

Comments?

[kypec]

you can't have VAQ and lumimasking together... Well, I didn't know that before, therefore I was asking for distinguishing these two options.
and lumimasking sux... so why you need a "separate" option? OK, now I see there's no need for "separate" option. Just would be nice if VAQ method was invoked through -vaq switch so as not be confused in the future when editing my scripts. Anyway, good comments can always help with such problem :p

[kypec]

Build:
http://www.fileducky.com/qRILYtae/

It's built with pthreads enabled.
Does that mean your build enables SMP (multithreaded) encoding?
If yes could you please upload it somewhere else? :thanks:
The link doesn't work for me at all.:mad:

[Ranguvar]

kypec, get a recent multithreaded build from the Multithreaded Xvid thread (a few pages back). Then copy the xvidcore.dll in the very first post in this thread to overwrite your old one. (Typically: C:\WINDOWS\system32\)

[kypec]

The most recent MT build I found is this archive xvid.cvs.head.MTK.2007.07.25.7z which contains 4 files:
xvid.ax 81 920 bytes 03.11.2006
xvidcore.dll 1 559 040 bytes 25.07.2007
xvidvfw.dll 282 624 bytes 10.03.2007
xvid.inf 2 963 bytes 30.05.2004

I've downloaded also the VAQ patch from the very first post in this thread xvidcore.dll 750 400 bytes. Why is there such huge difference in file size when only small routine (though I'm not an xvid expert, just average programmer guy) was replaced? That 750 kB DLL file seems more like an ordinary single threaded build but I might be wrong. I'll try it and see for myself.

[Dark Shikari]

The most recent MT build I found is this archive xvid.cvs.head.MTK.2007.07.25.7z which contains 4 files:
xvid.ax 81 920 bytes 03.11.2006
xvidcore.dll 1 559 040 bytes 25.07.2007
xvidvfw.dll 282 624 bytes 10.03.2007
xvid.inf 2 963 bytes 30.05.2004

I've downloaded also the VAQ patch from the very first post in this thread xvidcore.dll 750 400 bytes. Why is there such huge difference in file size when only small routine (though I'm not an xvid expert, just average programmer guy) was replaced? That 750 kB DLL file seems more like an ordinary single threaded build but I might be wrong. I'll try it and see for myself.It might have been compiled with different compiler settings.

[Ranguvar]

The most recent MT build I found is this archive xvid.cvs.head.MTK.2007.07.25.7z which contains 4 files:
xvid.ax 81 920 bytes 03.11.2006
xvidcore.dll 1 559 040 bytes 25.07.2007
xvidvfw.dll 282 624 bytes 10.03.2007
xvid.inf 2 963 bytes 30.05.2004

I've downloaded also the VAQ patch from the very first post in this thread xvidcore.dll 750 400 bytes. Why is there such huge difference in file size when only small routine (though I'm not an xvid expert, just average programmer guy) was replaced? That 750 kB DLL file seems more like an ordinary single threaded build but I might be wrong. I'll try it and see for myself.
February 9th, 2008 build: http://rapidshare.com/files/90468184/XviD_1.2.127-09022008.exe

[TheRyuu]

It might have been compiled with different compiler settings.

IIRC, it was compiled with the profiles or something which makes file size jump up. I also believe it was compiled with ICL9/10 although I'm not sure on that.

And thus the MTK in the file name. I forget what it means, but it's the reason for the huge file.

[TheRyuu]

Here's the latest xvid source-code with the latest VAQ patch.
Built with p-thread support so it's SMP enabled.

Xvid_20080401_VAQ.rar (http://www.fileducky.com/rMYjzbFW/)

[Gromozeka]

Here's the latest xvid source-code with the latest VAQ patch.
Built with p-thread support so it's SMP enabled.

Xvid_20080401_VAQ.rar (http://www.fileducky.com/rMYjzbFW/)

But what differences from Jawor's build? :)
Xvid 1.2.-127, Jawor's build with DivX profiles and VAQ (28.02.2008)
http://jawormat.republika.pl/xvid.html

[olnima]

Here's the latest xvid source-code with the latest VAQ patch.
Built with p-thread support so it's SMP enabled.

Xvid_20080401_VAQ.rar (http://www.fileducky.com/rMYjzbFW/)

Hi wizboy,
there seems to be something borked in your latest xvid-version. After installing it, it doesn't show off in virtualdub. Your version posted in this thread from 22nd feb. (http://www.fileducky.com/qRILYtae/) does.

Olnima

[LeXXuz]

Hi wizboy,
there seems to be something borked in your latest xvid-version. After installing it, it doesn't show off in virtualdub. Your version posted in this thread from 22nd feb. (http://www.fileducky.com/qRILYtae/) does.

Olnima

Jep and it cant be used with encraw either.

[kypec]

February 9th, 2008 build: http://rapidshare.com/files/90468184/XviD_1.2.127-09022008.exe
Did YOU build it (compiled the sources) personally? If not then why you just don't post the original URL link to file instead? :confused:

[Ranguvar]

I did not build it, and that is the URL that was given.

I use that build, with the VAQ xvidcore.dll, myself. Until I start compiling my own Xvid when my RAM gets shipped back.

[G_M_C]

But what differences from Jawor's build? :)
Xvid 1.2.-127, Jawor's build with DivX profiles and VAQ (28.02.2008)
http://jawormat.republika.pl/xvid.html

Was finaly able to update my Xvid. One question though: Do i ENable or DISable "adaptive quantization" in the options screen to make use of Dark Shikari's VAQ ?

(some earlier post suggested DISableing, others mentioned ENabling .. i'm confused ::confused: )

[Dark Shikari]

Was finaly able to update my Xvid. One question though: Do i ENable or DISable "adaptive quantization" in the options screen to make use of Dark Shikari's VAQ ?

(some earlier post suggested DISableing, others mentioned ENabling .. i'm confused ::confused: )Enable...

[TheRyuu]

Crap, I broke that build :(
Don't use it. :p

[celtic_druid]

xvid.cvs.head.MTK.2007.07.25

That would be my compile and it would have been ICL10, either that or 9. This is the reason for the large filesize. Basically the only change to the core was to allow for the disabling of N-VOP's. The MTK profiles and alt 2-pass are part of the VfW dll only. Replacing the core, you would lose some speed maybe (depending on CPU and alt compiler) and you wouldn't be able to disable N-VOP's (bad for ESS based SAP's as I recall).

As for various newer builds. There were zero changes to the CVS since my last build other than some nasm 0.99.x compatibility changes (talking CVS here, not patches). Even those are six months or so old.

Compiling a newer build without the code updating, makes no difference, well other than compiler improvements in the meantime. Still might update my builds with the VAQ patch.

[Inventive Software]

I used to do my own GCC compiles of Xvid a while back (cos at the time I didn't completely trust Koepi's builds), when they actually released the sources. I haven't done any of 1.2, cos there's nothing final, but speed was good, and it compiled, and if there's demand, I'll do one of 1.2. Size varied, but it wasn't UPX'd and defaults were used. VFW of course obligatory.

Will need to install and update MinGW to 3.4.6 though. 4 tends to be a lil slower, and less stable! :D

[Sharktooth]

3.4.x is faster than 4.x series, except 4.4 that seems to be the fastest one but unstable.

[olnima]

...and if there's demand...


...demand here ... :thanks:

Olnima

[Koepi]

Well, I finally found some time to create a build with the VAQ-patch as well. Find it at my Homepage (http://www.koepi.info).

Thanks Dark Shikari for the code!

I had to move some variable declarations around (to the beginning of the function blocks / loops) so the intel compiler won't abort with errors, but I'm quite positive that I didn't break anything.

I didn't test if the code works though. The installer does work at least ;-)

Cheers
Koepi

[plugh]

I had to move some variable declarations around (to the beginning of the function blocks / loops) so the intel compiler won't abort with errors, but I'm quite positive that I didn't break anything.
I had similar problems with MSVC6, plus no 'logf'...

FYI...

[Dark Shikari]

I had similar problems with MSVC6, plus no 'logf'...

FYI... ..... > --- a/common/osdep.h
> +++ b/common/osdep.h
> @@ -31,6 +31,17 @@
> #include <inttypes.h>
> #endif
>
> +//fixes logf bug in MSVC's math.h
> +//see http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98751
> +//note this will only work if math.h is included after osdep.h
> +#ifdef _MSC_VER
> +#if !defined (_M_IA64) && !defined (_M_AMD64)
> +#undef logf
> +#define logf(x) ((float)log((double)(x)))
> +#endif // !defined (_M_IA64) && !defined (_M_AMD64)
> +#endif

According to that url, not only is it a bug in msvc, it was fixed 2 years ago. So I won't accept a workaround.

[Ranguvar]

Well, I finally found some time to create a build with the VAQ-patch as well. Find it at my Homepage (http://www.koepi.info).

Thanks Dark Shikari for the code!

I had to move some variable declarations around (to the beginning of the function blocks / loops) so the intel compiler won't abort with errors, but I'm quite positive that I didn't break anything.

I didn't test if the code works though. The installer does work at least ;-)

Cheers
Koepi
Thanks, Koepi!

...and now, because when recieving a gift, it is proper to ask for more...

1.2.x SMP build with VAQ? Pretty please? xD :p

[plugh]

.....
Well spotted, and Nice to know. Thanks.

I just used 'log' (as the macro would have anyway).

I was a bit concerned about the 'statements before declaration' type errors, until I convinced myself it wasn't a bad patch application on my part. A bit of reordering and VC6 was happy...

[Dark Shikari]

I was a bit concerned about the 'statements before declaration' type errors, until I convinced myself it wasn't a bad patch application on my part. A bit of reordering and VC6 was happy...I'm lazy in that regard. I love throw statements before declarations, since gcc doesn't complain :p

[Koepi]

...and now, because when recieving a gift, it is proper to ask for more...

1.2.x SMP build with VAQ? Pretty please? xD :p

Thy wish is me command ;-)

Find Xvid-1.2-127-VAQ over at my website (http://www.koepi.info/).

Cheers
Koepi

[olnima]

Thanks koepi !!!

Olnima

[elguaxo]

thanks!

[Ranguvar]

Awesome, thanks Koepi! :D

Something about that Koepi Xvid feel, like it's the "true Xvid" xD :p :rolleyes:

What's the date of the source, please?

[Dark Shikari]

You know, if people are actually using this, I might want to go back and see if I can make it work any better for Xvid's quants :p

One thought is a the following: A CQM full of intentionally low values in order to make Xvid's QP8 equivalent to QP2 (in order to increase the quantizer resolution for moving quants up/down). This would require adjusting Xvid's internal lambda in order to compensate.

[Sharktooth]

EQM V3UHR or 6of9...

[Dark Shikari]

EQM V3UHR or 6of9...You'd still have to adjust the internal lambdas or else you're just going to waste bits.

[Gromozeka]

This would require adjusting Xvid's internal lambda in order to compensate.

It probably to realize?

[plugh]

The 1.2 series give the plg_frame routine access to lamda via
XVID_REQLAMBDA /* plugin requires access to the lambda table */

I debated whether to 'announce' this, but what the hell...

I've been working on some enhancements to the HVS plugin (http://forum.doom9.org/showthread.php?p=998742#post998742) (which I'm not ready to release yet), mostly some new variables and operators to work with and a couple bug fixes. (In case noone remembers, an earlier version of this code is in both squid_80's encraw and the xvidvfw I posted).

For example, on the AQ side, not only can you supply an eqn for the old lumi-masking (or variations), but now it will also allow expressing an equation for the new VAQ (or variations), or other approaches people might want to try. You can also do things based upon position (eg center vs sides) and some rudimentary support for zones (eg main movie vs end credits)

And, as the 1.2 version of that plugin also supports supplying equations to manipulate lamda, well *I* think it's a great tool for experimenting...

Stay tuned...

[ToS_Maverick]

any news on this?

this sounds extremely intriguing!

[IgorC]

I just encoded a few samples with a VAQ and compared it to Xvid's AQ and NO AQ. For me native Xvid's AQ has more detail but also more artefacts (on monotone structures like walls) then NO AQ. VAQ is optimal. It has less artefacts and has more details then both.

Dark Shikari, great work.
Do you plan to implement your alpha VAQ 2.0 to Xvid?

[Dark Shikari]

Dark Shikari, great work.
Do you plan to implement your alpha VAQ 2.0 to Xvid?It'd probably be far more beneficial to tweak the current VAQ than to port the alpha. It is really not optimal for Xvid's odd quantizer system.

[raeltheimperialaerosolkid]

My main purpose is to encode anime in a format that can be read by common stand alone players. Xvid always made a great job on it. I use the "home" profile for encoding. My favourite method is to set a constant quantizer (usually 3 for better results) and encode in a single pass. I don't care about size. AQ often (but not always) gives a great improvment in terms of quality so I'm REALLY interested in this VAQ patch.

Now the question: Is VAQ going to cause problems or incompatiblity with SAPs and/or if it will ever be released in a official Xvid release (i.e. 1.1.4 just to say one)?

I know that the better codec for anime encoding is AVC but, until it will not be widely suppported by SAPs, I will stay with the good old Xvid.

Thanks for the great work (and the answers)!

[Ranguvar]

VAQ cannot cause SAP or decoder problems. Like motion search level, VHQ, trellis, and AQ.

[NanoBot]

Hi,

from time to time I am using meGUI to encode some XviDs and now I would like to give VAQ a try. As far as I understand meGUI, I would need a new ( and hopefully also smp enabled ) version of xivd_encraw to do that. I saw that squid_80 earlier in this thread offered to build such a version of xvid_encraw. Therefore I would like to ask if there already is a VAQ enabled binary of xvid_encraw ( and I only could not find it ) or if I have to be patient and have to wait for it ?

Thanks in advance

C.U. NanoBot

[squid_80]

VAQ cannot cause SAP or decoder problems. Like motion search level, VHQ, trellis, and AQ.

Uh, yes it can. AQ adds a new element to the bitstream which the player must be able to handle.

[Ranguvar]

Oh, really? Thanks, did not know that.

In any case though, all (or all acceptable) decoders are capable of playing AQ/VAQ-using videos, right?

[Sharktooth]

Uh, yes it can. AQ adds a new element to the bitstream which the player must be able to handle.
not, properly. the old AQ added the same element...
so if it was working with the old AQ it will work with the new VAQ.

[squid_80]

Yeah, I was pointing out that AQ (using dquants) doesn't quite fit with motion search, VHQ and trellis. I don't know if there are any SAPs that fail to handle dquants, it's fairly trivial to implement in a decoder.

NanoBot: If you want to use new VAQ with MeGUI just replace xvidcore.dll with one from this thread that includes it. If I get around to adding it to xvid_encraw it will use a new command line parameter since I don't want to break anything that relies on the old behaviour.

[NanoBot]

Hi squid_80,

I really missed it, as in the first post it was said that replacing the xvidcore.dll by the newer one will also do the job with xvid_encraw.

And in fact, I already had the newer VAQ enabled xvidcore.dll on my PC, since I installed the VAQ enabled build from koepi a few days ago. The only thing I had to do was to copy it from ../system32 into ../tools/xvid_encraw.

:thanks: for your help !


C.U. NanoBot

[Sharktooth]

Squid: it's not necessary to add a new CLI parameter. Old lumimasking sucked badly and you cant use both AQ and VAQ... :)

[henryho_hk]

VAQ deserves a better name than "-lumimasking". ^_^

[Dark Shikari]

VAQ deserves a better name than "-lumimasking". ^_^Especially since that's a somewhat misleading name ;)

Complexity masking would be the technically correct term.

[Sharktooth]

i mean... -lumimasking could be renamed to -aq or something similar.
there's no need to "add" a new one...

[rseiler]

Could someone explain to me what the SMP version of xvid is? Would it only be appropriate for systems with multiple CPUs (or dual core) or does it have some other meaning? Thanks.

[Koepi]

That SMP-build is mostly useful with multiple cores/cpus in a system. It has some (minor) improvements on trellis quantization compared to Xvid-1.1.0. I think those improvements made it into later Xvid-builds like 1.1.3.

Cheers
Koepi

[NanoBot]

Hi Koepi, hi everybody,

Thy wish is me command ;-)
Find Xvid-1.2-127-VAQ over at my website (http://www.koepi.info/).
Cheers
Koepi

Koepi, I am using your smp and vaq enabled build of the xvidcore.dll ( thanks for that ! ), but I noticed that your build does not contain the xvid_plugin_ssim.

Is there any special reason why you left out ssim, perhabs because it is incompatible with smp and vaq, or perhabs because you think that the metrics determinded by the ssim plugin are to unreliable ?

If there ist no special reason, could you please compile a smp and vaq enabled build of the xvidcore.dll containing the ssim plugin ?

Thanks in advance, NanoBot

[[P]ako]

Thank you both, Dark Shikari and Koepi. I just tested it on animation and I can say I am quite pleased with the results. Later, I will tested it on a movie like "Dune" or "Blade Runner".

BTW, I still like XviD better than x264 to encode movies with.

[Koepi]

[...] but I noticed that your build does not contain the xvid_plugin_ssim.

Is there any special reason why you left out ssim, perhabs because it is incompatible with smp and vaq, or perhabs because you think that the metrics determinded by the ssim plugin are to unreliable ?


Could you please point me to a thread where plugin_ssim is introduced? I think i didn't hear of that yet as I didn't follow the development too closely the past 2 1/2 years. I'd happily add it if it is useful and doesn't break MPEG-ASP-compatibility.

Cheers
Koepi

[NanoBot]

Hi Koepi,

first thanks for your reply.

I am not able to find a thread here in the forum about the ssim plugin, and I only know about it because the version of the xvidcore.dll which came with meGUI contains it. But the build included with meGUI is not vaq enabled.

But I was able to find a pointer to that plugin in the xvid cvs:

http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/src/plugins/plugin_ssim.c?view=log

I think this plugin might be usefull to get at least a first impression about the impact on the quality of using different quant factors, matrices and of course vaq when encoding test clips with Xvid. Of course the best method to find my personal "optimal" settings should be using my eyeballs.

C.U. NanoBot

[Sharktooth]

I can include the xvid.dll with VAQ in the megui auto-update. what do you think? is xvid VAQ ok for "production" ?

[elguaxo]

I think it's ready.

[Koepi]

Ah, ok, now I understand what that ssim-plugin is about. Well, If you download the original source archives e.g. from xvid.org, you'll see that the plugin is missing in there too. I wonder why it is in CVS and not in the 1.1.3-branch....

That explains why it is missing in my builds. It's officially not there.

Cheers
Koepi

[TL0]

I think it's ready.

I agree, I have used it for 2 backups with megui, no problems detected.

[PatchWorKs]

I was bored, so I spent 15 minutes and wrote this patch to port x264's new VAQ to Xvid.
Just a question: it's just applicable to MPEG-4 or can be ported to other codecs too ? (I've Dirac/Theora in mind, but could be interesting for MPEG-2/1 too...)

[Dark Shikari]

Just a question: it's just applicable to MPEG-4 or can be ported to other codecs too ? (I've Dirac/Theora in mind, but could be interesting for MPEG-2/1 too...)Any codec with the concept of a delta quant can use it; its in a sense a relatively simple complexity mask.

[akupenguin]

... which disqualifies Dirac and Theora.
There's nothing inherently incompatible about delta quant and wavelets, but Dirac chose to allow delta quant only per subband, not spatially.
Theora allows delta quant, but with only 3 different quants per frame.

[henryho_hk]

Still waiting for the new AQ option in xvid_encraw. ^_^

[Ranguvar]

Still waiting for the new AQ option in xvid_encraw. ^_^

It's rather pointless, since AQ and VAQ can't be used at the same time :)
Either place the patched xvidcore.dll in the xvid_encraw directory, or you can delete any currently existing xvidcore.dll in there and then put the new one in (typically) C:\WINDOWS\System32\

[TheRyuu]

http://www.fileducky.com/NMjYIHRW/

That is a generic xvid build built with the latest svn source code unlike Koepi's which uses an older version.

It is built with pthreads and the vaq patch. Your processor must support mmx or higher in order to run it.

The last build I posted didn't work, this one should work without any problems. :)

[Adub]

Exactly were is the xvid svn source? I am running linux and I want to compile it from scratch and all I can find is the cvs repository on the Xvid.org page.

[TheRyuu]

Exactly were is the xvid svn source? I am running linux and I want to compile it from scratch and all I can find is the cvs repository on the Xvid.org page.

I just used the daily snapshot.

[Adub]

Is that really the latest? 1.2 and all that?
When ever I do "--version" on the configure, it says 1.1.0-.....

[TheRyuu]

Is that really the latest? 1.2 and all that?
When ever I do "--version" on the configure, it says 1.1.0-.....

It wouldn't have multi-threading if it really was 1.1.0

[looney]

The most recent MT build I found is this archive xvid.cvs.head.MTK.2007.07.25.7z which contains 4 files:
xvid.ax 81 920 bytes 03.11.2006
xvidcore.dll 1 559 040 bytes 25.07.2007
xvidvfw.dll 282 624 bytes 10.03.2007
xvid.inf 2 963 bytes 30.05.2004

I've downloaded also the VAQ patch from the very first post in this thread xvidcore.dll 750 400 bytes. Why is there such huge difference in file size when only small routine (though I'm not an xvid expert, just average programmer guy) was replaced? That 750 kB DLL file seems more like an ordinary single threaded build but I might be wrong. I'll try it and see for myself.

i think thats why celtic druid always upx his releases. so if the size is concern for you can alway try to upx (http://upx.sourceforge.net/)it yourself

[Sharktooth]

xvid with VAQ has just been added to megui.

[Irakli]

xvid with VAQ has just been added to megui.

:thanks:

[Avenger007]

Why are people still using an ancient encoder like Xvid? :confused:
For example, it has taken so long to get Xvid with VAQ into "production" (meGUI update) BUT x264 with VAQ was committed to GIT months ago (Sun Mar 30 17:58:41 2008 r804).
Now, there is a new psycho-visual patch in the works for x264: ** Psy RDO ** (http://forum.doom9.org/showthread.php?t=138293). How long do you think it will take for Xvid with Psy RDO to go into production, if ever? :rolleyes:

P.S. Sorry for spamming but I just have to speak my mind when I see people sticking (almost religiously) to old technology and refusing to change when something better exists and is easily accessible. :cool:

[Dark Shikari]

Why are people still using an ancient encoder like Xvid? :confused:
For example, it has taken so long to get Xvid with VAQ into "production" (meGUI update) BUT x264 with VAQ was committed to GIT months ago (Sun Mar 30 17:58:41 2008 r804).
Now, there is a new psycho-visual patch in the works for x264: ** Psy RDO ** (http://forum.doom9.org/showthread.php?t=138293). How long do you think it will take for Xvid with Psy RDO to go into production, if ever? :rolleyes:

P.S. Sorry for spamming but I just have to speak my mind when I see people sticking (almost religiously) to old technology and refusing to change when something better exists and is easily accessible. :cool:Psy RDO is probably not as useful for Xvid (much like VAQ wasn't as useful) as it is for x264, but for different reasons.

In particular, one of the main problems with H.264 in general is that intra prediction is very RD-optimal, but visually often results in a smooth, blurred block. Intra prediction is extremely effective for coding actual new information in the image, giving H.264 a huge advantage over other standards like VC-1, MPEG-4 ASP, etc. But often the RD-optimality of intra prediction results in blurred details when intra is chosen over inter when visually, it shouldn't be.

Xvid, with no spatial intra prediction at all, doesn't have this problem. Rather, it has a different (and unavoidable) problem: due to the lack of inloop deblocking, the overweighting of inter blocks relative to intra results in "trailing" and "smudging" in the background, and fake detail (often far stronger and sharper than the original) being created through blocks stacked upon each other.

As such, Xvid can't really benefit much from psy RDO (since inter is already naturally biased much more in favor of than it is in H.264).

[Ranguvar]

Why are people still using an ancient encoder like Xvid? :confused:
For example, it has taken so long to get Xvid with VAQ into "production" (meGUI update) BUT x264 with VAQ was committed to GIT months ago (Sun Mar 30 17:58:41 2008 r804).
Now, there is a new psycho-visual patch in the works for x264: ** Psy RDO ** (http://forum.doom9.org/showthread.php?t=138293). How long do you think it will take for Xvid with Psy RDO to go into production, if ever? :rolleyes:

P.S. Sorry for spamming but I just have to speak my mind when I see people sticking (almost religiously) to old technology and refusing to change when something better exists and is easily accessible. :cool:
Because there is still a use for MPEG-4 ASP.

My Archos 605, for example. Sweet player, cost me a few hundred bucks. Does MPEG-4 ASP, the AVC support is extremely limited. Or the other players like that out there. Or the fact that Xvid is nice for uploading to sites like YouTube. Or the fact that MPEG-4 ASP behaves much nicer on older computers, and many people already have the tools to play it, making it good for sharing home videos with friends and family.

You could go on and on.

MPEG-4 ASP is not obsolete, it's simply in a different usage category now. I do use AVC, I just find times when ASP will do a better job for whatever reason.

And regarding the patch, even Dark Shikari does not work 24/7 :p

I hope MPEG-4 ASP work continues for a good long time, and more power to those that continue to improve said encoders.

[Avenger007]

@Dark Shikari:
Thanks for the info. :) Even though intra prediction visually often results in a smooth, blurred block, like you said it is very RD-optimal and is extremely effective for coding actual new information in the image, giving H.264 a huge advantage over other standards like VC-1, MPEG-4 ASP, etc. Thus, all the more reason for people to let go of Xvid (since there is only so much benefit you can get by porting patches) and start using x264.

I would prefer to have an encoder encoding images as close to the original as possible and use filters to cleanup and add detail than to have the encoder adding fake detail while blocking and smudging the background to boot.

I guess a future improvement for x264 is to have a better algorithm (perhaps based on more metrics) for choosing inter over intra prediction when appropriate (assuming the problem isn't "etched" into H.264).

@Ranguvar:
The use you speak of for MPEG-4 ASP is one of compatibility since MPEG-4 AVC is the modern successor of MPEG-4 ASP. That's exactly what I meant when I said "sticking (almost religiously) to old technology". If you want to be on the cutting-edge and benefit from all that the latest technology has to offer then sometimes compatibility has to be sacrificed, but only if the improvements are significant and the choice to do so is economical.

I think x264 meets those requirements; it meets H.264 specs, it's free and is easily accessible. Besides, Blu-ray players support H.264/AVC and ffdshow also supports H.264. So when you think about it, compatibility really isn't an issue; people are just too lazy to change on their own and will only do so when they are compelled to change to by some external force (just like Newton's law of inertia :)).

Having said all of that, compatibility is still a factor so there will still be the need to use ASP. However, I would still try hard to use AVC if I could and use ASP only in exceptional cases (unless you goal isn't quality :p).

[Ranguvar]

I use AVC whenever I have a choice :)

But the fact is that sometimes the job at hand calls for ASP. At the moment, only with ASP can I have a solution with 5.1 audio that plays easily on my portable, TV (through Xbox 360 or XBMC), and ancient laptop I'm using right now...

I'm not sticking religiously, and I don't think that maintaining Xvid is a bad thing, or that most people still using Xvid are sticking religiously. The majority of them just don't want to upgrade their equipment, I'd say.

[LeXXuz]

P.S. Sorry for spamming but I just have to speak my mind when I see people sticking (almost religiously) to old technology and refusing to change when something better exists and is easily accessible. :cool:

Please send me 600 bucks so I can upgrade all my hardware to use AVC. Then I won't have to stick so religiously with this old technology! Wire transfer or cheque would be nice. THANK YOU SO MUCH in advance! :devil:

[laserfan]

Please send me 600 bucks so I can upgrade all my hardware to use AVC. Then I won't have to stick so religiously with this old technology! Wire transfer or cheque would be nice. THANK YOU SO MUCH in advance! :devil:Avenger007 if you are so anxious to get everyone off Xvid, put your money where your mouth is. I'm with LeXXuz, though I'd need about a grand to upgrade my stuff! :p

[Ranguvar]

And if you could please pay off Archos, Sony, Microsoft, the former to upgrade my Archos with a better H.264 decoder so I can watch reasonable level AVC clips on it, and I want Sony and Microsoft to decode Matroska videos with AC3 audio :P

[Avenger007]

If you want to be on the cutting-edge and benefit from all that the latest technology has to offer then sometimes compatibility has to be sacrificed, but only if the improvements are significant and the choice to do so is economical.
Xvid FTW! :stupid::p

[henryho_hk]

XviD has its own strength over AVC in certain areas. Both are bad when used in the wrong way. e.g. our local TV programs have just been switching to HD (h.264) and now the ppls are looking like dolls and the leaves are looking like plastic flips.

[Dark Shikari]

XviD has its own strength over AVC in certain areas. Both are bad when used in the wrong way. e.g. our local TV programs have just been switching to HD (h.264) and now the ppls are looking like dolls and the leaves are looking like plastic flips.That's mainly because they cut the bitrate when making the switch--often far too much (IMO).

It's also because the encoders they use are often absolutely terrible; while x264 often retains detail much better than Xvid, the same can't be said of most other AVC encoders.

[kandrey89]

I thought VAQ was supposed to increase quality not decrease it?!

I'm comparing samples right now and I see that VAQ does the following:
increase DRF Average
smooths out the video
introduces abbrasions on flat surfaces (such as widely differential pixels on a flat piece of cloth)
bigger end file by 3.75%

End result, worse

[Dark Shikari]

I'm comparing samples right now and I see that VAQ does the following:
increase DRF AverageDRF is not a measure of quality.
smooths out the videoThat's exactly the opposite of what VAQ does--unless you mean that it reduces blocking.
introduces abbrasions on flat surfaces (such as widely differential pixels on a flat piece of cloth)Yes, its called retaining detail. As an Xvid user, perhaps you've never seen such detail before? ;) :)

[kandrey89]

I did find places where VAQ smoothed out the edges.
I just now found some blockiness removal

with VAQ and Without
Yes I do see the difference now, just that sometimes it looks like the quality in the edges is lost :/
http://i29.tinypic.com/2dsqlv7.jpg http://i31.tinypic.com/2wlsj29.jpg

[elguaxo]

:)

that encode would probably benefit from more bitrate, but the VAQ version is definitively better.

[kandrey89]

that was in VHQ mode 4
I've just tried VHW mode 1, and it seems much better, what are your experiences with VHQ modes?

Edit: NVM, I'll stick with VHQ Mode 4, it's slower but better quality. even though I might not have saw it at that particular frame.

[Brother John]

My experience is that high VHQ (definitely 4, maybe 3 as well) can cause swimming textures in low quant encodes, especially CQ2. I’ve never thoroughly investigated but the problem never occured again after switching to VHQ 1 for speed resons (other settings unchanged), so VHQ seems to have caused the problem.

[Ranguvar]

In my experience, Brother John, it's more that low VHQ keeps small artifacts that make the video appear to have retained more detail. I may be wrong, but this is what I've seen. If I had more time, I'd make a test, but I'm too busy right now... if anyone reads this who has some spare time, please do help :)

[Gromozeka]

Dark Shikari
But you may add your VAQ to Hcencoder? :)

[Dark Shikari]

Dark Shikari
But you may add your VAQ to Hcencoder? :)HCencoder--if you mean HCenc, doesn't that program already have it?

Either way, of course--it isn't like I've patented it or anything :p

[Gromozeka]

I do not know how to program - unfortunately. :(

[rack04]

I do not know how to program - unfortunately. :(

What he's saying is that HCenc has it's own form of VAQ.

Changes from version v0.22:

Added adaptive quantization
Added panscan

BTW, this has nothing to do with Xvid.

[Gromozeka]

Yes, I read it. But I do not know anything about algorithm AQ of HCencoders.
VAQ from Shikari is already tested and probably best
Thanks - I have understood both :)

[Sharktooth]

there is no best as per forum rules.

[rack04]

Yes, I read it. But I do not know anything about algorithm AQ of HCencoders.
VAQ from Shikari is already tested and probably best
Thanks - I have understood both :)

Why don't you ask Hank, the author of HCenc?

[henryho_hk]

Just a dummy question.... Is VAQ (or old AQ) non-effective in constant quantitizer mode encoding?

[Ranguvar]

Should be, but I *could* be wrong.

Try'n'see ;)

[henryho_hk]

It seems VAQ is effective in constant quality mode too.

xvid_encraw = squid_80's 20070831 build
xvidcode = Koepi's 20080403 XviD-1.2.-127-VAQ build.

cmdline:

xvid_encraw -zones 0,w,1.0,K -threads 3 -progress 100 -max_key_interval 500 -quality 6 -vhqmode 1 -max_bframes 2 -bquant_ratio 162
-bquant_offset 0 -qtype 0 -bvhq -single -cq 2.0 -type 2 -i t.avs -avi t_nn_20.avi -stats t_nn_20.stats
xvid_encraw -zones 0,w,1.0,K -threads 3 -progress 100 -max_key_interval 500 -quality 6 -vhqmode 1 -max_bframes 2 -bquant_ratio 162
-bquant_offset 0 -qtype 0 -bvhq -lumimasking -single -cq 2.0 -type 2 -i t.avs -avi t_aq_20.avi -stats t_aq_20.stats


t_nn_20.stats:

500: key=0, time= 47, len= 28284 | type=B, quant= 3, len= 28284, psnr y = 41.92, psnr u = 45.24, psnr v = 46.12
501: key=0, time= 0, len= 6 | type=P, quant= 2, len= 113496, psnr y = 43.79, psnr u = 45.79, psnr v = 46.62
502: key=0, time= 109, len= 147674 | type=B, quant= 3, len= 27221, psnr y = 42.08, psnr u = 45.48, psnr v = 46.36
503: key=0, time= 47, len= 27778 | type=B, quant= 3, len= 27778, psnr y = 42.06, psnr u = 45.40, psnr v = 46.26
504: key=0, time= 0, len= 6 | type=P, quant= 2, len= 120459, psnr y = 43.95, psnr u = 45.76, psnr v = 46.61
505: key=0, time= 47, len= 73726 | type=P, quant= 2, len= 73726, psnr y = 43.93, psnr u = 45.80, psnr v = 46.66
506: key=2, time= 15, len= 263785 | type=I, quant= 2, len= 263785, psnr y = 45.66, psnr u = 46.81, psnr v = 47.62
507: key=0, time= 109, len= 152695 | type=B, quant= 3, len= 40027, psnr y = 41.60, psnr u = 45.12, psnr v = 46.12
508: key=0, time= 47, len= 42985 | type=B, quant= 3, len= 42985, psnr y = 41.83, psnr u = 45.45, psnr v = 46.55
509: key=0, time= 0, len= 6 | type=P, quant= 2, len= 112674, psnr y = 43.99, psnr u = 46.39, psnr v = 47.28


t_aq_20.stats:

500: key=0, time= 47, len= 32955 | type=B, quant= 3, len= 32955, psnr y = 41.23, psnr u = 43.90, psnr v = 44.83
501: key=0, time= 0, len= 6 | type=P, quant= 2, len= 73166, psnr y = 41.52, psnr u = 43.97, psnr v = 44.89
502: key=0, time= 140, len= 109082 | type=B, quant= 3, len= 31318, psnr y = 41.45, psnr u = 44.19, psnr v = 45.13
503: key=0, time= 47, len= 31880 | type=B, quant= 3, len= 31880, psnr y = 41.47, psnr u = 44.10, psnr v = 45.05
504: key=0, time= 0, len= 6 | type=P, quant= 2, len= 77770, psnr y = 41.71, psnr u = 43.93, psnr v = 44.87
505: key=0, time= 63, len= 46075 | type=P, quant= 2, len= 46075, psnr y = 41.65, psnr u = 44.02, psnr v = 44.95
506: key=2, time= 31, len= 202642 | type=I, quant= 2, len= 202642, psnr y = 42.91, psnr u = 44.48, psnr v = 45.41
507: key=0, time= 109, len= 113760 | type=B, quant= 3, len= 42434, psnr y = 41.29, psnr u = 44.03, psnr v = 45.05
508: key=0, time= 63, len= 43728 | type=B, quant= 3, len= 43728, psnr y = 41.54, psnr u = 44.51, psnr v = 45.56
509: key=0, time= 0, len= 6 | type=P, quant= 2, len= 71332, psnr y = 41.79, psnr u = 44.63, psnr v = 45.58


ffdshow's visualizations:
-----------------------
http://img230.imageshack.us/img230/4836/tnn20f504cropii9.th.png (http://img230.imageshack.us/my.php?image=tnn20f504cropii9.png)
-----------------------
http://img392.imageshack.us/img392/6355/taq20f504cropbs9.th.png (http://img392.imageshack.us/my.php?image=taq20f504cropbs9.png)

XviD VFW stats with the same parameters:
-----------------------------------------
http://img232.imageshack.us/img232/5365/xvidnnstatji4.th.png (http://img232.imageshack.us/my.php?image=xvidnnstatji4.png)
-----------------------
http://img71.imageshack.us/img71/7554/xvidaqstatxa6.th.png (http://img71.imageshack.us/my.php?image=xvidaqstatxa6.png)

[MyCometG3]

Note that I could not get it working correctly with mencoder; for some reason libavcodec seems to have its own lumimasking library that's overriding my patch. It works with xvid_encraw and VfW though...

Dark-san,
Would you please tell me how to find the result is incorrect or not?

I am trying to implement your VAQ patch into my QuickTime Component xvidEncoder (libavcodec+xvid daily snapshot+VAQ patch; Sorry it runs on MacOS X only).

Under many trial, xvid via libavcodec seems to work well:
- decrease total video stream size
- make less blocky frames
- make fewer pseudo edges than VAQ-off

I am not sure VAQ Really runs well or not though...
current sample is here: http://www.fileducky.com/eKMeZZYg/

Or, am I misunderstood VAQ behavior?

[Dark Shikari]

Dark-san,
Would you please tell me how to find the result is incorrect or not?

I am trying to implement your VAQ patch into my QuickTime Component xvidEncoder (libavcodec+xvid daily snapshot+VAQ patch; Sorry it runs on MacOS X only).

Under many trial, xvid via libavcodec seems to work well:
- decrease total video stream size
- make less blocky frames
- make fewer pseudo edges than VAQ-off

I am not sure VAQ Really runs well or not though...
current sample is here: http://www.fileducky.com/eKMeZZYg/

Or, am I misunderstood VAQ behavior?The way I can tell whether it works or not is by looking at the quantizer distribution and seeing if it matches what is expected from the VAQ algorithm. This can be done with ffmpeg's visualization option, or with the proprietary Elecard Streameye.

[MyCometG3]

The way I can tell whether it works or not is by looking at the quantizer distribution and seeing if it matches what is expected from the VAQ algorithm. This can be done with ffmpeg's visualization option, or with the proprietary Elecard Streameye.

Thank you for Quick advice. I have tested them with FF_DEBUG_VIS_QP.
I can confirm that under VAQ on, I/P frames takes different QP in each macroblocks.
I guess I can say it runs well. Cool.

Here is the result.
http://mycometg3.blog.so-net.ne.jp/_images/blog/_1be/MyCometG3/E38394E382AFE38381E383A3202-5bd09.png

[TheResidentEvil]

If I update the files listed in this thread and then use AutoGK, will it automatically be using VAQ or do I need to change a setting in AGK?

[Sharktooth]

autogk comes with it's own version of xvid. stick with that version unless you want problems. also, VAQ replaces the normal AQ, if autogk does not use AQ then it wont use VAQ...

[DeathTheSheep]

Can anyone post/build/compile the most recent CVS with the newest fixed version of VAQ (it had some improvements and bugfixes in x264 since this 15-minute port was made)? Or are all such changes totally irrelevant (i.e. no new changes/fixes in CVS, and no ASP-applicable changes to VAQ)?

[Sharktooth]

good luck...

[Midzuki]

Well, here goes a hex-edited (and renamed) version of squid_80's xvid_encraw.exe
( in order to avoid possible confusion/interference with the original program,
I've decided to call it "xvidencoder.exe" :) ).

In it, the command-line switch "-lumimasking"
was replaced with the option "-variance_aq"; besides,
now it requires that a "VAQ-patched" xvidcore.dll be renamed to
"xvidc0re.dll". Because, as someone said elsewhere in this thread,
« VAQ deserves a better name than "-lumimasking". :) »

xvidencoder - raw mpeg4 bitstream encoder written by
Christoph Lampert, 2002-2003


xvidencoder built at 10:22:53 on Aug 31 2007

USAGE : xvidencoder [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer : input data type (yuv=0, pgm=1, avi/avs=2)
-w integer : frame width ([1.2048])
-h integer : frame height ([1.2048])
-frames integer : number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream,
or AVI file,
or MKV file,
based on filename extension
-avi string : save an AVI file for the complete sequence
-mkv string : save a MKV file for the complete sequence

BFrames options:
-max_bframes integer : max bframes (2)
-bquant_ratio integer : bframe quantizer ratio (150)
-bquant_offset integer : bframe quantizer offset (100)

Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate (700)
values <= 10000 are treated as kbit/s
values > 10000 are treated as bit/s
-size integer : target size in kilobytes
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-altpass2 [filename] : twopass mode (2nd pass alt)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-zones : see xvidencoder -help zones
-max_key_interval integer : maximum keyframe interval (300)

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (24)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced [integer] : interlaced encoding (BFF:1, TFF:2) (1)
-nopacked : Disable packed mode
-noclosed_gop : Disable closed GOP mode
-variance_aq : use Variance AQ algorithm
-hvs_aq string : use custom adaptive quantisation equation
-hvs_lmb string : use custom lambda equation
-stats : print stats about encoded frames
-ssim [integer] : prints ssim for each frame ([0..4]) (2)
-ssim_file filename : outputs the ssim stats into a file
-debug : activates xvidc0re internal debugging output
-vop_debug : print some info directly into encoded frames
-nochromame : Disable chroma motion estimation
-notrellis : Disable trellis quantization
-imin integer : Minimum I Quantizer (1..31) (2)
-imax integer : Maximum I quantizer (1..31) (31)
-bmin integer : Minimum B Quantizer (1..31) (2)
-bmax integer : Maximum B quantizer (1..31) (31)
-pmin integer : Minimum P Quantizer (1..31) (2)
-pmax integer : Maximum P quantizer (1..31) (31)
-drop integer : Frame Drop Ratio (0..100) (0)
-start integer : Starting frame number
-threads integer : Number of threads
-nothreadedinput : Disable threaded input reading
-progress [integer] : Show progress updates every n frames (10)
-par integer[:integer] : Set Pixel Aspect Ratio.
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : prints this help message
-help zones : prints zones help message

NB: You can define 64 zones repeating the -z[qw] option as needed.

Contents of the attached archive:

aviwriter.dll
xvidencoder.exe
xvidencoder.info

If the modified application happens to not work as it should on your PC, don't be afraid to complain about the issue(s). :o

[Gromozeka]

Dark Shikari, you can be shall port VAQ xvid in mencoder for mpeg2 and XviD encoding?
sorry my english

[henryho_hk]

It seems no one cares/has succeeded including compiling mencoder with an updated version of XviD binary.

Also, mencoder's first pass seems to be CQ=2 and cannot be altered. Teegedeck's presets likes CQ=3 for 1st pass.

[Gromozeka]

"It seems no one cares/has succeeded including compiling mencoder with an updated version of XviD binary."

This bad. :(
I not programmer
Nobody has no time to do this?

[Gew]

I wrote an entry-level Wikipedia article on VAQ, with the bare minimum that I know about it.
I.e. there's hardly any substance in the article just yet. Feel free to correct/elaborate on it.

http://en.wikipedia.org/wiki/VAQ

Regards~

[Sharktooth]

Ehrr... "Variance Adaptive Quantization (VAQ) is a video encoding technique that was first introduced in H.264 (MPEG-4 AVC)" no...
that's completely wrong. VAQ was introduced in x264 (that is an opensource h.264 implementation).
also it is a new (invented from scratch) algorithm of adaptive quantization... also "some lobbyist coder" is actually one of the x264 devs (Dark Shikari).
VAQ is also used in HCEnc (a mpeg2 encoder)

[zmaster]

Sorry for the stupid question, but where you can download the magicxvidcore.dll? :/
Link is in first post does not work.

[Midzuki]

@ zmaster:

http://mirror05.x264.nl/Dark/


--- it's the last item on the listing.

[zmaster]

Midzuki,
:thanks:

[Hagbard23]

You can also get a VAQ Patched Version here:

http://www.xvidvideo.ru/xvid-video-codec/

I think it is a more recent build, but i do not know exactly (DS Version is from 1st July 2009 / XVidVideo's Version is from 14th August 2010.

[zmaster]

Hagbard23,
I compared the results to me more like the image after compression with the aid of modifications from Dark Shikari.

[Hagbard23]

Hagbard23,
I compared the results to me more like the image after compression with the aid of modifications from Dark Shikari.

I do not understand you. The russian Builds do contain DarkShikaris VAQ Patch as well. There is no other...:confused:

[zmaster]

I get different results after using this version xvidcore.dll and that which is included in Xvid on xvidvideo. But it's does not mean that it's only VAQ.

[yetanotherid]

Could someone be so kind as to tell me if this VAQ patch is different to the VAQ patch which the version of XviD installed by AutoGK uses?

From the 2.53 release notes:
http://www.autogk.me.uk/index.php?name=News&file=article&sid=74
"XviD now uses VAQ if source is not a cartoon (XviD setting in hidden options control's that) or have burnt-in subs."

[SilaSurfer]

The link provided on first page of this thread doesn't work. Dark Shikari is Koepi's build 1.2.1 VAQ ok to use?

[Tuik]

I'm using the xvid_encraw from megui (with development server) with the option -lumimasking, the custom matrix done by Didee, SixofNinesHVS.xcm and something like 1900/2000 bitrate (backup bluray to xvid). Also using 3 b-frames.

Is it a good combination?

[Sharktooth]

it depends. we do not share minds so i dont know... good for what?
details pls (for example, if you want to keep 1080 res or downsize to 720 or even lower, compressibility of the movie, etc...)

[henryho_hk]

1900/2000 kbps for 1080p? (and which deinterlacer are you using?)

[Sharktooth]

1080p doesnt need deinterlace

[henryho_hk]

No... I mean deinterlaced 1080i .... a bit too lazy in typing ~lol~

[Tuik]

it depends. we do not share minds so i dont know... good for what?
details pls (for example, if you want to keep 1080 res or downsize to 720 or even lower, compressibility of the movie, etc...)

I want to downsize it to 720p and 480p ;)