xvid blockiness help

[cdrips]

I did an ecnode of American History X 2CD. Overall it looks really good almost like the dvd. Anyway, I noticed in some parts it gets really blocky such as when the camera pans. Is there anyway to lessen this blockiness? Where do these blocks come from in the codec? I also had a question about p-frame and i-frame quants. I tried to search for explanations of them. I found one in the divx5 forums. But didn't quite understand. When you cap these what happens? Is there an explanation in the forums about payback delay? I shall search for that next, but if anyone can explain. I know in divx3 it's used so bits can be taken b/c of high motion scenes? In xvid though, it's a much higher number than divx3. Any explanation?

[Dali Lama]

Ok, I'll do my best to answer these questions:

1. Blockiness in fades, pans, etc. is a common problem with encoding in any format. Divx5 has an option called GMC, which tries to predict these fades or pans, scrolls, and account for the common areas of adjustment. Basically, its trying to save bits in making a prediction of how the video will behave. I believe it is no safe to use this option without wierd side effects (note I achieved a weird shifted pixel problem with this option in the earlier versions of Divx5).

2. Higher Quantization Number = Worse Visual Quality = Smaller File Size

Therefore, if you choose to limit the quantization, you don't give the codec the option of displaying ugly frames OR saving space. It is a little bit of an art form to so called "cap quants."

Here are some numbers to play around with:

I = 2-8, 2-6, or 2-4
P = 2-16, 2-12, or 2-8

I like to cap my I frames at half the value of my P frames. Why? Because I frames are the basis by which P frames will refer to. Basically, an ugly I frame, which is inserted at Scene Changes in Xvid will cause that whole scene to degrade in quality, because the P frames are referencing that frame. Only until the next scene might a lower quant I frame be used and a better quality achieved.

3. Payback delay in Xvid is pretty much the same thing as it is in Nandub. Its an alloted time frame for the codec to choose how to distribute its bits. A longer time allows long action scenes to get their deserved bits, as you pointed out. The difference that you noticed is that in Nandub, the payback delay is in seconds, while in Xvid its measured in frames. Simple, right? So just multiply a reasonable value like 45-120s by the frame right of your source.

45s x 24fps = 120 frames in payback delay

I hope you understood everything and sorry for such a late reply.

Good luck,

Dali

[-h]

I like to cap my I frames at half the value of my P frames. Why? Because I frames are the basis by which P frames will refer to. Basically, an ugly I frame, which is inserted at Scene Changes in Xvid will cause that whole scene to degrade in quality, because the P frames are referencing that frame. Only until the next scene might a lower quant I frame be used and a better quality achieved.

The only frame that references the I-frame is the P-frame immediately following it. P-frames reference only that frame that came immediately before it, be that frame an I-frame or a P-frame.

A highly-quantized and ugly I-frame at a scene change will require more bits in the following P-frames to "correct" it. A less-quantized I-frame will require fewer bits to be spent correcting it in the following P-frames, but will of course take more bits to initially store. It's a balancing act really, and it's a subjective question as to which method is best. The human eye typically can't notice details as soon as they appear, so it is often better to exploit this by allowing I-frames at scene-changes to be more heavily quantized.

-h

[cdrips]

thanks for the explanations, i shall try and experiment now.

[Dali Lama]

Originally posted by -h
The human eye typically can't notice details as soon as they appear, so it is often better to exploit this by allowing I-frames at scene-changes to be more heavily quantized.


That's interesting -h. I learn something new everyday. So you are saying something like:

I = 2-16
P = 2-8

is good?

I will try to investigate a little,

Dali

[-h]

That's interesting -h. I learn something new everyday. So you are saying something like:

I have no idea, I've never really used XviD to encode a video that I'd watch afterwards (!).

-h

[Koepi]

IFrames start looking ugly (when looked at as still picture) with quant=4.

I suggest for "best" quality you set iframe boost to 0, cap quantizers for i: 2-5 (in hard to compress cases from 2-6) and leave pframe quantizers as-is (2-31). With StatsReader scaled curve (see that thread) you don't run into trouble with minsize frames getting "downscaled" and stack up overflow which degrades the frames following such a sequence.

Hm. I didn't intend to hijack this thread or advertise statsreader... I should try to find the real formula for minsized frames (macroblocks/9.4 + 24 bytes avi-frame overhead just works for 640x272, other resolutions [macroblock counters] are closely approximated by it, but still some bytes off]) and hack that into 2pass.c of xvid.

Regards,
Koepi

[-h]

Hm. I didn't intend to hijack this thread or advertise statsreader... I should try to find the real formula for minsized frames (macroblocks/9.4 + 24 bytes avi-frame overhead just works for 640x272, other resolutions [macroblock counters] are closely approximated by it, but still some bytes off]) and hack that into 2pass.c of xvid.

I was thinking about the email you sent about that, it's got me very confused. You say that the frame size XviD reports for a null 640x272 frame is 115 bytes? But for 640x352 it's 118?

All I can figure is that it'll be 1 bit per macroblock plus the VOP header, which (just by a quick guess from the source code) would average out to be 15 bytes, and finally 4 or 5 bytes of stuffing (after alignment). That would give ((640/16)*(272/16)/8)+15+5 = 105 bytes for a frame containing nothing but skipped macroblocks.

I'll step through the source and see if I can find a more accurate number though. One problem is that there are a few entries in the VOP header which are of variable bit length, and in certain circumstances the number of bytes used per frame would have a +- 1 or 2 byte range.

-h

[Koepi]

Heh, I'm going to make a table with different MB counts / min frame sizes.

For 640x272 (680 MBs) the size is 96 bytes.
For 640x352 (880 MBs) the size is 118 bytes.

1 bit per MV doesn't fit here as I'm pretty sure that avi frame overhead (24bytes) is already included there, and for 880MBs 1bit/MB would sum up to 110bytes :-(

It's all real weird, but I have to confirm the value for 880MBs first, I think I saw different min sizes for that (?!).

Thanks for the help :)

Best regards,
Koepi

EDIT:Resolution | MBs | Minsize frame bytes
-----------+-----+---------------------
320x240 | 300 | 48 (kf: 855 bytes)
352x288 | 396 | 60 (kf: 1119 bytes)
480x576 |1080 | 146 (kf: 3000 bytes)
640x272 | 680 | 96 (kf: 1900 bytes)
640x352 | 880 | 121 (kf: 2450 bytes)
720x576 |1620 | 213 (kf: 4485 bytes)
All tests done at 1pass const. quant. 1, pure black image sequence.

[cdrips]

I've been following the statsreader thread for a while. I was wondering, is it still the same as the internal for xvid or has it changed now in which it will be an improvement to the internal.

Edit: Oops, sorry didn't see the last two posts on that thread. Ok, so if statsreader adds an improvement, maybe I shouldn't mess with capping quants? I should just use StatsReader?