greyscale mystery

[kassandro]

Can somebody help me to explain the following strange phenomenon. Input is an avisynth script with about 1500 frames originating from a black&white, progressive mpeg2 file. If I encode this script with xvid-beta3 and with the xvid-greyscale option enabled then the size of the output file is 7983 kb. If in addition I insert the builtin filter greyscale() at the end of the script and change nothing else, then very surprisingly the size of the output climbs to 8021 kb. Thus removing the chroma noise increases the file size. This is really hard to believe. Now if a disable xvid-greyscale but leave the greyscale filter in the script, then the size increases only very slightly to 8023 kb.
The conclusion of this experiment: xvid needs chroma noise to decrease output size with the xvid-greyscale option. What is going on here?

[sh0dan]

Maybe the missing noise could cause some other I-P-B-frame decisions to be made. I don't know if chroma is included in these decisions, though.
I guess one or two more B-frames could give this difference.

[Mug Funky]

was "chroma motion" turned on in the first encode? not sure what that'd do, but it's something to consider :)

[kassandro]

Originally posted by Mug Funky
was "chroma motion" turned on in the first encode? not sure what that'd do, but it's something to consider :)
Probably not, but I'm not absolutely sure. I have used one zone with a fixed quantizer 5 and with bframes turned on. Thus a normal one pass quality vbr. What does the xvid greyscale option anyway. It doesn't seem to do the obvious, namely setting both chroma planes to 128.

[Danzel]

Im just guessing here, but it could be that the xvid greyscale and the avisynth grayscale options work in different ways, perhaps the avisynth one blends all the colors to make new chroma info, while xvid just drops everything except chroma, although that still wouldnt explain all the strange filesize differences..

Did you have chroma optimizer enabled? I think that this caused some troubles / inconsistencies with b/w encodes in the old dev-api3 days. (IIRC)

A strange result indeed....

Danzel.

[m0rtal]

Originally posted by Danzel
Did you have chroma optimizer enabled? I think that this caused some troubles / inconsistencies with b/w encodes in the old dev-api3 days.
same applies to dev-api4 :(

[kassandro]

Fortunately I still have Vdub configuration file. Loading it, I can recall the options used. Besides the greyscale option the following options were used: Turbo (should be useless for 1 pass vbr mode), Trellis quantization, Motion search precision = 6, VHQ mode = 3, I-Frame intervall= 500, adaptive Quantization, quantization type = H.263, max consecutive BVOPs = 4, BVOP quant ratio=1.5, packed bitstream, closed gov, BVOP sensitivity = 4. Neither the charoma optimizer nor the chroma motion option were used.
I will repeat this test with my next b&w clip.

[RadicalEd]

Turbo is useful as long as you're encoding with bframes or qpel. I think you might be confusing it with fast first pass.

[jon.schaffer]

Hi,

I got a question:
- what Target Bitrate or Target Fila Size did you use?
- was the final bitrate near the Target Bitrate?

If you used a high bitrate (>1500 kbps, maybe even less) and that the final size was oversized. I would say it is related to an overflow problem: when too much quantizer=1-frames are produced, the Rate Control gets crazy... As you say that adding Greyscale() raise the final file size and that removing chroma-noise does too, I think that these two actions lead to produce even more quantizer=1-frames, which amplify the Rate Control error.

If it is this problem, try setting the minimum quantizer at 2 for every frame-type (let 31 as max.)

Jon

[Pen-Pen]

Originally posted by Danzel
Im just guessing here, but it could be that the xvid greyscale and the avisynth grayscale options work in different ways, perhaps the avisynth one blends all the colors to make new chroma info, while xvid just drops everything except chroma, although that still wouldnt explain all the strange filesize differences..


I think they both discard all chroma information... but there are lots of people out here that know that better than I do ;)

[lordadmira]

Well the Xvid grayscale option just compensates forward the chroma planes. Theoretically this shouldn't lead to dramatic size savings. However the scenario that Heir Schaffer put forward seems likely. The grayscale could have increased the compressibility enough that the codec had to start using too many quants 1's & 2's thereby throwing the encode into rate control anarchy. What was ur minimum quantizer? It should be 2. The size savings of each higher quantizer is not linear. Meaning that each successive quant number yeilds progressivly smaller savings. And conversely, lower quantizers yeild progressivly larger frames. I.e. the size diff from Q=1 -> Q=2 is much greater that Q=10 -> Q=11, etc. It's like the Warp Scale. Going from warp 8 to 9 is a dramatically bigger speed jump than going from warp 1 to 2. :D

LA