encoding artifce - vibrating blocks

[nicco]

I have to encode a movie with a still image of a map with a red path.
I use divx5.1.1.
If I encode it with 2-pass in standard mode everything looks ok, but if I encode 1stpass-standard, 2ndpass-slow or slowest (it should be better!) some parts of the image (like blocks or couple of bloks)appear to vibrate up&down!
Why does it happen? Maybe becouse I use b-frames at a bit-rate of 900kbps?
Please help me!

[nicco]

This problem really seems to be linked to b-frames, I do the following tests:
900kbps - 2pass@standard - bframes --> no vibrating blokcs
1100- 2pass@standard - bframes --> no vibrating blokcs
900kbps - 2pass@slow - bframes --> vibrating blokcs
900kbps - 2pass@1st_standard,2nd_slow(-est) - bframes --> vibrating blokcs
1100kbps - 2pass@1st_standard,2nd_slow(-est) - bframes --> vibrating blokcs
900kbps - 2pass@1st_standard,2nd_slow(-est) - NO_bframes --> no vibrating blokcs


Can it be possible?
It's very strange, b-frames did never get me problem , I always use them.Maybe this artifice is not visible in motion scenes...
So I have two new questions:
1)what does the 2nd pass in slow mode do?
- it reduces filesize
- it improves the quality (not in my case!)
2)If I can not do the 2nd pass in slow mode (becouse of the vibrating blocks) what should I do?
- 2 pass standard with b-frames
- 2 pass standard-slow without b-frames

[nicco]

Baybe I found the solution!
This problem seems no to appear if I use scene change threshold to 97% (i think it means quantizer=2): I can do:
900kbps - 2pass@1st-standard, 2nd-slow bframesYES - scene change threshold 97% --> no vibrating blokcs!
Can someone explain me?
I really don't know what scene change threshold affects in encoding movie.

If someone would like to watch these short clips (bad and good)to better understand what is my problem I can mail them:)

[CiNcH]

Has nothing to do with encoding at a fixed quantizer.

The scene change threshold defines the minimal percentage of intra-blocks that are required for a frame to become an I-frame.
If more than 97% of the total number of blocks in a frame are I-blocks the frame becomes an I-frame (otherwise it is predicted). Such a high percentage means that there won't be many I-frames in your encoded video except keyframes.
AFAIK, the scene change threshold is not respected in Slow P/Q as the Rate-Distortion algorithm makes the scene change decisions.

[nicco]

sorry for quantize mistake,but why a so high scene change threshold value eliminates my problem, even if it's not considered in 2nd-pass@slow mode?

[stephanV]

Originally posted by CiNcH
Has nothing to do with encoding at a fixed quantizer.

The scene change threshold defines the minimal percentage of intra-blocks that are required for a frame to become an I-frame.
If more than 97% of the total number of blocks in a frame are I-blocks the frame becomes an I-frame (otherwise it is predicted). Such a high percentage means that there won't be many I-frames in your encoded video except keyframes.

I-frame is just another name for keyframe right?


AFAIK, the scene change threshold is not respected in Slow P/Q as the Rate-Distortion algorithm makes the scene change decisions.
nicco does first pass in standard mode, so in the first pass scenechange-treshhold should still be used... (just guessing here)

anyway, according to him it does make a difference so there must be something

[CiNcH]

I-frame is just another name for keyframe right?

Yes, I just referred to the forced I-frames that are inserted after xxx predicted frames (max keyframe interval).

[nicco]

I must correct myself, i did some (much) new tests and the good result I had with scene change thr to 97 was no more achieved, maybe I did a NO-bframes encoding thinking b-frames were on.
but...
finally I think I really solved the problem: this artifice occurs when I use both b-frames and... Psycovisual enhancement!!!!
Vibrating blocks don't appear if I disable psv (but enable b-frames)!