About the new luma-masking algo..

[MoonWalker]

I want to test the new Luma-masking in the newer XviD builds...So I got "The others"(great movie, very dark)..I was thinking to do one-pass quantizer mode at 2x with Luma enable and disabled and the then compare the final size and the visual quality..Is this worthly?

MoonWalker

[soujir0u]

I tried encoding with the new CVS builds, and found that Koepi's build produced smaller files with the clip that I tried (both cases with lumi masking on). Probably due to the fact that Koepi's build uses EPSV^2 (or was it EPVS? :confused:), not sure though. The picture quality looked about the same to me.

[rui]

Originally posted by soujir0u
I tried encoding with the new CVS builds, and found that Koepi's build produced smaller files with the clip that I tried (both cases with lumi masking on). Probably due to the fact that Koepi's build uses EPSV^2 (or was it EPVS? :confused:), not sure though. The picture quality looked about the same to me.

This confirms some tests i have done too.

Some time ago, when Koepi (and Nic) launched their EPSZ and EPSZ^2 activated builds, i compared two files with the same size (2-pass encode), one made with Koepi's build and the other made with a uManiac's build, which didn't have EPSZ code enabled.
I even posted here that Koepi's resulting avi was keeping more details, and since the builds were equal, except for the EPSZ code, this one must be the responsible for the quality increase i was getting.

But, testing this later uManiac's builds, for the same filesize (2-pass encode) the quality between them and Koepi's build are the same now, at least IMHO.

Since i believe that uManiac's builds still don't enable EPSZ code, something has improved (new lumi?).
If Koepi, or Nic, would compile a new build, based in the latest CVS, with EPSZ enabled, i believe that we would experience a little jump in quality.

[yaz]

Originally posted by rui


... Koepi's resulting avi was keeping more details, and since the builds were equal, except for the EPSZ code, this one must be the responsible for the quality increase i was getting.

But, testing this later uManiac's builds, for the same filesize (2-pass encode) the quality between them and Koepi's build are the same now, at least IMHO.

Since i believe that uManiac's builds still don't enable EPSZ code, something has improved (new lumi?).


i confirm all above.

add.:
- the new (tested) build of umaniac seems to be quicker than the last one from koepi
- i can't notice any significant difference in quality (earlier there was, esp. in how they treated the small objects in the background), but it may come from the characteristics of the clip i selected for the test.

hmmm ... it's never obvious (for me) what do they take from each others build/improvements :-) anyway, the latest builds seem to be quite "compatible", as regards quality (imho:-))

the bests
yaz

[Nic]

Because rui helps me out so much, his wish is my command :D

http://nic.dnsalias.com

Changes:
EPSZ and EPSZ^2 activated.
Intel Compiler 6 Compiled! :)
New lumi-Masking
New Mini-Calc...
(Its been a while :) )

Still has my filter, but that stills has the green frame bug :( Ill fix that soon.

Cheers,
-Nic

[JasonFly]

Nic:
Do you develop xvid or you just compile the sources?

Nothing to do with this but when will Xvid be is final version?

[Nic]

Nope, I developed my filter, but thats it, other than that I just compile the sources :) (I wish I had time to do more)

I hope XviD will never be "finished" & will just keep on developing... :) But things are moving forward now after a bit of a slump, B-Frames are working for fixed quants for the developers, so there not too far off from being full usable (I hope! :) )

-Nic

[rui]

Originally posted by Nic
Because rui helps me out so much, ...
It was an honor, Nic. :)
Originally posted by Nic
I hope XviD will never be "finished" & will just keep on developing... :) But things are moving forward now after a bit of a slump, B-Frames are working for fixed quants for the developers, so there not too far off from being full usable (I hope! :) )
-Nic
This are good news.
I've noticed that the later builds already have a new tab (disabled, for now) to configure b-frames. ;)

[Nic]

Well, only for testing purposes and the experienced (!) :

http://nic.dnsalias.com/xvid.dll

This has B-Frame support (!!!!) (just overwrite the old xvid.dll in your Windows System(32) directory)

Seemed to work fine doing a CBR encode, I used the DX50 FourCC & turned on DX50 BVOP compatability. File was slightly bigger, but quality was good !

Cheers,
-Nic

ps
I just tried to do a 2pass encode with B-Frames, went fine, but the picture did get slightly corrupt at times. Please remember, this is just for experimentation & to show the current progression of the codec.

[soujir0u]

Cool, now people will stop asking when B-frames is ready. Although it isn't really ready yet... :D

Will XviD forever stay in alpha stage just like ICQ stays on beta? :)

[ProfDrMorph]

would be a funny thing if my luma masking code is already working well :). Someone with Win32/Knowledge should add a temporay tab for luma masking settings. This could help us finding better constants. To be honest: I hadn't have the time to do a real test to find out which constants are good. So the values my new luma maskin code is currently using are crap to say the least. Anybody who's interested in making a temporary change to the VfW front-end can mail me in case he wants to know what values have to be changeable. I could upload a build with this front-end to my webspace ( only the "final" constants we find for luma masking should be committed to CVS and not a more complex front-end. Maybe a single slider for luma masking agressivity should be in the CVS version of XviD but nothing more. )

for any body who's interested:

http://home.t-online.de/home/profdrmorph/xvid/xvid_13.6.2002.zip

this is the link to the build I made after writing the new luma masking code.

Note: please do not only compare file sizes but also quality of encoded movies!

[rui]

well, i just made a small test using Nic's dll with b-frames enabled.
I can't be sure if i enabled them correctly.
I left all xvid configs at default except:

motion search - 6
enabled packed bitstream

I left the maximum b-frames at -1 (?). Probably i didn't enabled them at all?
i will try to change this value to see what happens.

[rui]

Ok, i changed the maximum b-frames to 1, but Vdub crashed :(
Probably it will need to be modified to support xvid b-frames.

[Nic]

(hmmm worked ok for me? I set the value to 100 (just as a random value). I did the encoding in VDub...(Win2k, Celeron 1000)

-Nic

[rui]

Ok, i think that i got it.
I said above that i had left xvid config at default but that wasn't completely true. I had enable ME hints.

Now that i disabled them, the 2-pass encode works.

But i can't judge the video, because i am at work with my p2-350 and win95B, and it would take forever to do a test here :(

I just got the encode started, saw that it wasn't crashing, and came here to the forum to post this.

I used, this time, the xvid defaults, except:

motion search precision - 6
maximum b-frames - 50
packed bitstream enabled

I didn't enabled the dx50 B-VOP compatibility, since i don't intend to use divx to see the video. This is the reason because this option exists, correct? Or is there another reason?

[Teegedeck]

Originally posted by rui
Ok, i think that i got it.
I said above that i had left xvid config at default but that wasn't completely true. I had enable ME hints.

Now that i disabled them, the 2-pass encode works.

But i can't judge the video, because i am at work with my p2-350 and win95B, and it would take forever to do a test here :(


Hm, you might be disappointed when you come home. :( After what I've read on XviD.org, it doesn't work with 2nd pass, yet.

[d4Rk Ch1Ld]

I'm doing some home-testing on newest XviD (without B-frames) and i am very confused with those luma-masking... can anybody tell me does luma masking have to be enabled during 1st pass or during both passes ? (prior XviD had shadowed luma masking in 1st pass)


does your testings prove better with luma-masking off or on ?
more/less details ? corrupted frames from time to time ??

thanx for u'r time...

[soujir0u]

Originally posted by d4Rk Ch1Ld
I'm doing some home-testing on newest XviD (without B-frames) and i am very confused with those luma-masking... can anybody tell me does luma masking have to be enabled during 1st pass or during both passes ? (prior XviD had shadowed luma masking in 1st pass)


does your testings prove better with luma-masking off or on ?
more/less details ? corrupted frames from time to time ??

thanx for u'r time...

Hi, I usually turn it on for both first pass and second pass. It's main purpose is to increase compressibility, and I never got any corrupted frames with it before.

[Bulletproof]

Shouldn't Luma masking be increasing bitrate? that's what Nandub was doing becuase the codec often did not give enough bitrate to less complex scenes and thus the luminance masking was compensation for that..

[Gant]

hummm... and all this time i thought luma masking was suposed to ... well Bulletproof already said it...
Please people who know.. explaint it better...

Thnaks in advanced.

Gant

[d4Rk Ch1Ld]

luma masking is suppose to compress darker and lighter areas of the frames harder that hunman eye can barely see the difference... and that bitrate thats saved there is used on some more important scenes... but i was just curios how do you people do it and does it have any negative effects (bad frames, tear picture etc..) ?

[Teegedeck]

Bulletproof, Gant:

That thing in Nandub was called luminance correction, what we have here is luminance masking. Perhaps if you just think of 'brightness' instead of 'luminance', you get the idea. The 'correction' implies that there was something wrong in DivX311 with brightness that had to be corrected by Nandub (giving more bits to some scenes, as you've mentioned). The 'masking' refers to treating some parts of the picture differently from other parts, based upon their different brightness-values. Because XviD doesn't have the problem of dark scenes not getting enough bits, masking is used to give less bits to parts of the picture where it isn't noticeable (or so one hopes).

Also, if you use it in both passes, the codec can make a better guess on the bitrate savings and will use lower quants to begin with. A redistribution of bits from overall darker scenes to overall brighter scenes can happen but isn't inevitable.

Hm, d4Rk Ch1Ld really already explained that. No generally, you don't notice any adverse effects. But in some cases you might have one of these problems (it depends on personal taste whether you see it as a problem): (1) solid red is generally a problem in video as with the color red, we easily notice that color information is stored with a smaller resolution than brightness information. Luma masking tends to increase this effect if you use VERY high quantizers, but it occurs very, very seldomly that you can notice it. (2) I remember that moving objects in front of a highly compressed background could 'smear' into the background, sometimes - but I haven't seen this effect for ages, maybe it's been solved, maybe because I use mv-hints for the 2nd pass. (3) There can be more 'ringing' around detailed objects in front of a highly compressible background.

Personally I always use luma-masking for both passes if it gives me 5% or more gain in compressiblity. It's really worth it. If it gives me less gain than this, I don't use it for a 2-CD-encoding.

[Bulletproof]

Ok, that explains Luma Masking, thanks. While we're on an active discussion here I guess now would be a good time to bring something up that's been on my mind.

When I first got XVID I noticed that I seemed to get very noisy playback in 16-bits color mode on my desktop. Just random noise going everywhere. BUT, there was a HUGE advantage here. The picture was extremely sharp and had ZERO color bleeding. An example would be Yellow subtitles with a black border, when I was seeing them in that state they were completely sharp with no bleeding whatsoever.

The noise however was intolerable. Someone on the board had told me to switch my desktop to 32-bit mode to try to solve the problem, this indeed fixed it. But the colors seemed washed out as they used to in DivX 3.11, Yellow subtitles were washing out in the background.

So the question here is, is all the washing out on the video being caused by my video card? maybe it's the overlay causing it to wash out? The sharp picture and color looked very nice if it wasn't for that noise.

[ProfDrMorph]

Originally posted by d4Rk Ch1Ld
luma masking is suppose to compress darker and lighter areas of the frames harder that hunman eye can barely see the difference... and that bitrate thats saved there is used on some more important scenes... but i was just curios how do you people do it and does it have any negative effects (bad frames, tear picture etc..) ?
Depending on the "aggresivity" of the luma masking ( how much detail is removed in those very dark/bright areas ) algorithm you may see the usual compression artefacts that become visible with higher quantizers ( blocking, ringing ). XviD lowers/raises the quantizer on a per macroblock-basis. In some cases XviD may thing that the loss is not visible when it is. That's why I asked for someone to make temporary test build with a changed VfW front end so that everybody can test different "constants" for the luma masking algorithm without recompiling the core all the time. I could try to make such a build myself but I know only few things about Win32 programming and all that stuff.

[Didée]

Originally posted by Teegedeck
...

Personally I always use luma-masking for both passes if it gives me 5% or more gain in compressiblity. It's really worth it. If it gives me less gain than this, I don't use it for a 2-CD-encoding.
Teegedeck, how do you figure out how much compressabilty you will gain by luma masking. Two complete first-passes, one with and one without masking? That takes time ...

Additionally, I want to mention a position 4) to the three above:
The artefacts introduced to the dark areas by luma masking, even if not noticeable on a monitor, are quite more easy to see on a TV.
Thats why I use luma masking very seldom: having done a rip on my PC, with great effort, and being under the impression to have done good work ... next time I watch that thing with some friends on the big TV in the living room, and when the film gets really dark, there are artefacts all over the place! (I made *bad* experience with "The Blair Witch Project", BTW)

But luma masking definetly points to the right direction, it only needs a better balance.

[Teegedeck]

Originally posted by Didée

Teegedeck, how do you figure out how much compressabilty you will gain by luma masking. Two complete first-passes, one with and one without masking? That takes time ...

No, only a compressiblity-check in GKnot, of course. 4% of the movie take me 25 minutes for each test with a slow CPU.

[soujir0u]

How do you do a compressibility check with Xvid using GordianKnot?

[Aktan]

Just load it like a nandub stats file

[Teegedeck]

There's a 'guides'-section on Doom9's...

Anyway, open the DVD2AVI-project in GKnot as usual, resize, save the .avs - but in the save-dialogue on the bottom right-corner, you'll find the options for the check. The resulting .stats-file should be opened with the 'load' button in the bottom middle of the GKnot main window.

[Gant]

@Teegedeck

Thanks a lot mate... this helped to clarify things. :)

Matta.

[Teegedeck]

After a first test, it seems to me the new algo is tuned too lightly. Hardly a difference in filesize between using it or not with constant quantizer; hardly measurable differences in compressibility. No-one to code a quick-and-dirty vfw-interface so we can alter the lumi-masking-settings?

[MoonWalker]

Arggg Teegedeck got me :) :):) ...

I made a test for the new luma masking over a whole movie (The others) with quant 2 (Nic's build 28-06-02)

No luma : 940.724.224 bytes Quality ok with some block at the foggy scenes(logical)

New Luma : 940.681.216 bytes Quality almost the same, some trails, some distortion at the edjes..

MoonWalker

[pandv]

As a quick-and-dirty programmer, if no one has the time to tweak the vfw interface, maybe one with experience in compiling Xvid can make it to read this values from a disk text file.

A very dirty solution, but I use it very often when in development stage (more dirty: I always force it to read the file from c:\).

Only a sugestion.

pandv.

[Koepi]

Const. quant. is a bad test for lumamasking.

Do it properly:

Either

a) a real 2 pass
b) CBR

After that you'd get better comaparable results.Const. quant does what it says: it keeps the quantizer constant. So no blocks get another quantizer - it's hardcoded in XviD this way (so it's strange to notice differences...).

Maybe someone could "pseed test" my dll as well - you were complaining my build is too slow.

Thanks,
Koepi

[Teegedeck]

Hello Koepi,

this sound kinda strange; luma-masking has always worked on the 1st pass - and that one is a constant-quantizer-pass, I thought. Anyway, I got a a difference of 0.1% in a compressiblity-test (1st pass) with new luma-masking as compared to no luma-masking. Maybe it's my source. I'll install an older version of XviD and compare against the old algo.
[EDIT:] Yep, it was my source; sorry for the WOB.

At least I seem to remember that first tests on the 1st luma-masking version were either done quantizer-based or quality-based. Can we use a quality-based one-pass?

Greets

Tee

[Koepi]

Hi Tee G. D. ;)

Sure you can use const. qual as well as it allows modulating the quantizer. I was just too lazy & busy to edit my post - just look at the plenty typos :)

Regards,
Koepi