Looking for unstable releases where lumamask and qpel are working

[OUTPinged_]

I see here quite a number of people who use luma masking and qpel as their default settings for xvid encoding with development builds.

But for some reason i get negative gain from luma masking and qpel when they are enabled - filesize gets bigger and psnr decreases.

Luma mask is working in Koepi's 04102002-1 build for me, so it's not a problem on my end.

I tried 3 of the later development builds i managed to find, all of them failed to deliver "working" luma mask and qpel. This is still not much but i didnt manage to get any earlyer releases.

Are there any particular later development builds where qpel and luma masking work as they are supposed to? If anybody has it working, please tell me which build it is. Thank you.

[sam_b]

There's more to life than PSNR. Qpel has pretty much always increased size, as has the new lumi masking. Why is it suprising that the filesize increases with both? If you don't like the 'look' of either don't use them, but don't expect everything to make positive psnr/size changes.

[OUTPinged_]

QPEL:

I know no one would believe whatever i say, so here are citates from the "big boys talk":

"1/4 pel ME is supposed to give a big boost to the compressio ratios. "

"As for proof on the benefits of 1/4, I have none specifically for it but have come across numerous statements that it brings coding efficiency. Simply put, it allows for a closer matching of blocks between two consecutive frames. This means a lower prediction error and that means more zeros that come out of the DCT process and therefore a lower bitstream"

"For the right input source quarterpel can reduce filesize (I measured up to ~9%)."

...straight from xvid.org' forum.

You can pick on a last quote saying that it mentions that some sources would produce bigger files even with prefect implementation, but it should definitely not be a 10% increase in a filesize i am getting.

LUMAMASK:

even with a very dark samples in 2pass mode i dont get any decrease in size. PSNR is increasing, too.

Contrary to that old koepi's build shaves up to 5% of bitrate comfortably.

I read the thread on "new lumamasking algo", which was introduced in July(or August), and the testers reported decrease in framesizes. Even using "wrong" sources they were gaining ~0.1% off the size. I get 2% increase in framesize with extremely dark "night action" clip. I get 5% increase in size with regular clips.


And i dont think that increased framesize+decreased psnr could produce better percieved quality in this case.


The point is, both of these settings are supposed to decrease filesize or increase picture quality. Why i don't see that happening?

I get positive effect with lumamask from stable November build. Is it supposed to work that way? If yes, why it isnt working for me in later builds? If no, how does one benefit from that setting now?

If there are some specific clips that benefit from qpel, can anybody tell their properties (should they be dark/bright/contrast/low-high motion/noisy/etc) please?

[wotef]

best releases (for me) where Qpel encoding and decoding worked were Koepi's 09/12/02 build and Nic's early and late february builds

Qpel and H263 is superb, compare with it and without it for detail retention on a clean source and you will see what it does

i don't use lumi-masking

[TheXung]

Looking at this http://andrei.myip.org:8000/users/chl/basic.html, you can see numbers that other people have been getting. While there are a few clips where the psnr does decrease (notice how the decrease is slight when compared to clips that have psnr increase), overall, 1/4 does increase psnr on average.

But as pointed out before, 1/4 basically benefits slow motion scenes. There was talk of dynamic 1/4 and 1/2 decision, but on a per frame basis, that would not be mpeg4 compliant and caused disagreement amongst the developers.

Just what sort of test clips are you testing on? There is no point in optimizing quality for atypical clips.

[Assault]

@OUTPinged_

Koepi once mentioned that refdivx lumi masking code doesn't decreases filesize but works as a bitrate redistributor. Therefore it should improve quality.
The stable builds exactly as nic's and umanic's builds use the "old" lumi masking code which is in cvs and it decreases filesize because it works in another way.

Regards
Assault

[sysKin]

Originally posted by OUTPinged_
QPEL:

Qpel uses more motion data and a bit fewer DCT data. In some clips the first wins, in some - the second.
Create a low to medium motion clip, low resolution (512x or less) and use a sharp resizing filter (bicubuic, lanczos). This is where qpel will decrease filesize at quant 2.

Generaly it works this way for most standard test videos, so people say it's common. It usually doesn't work this way for dvd rips.

LUMAMASK:

"Adaptive quantization" means that we can change quantizer within a frame. "Change" does NOT mean "increase". We can as well decrease it. In fact, to make things working, the average quantizer should remain the same, so filesize should be also the same.
As for PSNR, it says "peak signal-to-noise ratio" and if you increase quantizer for a single macroblock, the peak will probably be there and will be recorded as higher.
And i dont think that increased framesize+decreased psnr could produce better percieved quality in this case.OK, so don't use it. I don't use it either, but not because of PSNR.
BTW I haven't heard of any lumimasking which would improve PSNR.

Radek

[OUTPinged_]

BTW I haven't heard of any lumimasking which would improve PSNR.

Is there any way to measure quality that would show improvements that are brought in by using lumamask?

Also, i finally found a test clip where i see lumamask in action with later build. I had to bump up brightness alot when examining it though.

I can't say it makes image look any better(quant.5 was used for a frame i examined).

In fact, to make things working, the average quantizer should remain the same, so filesize should be also the same

Dbview logs were used to check if frames have same quantizer value. Vdubmod was used to see framesizes.

[OUTPinged_]

OK, so don't use it. I don't use it either, but not because of PSNR.

I am now writing a local language guide for xvid usage. Started this thread because my set of 5 test clips didnt show any gains from qpel and lumamask. It's kinda lame to write "this feature doesnt do anything for me so don't use it" :-)

There i want to find out on which conditions i would benefit from qpel and lumamask. As writing "looks better to me" or "i like it 'cause it sounds k3wl" is a no-no, it shoud do at least one of 3 things:

1. Decrease framesize (under a certain conditions).
2. Increase PSNR.
3. Look noticably better on some frames so that I could use them to point "look, it gets better here".
4. Increase speed.

I assume that other people who are experienced and use there features for default encodes, seek for same benefits from them.

[sam_b]

I really don't think there is any advice that will generally useful other than 'use what looks good for you'.

I would say that the picture changes qpel brings completely outweigh any size alteration due to it. I do not care what PSNR a setting achieves on a clip. It is a useful qualatitive measure where there are too many variables to easily judge difference by eye. I see little use for it in deciding whether to use qpel or not. I am sure people reading your guide will accept that sometimes you just got to look at what's coming out of the decoder each time. Sometimes qpel looks awful, sometimes it looks great, it has little to do with the bitrate produced.

I will not try to advise about lumi, as I rarely use it, but I believe the advice must be similar. This is assuming you are using koepi's builds.

[wotef]

"I assume that other people who are experienced and use there features for default encodes, seek for same benefits from them."

nope, in fact i used qpel for some "don't care too much about filesize, don't care about speed" encodes at quant 2 - the qpel files were always bigger (and retained more fine detail) than an equivalent encode without qpel + they were also always longer to encode....

PSNR, why obsess about it - honestly, who cares?

if you want MASSIVE compression gains, you'd be better off with steady's pixiedust filter

[mf]

Lumi masking is simply "If something looks bad, use lumimasking, so it'll make something else look bad which isn't as noticable if it looks bad". With clips that already look good without it it's not very wise to use it, cause there will be a quality decrease somewhere. It's just that if the quality decrease is inevitable, you might as well let it be somewhere it's not as noticable.

[OUTPinged_]

Alright, here is what extensive testing (7dvds with different noise levels and diferent amounts of motion were used to judge qpel) showed me:

1. High motion scenes, noise and qpel dont mix. Framesize bumps up 20-40% on high motion parts. Noise helps framesize to grow too. Ugly. Here is why "qpel clips need more cpu power to decode" - they need 40% more cpu power for highmotion scenes.

2. Clean low motion clips _do_ compress better. Yay. I am getting up to 7% of framesize reduction there.

About "better quality": I can't see any difference there. Must be wrong clips :/

if you want MASSIVE compression gains, you'd be better off with steady's pixiedust filter
Nah, i will get old before the encode will finish.

Also, filters are out of this topic.

[Tommy Carrot]

The main idea of the qpel is not the compression gain!!! It simply keeps more details on a given quantizer. Create 2 clip with constant quantizer, qpel on and off, and compare them to each other in virtualdub. Ya'll see huge differences in the detail (and sadly, in DCT noise too, a side-effect of qpel). Usually qpel gives smaller filesize too, but that's not important.

[OUTPinged_]

Sorry Tommy, I didnt see any increase in quality while using qpel. Even with "SUBTRACT().LEVELS()" difference clips.

That may be due to fact that the resolutions of my clips are 640x - 1280x, for i am not interested in results of low-res clips.

If you can post here 2 screenshots which do show noticable differences due to qpel enabled, i would be very thankful.

[avc]

Originally posted by OUTPinged_
Sorry Tommy, I didnt see any increase in quality while using qpel. Even with "SUBTRACT().LEVELS()" difference clips.


If you want to use Qpel in Xvid codec, you risk generating non-standard video clip. No one will correct it for you.

BTW, for high resolution, I don't see any advantage of using qpel, it is merely wasting your time.

Similar problems exist in Xvid's b-frame, interlaced.

[OUTPinged_]

@avc

MPEG4 consists of several profiles.

"simple advanced" has bframes, qpel, gmc and interlacing covered, so they are perfectly legit.

On the other hand Sigma chip supports only "simple" profile, so if it does brake some compatibility with standalones, that feature better be more efficient than 5% compression gain i get from gmc and qpel.

I like bframes. When used right, they can decrease 1pass size up to 30% without notable quality differences.Which means we finally can have 640x res as minimal for hq releases. Screw those 512x addicts.

[sam_b]

He was talking about Xvid's qpel specifically, not ASP's qpel. Try 512x with qpel and still see if you can't see a difference. As avc said, if your obsessed with 640x480, qpel is probably just wasting your time.

[avc]

Well, I am not saying you should not use adv options in xvid. Just be cautious, and verify them before you start to use. If you have time, you can try them all:) I suggest you can use Envivio's player to verify.Tell you my experience, now it is a pain for me to convert all ill-format xvid interlaced video to standard ones. I am thinking to setup a paid job for that too.

Are you sure Sigma chip only supports "simple" profile? Is it that simple?:confused:

[sam_b]

Supports simple + B-frames. Probably Simple + b-frames + 1 warp-point GMC in the new sigma decoder.