Getting 0wned by overflow

[OUTPinged_]

Yesterday my encode got 0wned by overflow. Basically it was getting too high quantizer values (going up to 17 with average at 4 and pretty strict alt.cc settings that shouldnt be allowing to jump over 10) at second pass so i begun looking at why does that happen. Switching to default settings (bitrate excluding) didn't help it. Duh.

For some reason the resulting framesize wasnt anywhere close to "scaled" in debug, and overhead of about -20 to -30 kbytes was appearing at "large frame" portions of the video. It wouldnt be anything special but for some strange reason codec wanted to compensate them right now and at once. So overhead was scaling to low positives too fast, producing quantizers that had little relation to CC settings.

Bad.

Settings: XviD-14052003-1 by Koepi (latest and greatest,:-/ ), encoding with no qpel/bframes/gmc, alt.cc is off(so that "no-alt.cc" dudes could check that too). h263, me=6, vhq=0, chroma_opt and trellis are off. CC settings: high=0, low=0, payback=250(default), bonus=proportional.

Now we are supposed to get encode with quantizers pretty close to average, right? Wrong! Look at debug:


[1012] 2nd-pass: quant:6 H.263 inter stats1:5542 scaled:2612 actual:1974 overflow:-8390 movie
[1012] 2nd-pass: quant:5 H.263 inter stats1:5463 scaled:2575 actual:2947 overflow:-8809 movie
[1012] 2nd-pass: quant:3 H.263 intra stats1:64289 scaled:40313 actual:51756 overflow:-8885 movie
[1012] 2nd-pass: quant:2 H.263 inter stats1:169 scaled:161 actual:2699 overflow:-11689 movie
[1012] P-frame quantizer prevented from rising too steeply
[1012] 2nd-pass: quant:4 H.263 inter stats1:55181 scaled:26016 actual:36329 overflow:-22268 movie
[1012] P-frame quantizer prevented from rising too steeply
[1012] 2nd-pass: quant:6 H.263 inter stats1:52059 scaled:24545 actual:20493 overflow:-18482 movie
[1012] 2nd-pass: quant:8 H.263 inter stats1:50403 scaled:23764 actual:16224 overflow:-11208 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:49303 scaled:23245 actual:22972 overflow:-11201 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:52980 scaled:24979 actual:20200 overflow:-6688 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:63462 scaled:29920 actual:26250 overflow:-3284 movie


Looks wierd. Here we can see quant4 frame deviating 28% from "scaled" size and quant8 frame that gets hit by overflow too much, too.

2-8 range with 0/0 cc :/ It only gets worse if i bump up cc settings. Increasing payback interval didnt help things a tiny bit. Only by decreasing "maximum overflow improvement/degradation" values to 10, i get a more tolerable behaviour.

like this


[1012] 2nd-pass: quant:4 H.263 inter stats1:64259 scaled:30296 actual:38736 overflow:-153598 movie
[1012] 2nd-pass: quant:4 H.263 inter stats1:79938 scaled:37688 actual:50226 overflow:-166381 movie
[1012] 2nd-pass: quant:4 H.263 inter stats1:75400 scaled:35549 actual:44537 overflow:-175614 movie
[1012] 2nd-pass: quant:5 H.263 inter stats1:73478 scaled:34642 actual:37420 overflow:-178637 movie
[1012] 2nd-pass: quant:4 H.263 inter stats1:60487 scaled:28518 actual:37141 overflow:-187505 movie


Why does "actual" framesize differ from "scaled" that much? why are frames being hit by overflow that hard? in "quant8 frame" case it was 22kb to compensate over 250 frames - less than 100bytes/frame. That shouldnt even have shifted quantizer by 1 only due to overflow. Why does this happen? Could it be that rate control got messed up? Maybe overflow control is?

[Koepi]

What happens if you use payback with bias? it should help the small frame - overflow quite bit.

And to why scaled and actual differ: maybe three's too much detail in the pictures so that with the average quantizer the scaled size isn't reachable.

If dev-api-4 hits the road i'll play around with ratecontrol again to see if there's something we can do about that.

Regards
Koepi

[OUTPinged_]

[1012] 2nd-pass: quant:6 H.263 inter stats1:5542 scaled:2612 actual:1974 overflow:-8390 movie
[1012] 2nd-pass: quant:5 H.263 inter stats1:5463 scaled:2575 actual:2947 overflow:-8809 movie
[1012] 2nd-pass: quant:3 H.263 intra stats1:64289 scaled:40310 actual:51756 overflow:-8885 movie
[1012] 2nd-pass: quant:2 H.263 inter stats1:169 scaled:161 actual:2699 overflow:-11689 movie
[1012] P-frame quantizer prevented from rising too steeply
[1012] 2nd-pass: quant:4 H.263 inter stats1:55181 scaled:26014 actual:36329 overflow:-22270 movie
[1012] P-frame quantizer prevented from rising too steeply
[1012] 2nd-pass: quant:6 H.263 inter stats1:52059 scaled:24543 actual:20493 overflow:-18486 movie
[1012] 2nd-pass: quant:8 H.263 inter stats1:50403 scaled:23762 actual:16224 overflow:-11214 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:49303 scaled:23243 actual:22972 overflow:-11209 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:52980 scaled:24977 actual:20200 overflow:-6698 movie
[1012] 2nd-pass: quant:6 H.263 inter stats1:63462 scaled:29918 actual:26250 overflow:-3296 movie


Nothing changes :/

Same settings, biased payback. Could anything be done to current payback algorithm so that it wouldnt affect frames _that_ badly at default settings?

And video material is not noisy and doesnt have any small details.

Could anyone please do a second pass for any movie you have first pass for, keeping settings same as mine and see if it would perform bad (quantizers would deviate more than 1-2 from average)?

[sysKin]

I had the same problem with two movies I encoded :/
The first time, I re-did second pass with quantizers capped to average +/- 1 (which was 3 - 5).
That's pretty weird concidering that I was always against capping ;)

Anyway, the second time I changed to 'payback with bias' and it looked ok - I say 'looked' because I still had quantizers capped. However, The movie seems to be encoded mostly at Q4 so it wasn't hitting the limits too hard.

I hope dev-api-4's RC will have it fixed :)

Radek

[OUTPinged_]

The more i look into it, the more i think something is wrong with "payback delay" setting, or what it was called in xvid. :-)

It acts like being capped to some really low value, like 5 or 10 frames, and not reacting at changes i do to it.

Can any developer guy take a peek at it?

OT: Are there girls in xvid devel team? ;-)

[Foxer]

I currently have it reporting scaled bytes as the value prior to applying any overflow influence.

-h and I decided upon including maximum overflow improvement/degradation for those who wanted to modify how great an influence overflow can have on the desired framesize.

Then there is of course the distributed keyframe overflow.

I'm sorry if the encoding results aren't to your satisfaction but there is little I can do with this rate control that'll help situations such as this..

[OUTPinged_]

Foxer, you probably got it a bit wrong.

Max overflow impr/degr. settings were not guilty, they just helped to make a "ugly fix" for it. The thing that worries me is that xvid at default settings (60/60 for max_overfl_impr/deg) behaves suboptimal.

[Prettz]

On a side note, if you try to enter values greater than 80 for max overflow improvement/degradation, the codec will set them back to 80. Why is that?

[Foxer]

@OUTPinged_:
It was due to how much of the overflow's influence was permitted by the max improvement/degradation..

I mentioned max improvement/degradation and distributed keyframe overflow because they work with the overflow.

If you believe those values to be suboptimal, then by all means, suggest a few sets which you believe may produce better results and let people scrutinize their affects in their encodes.

If there is a consensus on which values are better, the defaults will most likely be changed accordingly.

@Prettz:
Anything beyond 80% degradation is simply too much possible influence overflow can have on the chosen quantizer. 80% could bring desired quant2 down to quant10 whereas 60% could bring desired quant2 down to quant5.

I chose to limit the improvement to limit how much underflow can be taken as to not immediately throw it all away when it's in abundance(rare).. 80% could bring say desired quant10 up to between quant 5 and 6.

[Prettz]

Originally posted by Foxer

@Prettz:
Anything beyond 80% degradation is simply too much possible influence overflow can have on the chosen quantizer. 80% could bring desired quant2 down to quant10 whereas 60% could bring desired quant2 down to quant5.

I chose to limit the improvement to limit how much underflow can be taken as to not immediately throw it all away when it's in abundance(rare).. 80% could bring say desired quant10 up to between quant 5 and 6.
I was always wondering because when I started experimenting again with xvid a few months ago, raising the two settings higher seemed to make a noticeable effect on quality, so I wanted to keep raising them to see what happened. Right now, with both at 80%, the first part for a 2 cd encode is getting only 38 p-frames at quant 3, everything else at quant 2 (I'm pretty pleased with this).

[OUTPinged_]

@Foxer:

Overflow shouldnt have influenced stuff that much. After codec applies curve compression (which i have carefully set up and believe, is best to use in that case), it has "ideal" second pass curve. Because rate control in xvid is not hitting target framesize (+/- 30%, duh) nowadays, good overflow algo will compensate deviations so that:

1. All framesizes will be as close to their "ideal" sizes.
2. There will be as little accumulated deviation as possible

While second is very true in latest xvid build, first is not. A pity. :/

Proper fixes:
1. (sufficient) make "payback delay" option do what it should.
2. (best one) fix the rate control
3. (ugly) change default overflow impr/deg to 30s.

Those fixes will allow to make encodes look as they are supposed to. It is silly to have excellent compression engine and broken curve scaling.

[Didée]

Well, I have been unsure about curve compression since B-frames came up.

Lets stay simple, and consider normal curve compression.
When starting a 2nd-pass, XviD spits out the "middle frame size for asymetric curve compression".

Now, a typical scenario would be something like that:
- average size of P-frames: 10000
- average size of B-frames: 2000
- middle frame size for cc: 4000

(Phantom numbers, but you get the idea)

Without knowing the inner circles of the CC algorithms, one could suspect that all P-frames are consider as "above average" and get squeezed. This would be no good, of course.

And, while I'm making a fool of me anyway:
In DebugView, it looks like B-frames would get scaled the same way as P-frames, where in fact they do get scaled acc. to the pre-/proceeding P-frames.

Any comments on that stuff?

All answers are in the sources of XviD, I know. But you could give me as well some documents in traditional chinese ...

:confused:
Didée

[Koepi]

The problem with dev-api-3/cvs head/my current build is (already fixed in dev-api-4/future xvid1.0):

bframes get sclaed within core, while p and iframes get scaled from vfw.

So foxer added a third compression curve for bframes as well, where the values are more or less _guessed_ (and for that we don't know much about them within vfw the values are really, really good). Before foxer was so kind to add that, the rate control with bframes really was a pure mess, unusable (still some people tried it).

As you all should know as of now, bframe quant gets calculated (_in core, not vfw_) by the formula you setup in vfw: bframe quant= ([pframe quant before the bframe]+[pframe quant after the bframe]) * bframe quant ratio + offset.

Now this is no real problem, taken for this alone.

But since the 2nd pass has no frame-type control when bframes are used (dynamic ipb-decision) the frame-types may differ between first and second pass in some places. this is where the bitrate curve gets "artificially" distorted and the rate control has to do something - usually unnoticable in the final result, but in some cases it's really bad.

As you can see Outpinged_, the curve compression isn't really broken. It's the 2nd pass frame type control which does cause these problems.

This is a limit / problem we have to live with until dev-api-4 gets in usable state (IMO it is already, but i didn't find the time to look at it. Also the main core devs don't want dev-api-4 to hit the road now.)

Koepi

[OUTPinged_]

Then i will stop looking into that until dev-api-4 will surface.

Until it will be released, i'd recommend everyone to reduce max overflow improvement and degradation settings to 20-30 when encoding 10+ minute clips in 2 pass with no quantizer capping.