Log in

View Full Version : Bframe harms image quality?


colasonic
30th November 2002, 19:46
I just finished testing Bframe+CM using a U-571 trailer. New techs surely give me a big surprise. With B+CM, the first pass size can be 20% smaller than w/o them. But I also found out that it seems B+CM also reduce the image quality although the avg. quantizer number is lower.

This is a snap of Normal 2pass encode result:
http://211.162.32.36/non-cgi/usr/10/10_170.png

And this is the snap of B+CM 2pass encode result. Pay attention to the edge of the submarine, especially in the red circle. Strange zigzag lines appear.
http://211.162.32.36/non-cgi/usr/10/10_170_1.png

Can anyone confirm this? and is it fixable?

Avs file:
LoadPlugin("E:\programs\divxtool\GK\mpeg2dec.dll")
mpeg2source("G:\divxtest\d2v\571.d2v")
crop(0,61,718,351)
lanczosResize(640,352)


Testing enviroment:

total 3610 frames. Koepi's XviD-25112002-1 binary, ultra high, H.263, Xvid ForceCC, min. max I P frame quantizer: 2, 4, 2, 10

the differences between my Normal test and B+CM test is:
B+CM use: Chroma Motion, B setting: 4-150-100, DX50 B-VOP compatibility.

both use internal linear scale and aim the same file size-30,838K.
Normal: 30848K avg. quan. 4.149
B+CM: 30868K avg. quan 3.747


BTW: would somebody please email a copy of new version Xvid Analyzer to my mail box(should be v0.16, right?)
jianhui@public.xm.fj.cn
I cannot access Moonwalker's website. it seems the geocities.com is banned in China...


Edit: use VD to catch these snaps.

Teegedeck
30th November 2002, 20:37
Without checking your samples, just let me mention that B-frames don't do magic on compressibility - it comes at a price. The B-frames just get higher quantizers, the trick is that you don't realize highly compressed B-frames as easily as highly compressed P- or I-frames.

Smaller first pass size is due to the fact that with B-frames, quant=2 isn't used on ALL frames but B-frames get something like quant=4 or whatever, dependending on your settings.

colasonic
30th November 2002, 21:12
but why debugview shows in first pass every frame including Bframe uses quant2? or you mean that even so, the actual quant of Bframe is higher?

Teegedeck
30th November 2002, 22:29
Well, I wouldn't know why dbgview should show an incorrect quant, but your first pass CAN'T be 20% smaller with B-frames if those B-frames don't have higher quants.

Anyone knows more than me on this one?

sprit
30th November 2002, 23:36
Sure, the first pass could be smaller with B-frames vs. without as the encoder would be able to use frames in the future as well as frames in the past (i.e. P-frames and two I-frames) when encoding a frame as a B-frame.

Teegedeck
1st December 2002, 00:04
Unfortunately that's purely theoretical (that this alone could save a 20% in size, that is). ;) Or have have I missed something? Koepi or anyone with helpful insights?

soujir0u
1st December 2002, 08:04
Interesting... I tried encoding a short clip, 2 passes with both B-Frames (3/150) and no B-Frames. I used a huge 2nd pass target file size to make sure that the resulting file will have all Quant 2. With DebugView, it shows that both encodes have all Quant 2s. The file with B-Frames was 33% smaller than the one with no B-Frames. I can't tell the difference between the two files...

Koepi
1st December 2002, 08:44
well, now GUESS why it says:

bframe QUANT ratio
bframe QUANT offset?

if you use 150/100, your bframes in first pass will have quant 4:

(((2+2)/2) * 1.5) + 1 = ((4/2) * 1.5) +1 = 2*1.5+1 = 4

If you use lumi masking, your frames sometimes will have quant 3 as well.

They get "cosmetically" set to 2 in vfw and reported that way.

I hope this is the answer you needed to know.

Regards
Koepi

colasonic
1st December 2002, 09:10
Originally posted by Koepi
well, now GUESS why it says:

bframe QUANT ratio
bframe QUANT offset?

if you use 150/100, your bframes in first pass will have quant 4:

(((2+2)/2) * 1.5) + 1 = ((4/2) * 1.5) +1 = 2*1.5+1 = 4

If you use lumi masking, your frames sometimes will have quant 3 as well.

They get "cosmetically" set to 2 in vfw and reported that way.

I hope this is the answer you needed to know.

Regards
Koepi

:Dthank you for your answer. But I don't fully understand your equation. I guess if I set BF to 100-0, then the quan no. of BF in first pass should be: ((2+2)/2) * 1 + 0 = 2
Is that correct?

Umm, sounds like I am attending a primary school class....

Koepi
1st December 2002, 09:39
Correct interpretation of the formula :)

Regards
Koepi

colasonic
1st December 2002, 19:51
Ok, I just took another 1pass encode and this time I set BF to 4-100-0. The final size is about 1% bigger than the normal one (75102KB vs. 74237KB).

Thanks to Koepi for your explanation. and also thank all guys in this thread.