Repeated 'Broken B-Frame's with high 'maximum B-Frames' setting

[dubious buccaneer]

----- mandatory info begins -----

XVid version: Nic 2003-07-16
DShow filter: 'XVid MPEG-4 Video Decoder', both de-blocking options not checked
How many encodes: the first one I tried using a high B-Frame setting, and I don't intend to spend more days doing worthless encoding...
Media Player: GraphEdit ; also tried MS Media Player 6.4
System: AMD Athlon XP 1600+, Inno3d Tornado GeForce 2 400-MX, MS Win XP Pro
Encode options: 2-pass, motion search 6, quant type modulated, VHQ 2, max b-frames 300, b-frame quant ratio 150%, b-frame quant offset 100, lumi masking, chroma motion, global motion compensation, quantizer restrictions default, two pass defaults (pay with bias), no alt curve, grayscale end credits sequence, performance automatically detect, 2nd pass type '2nd pass Int.'
AVISynth Script: looks fine, using Crop, Telecide, Decimate, LanczosResize to 592x332
Container Format: AVI with no sound

------ mandatory info ends ------


The important setting is 'Maximum B-Frames' 300. I set it to 300 since the I-frame interval is 300, and I was thinking of letting the encoder decide without limitations which frames it wanted to be B-Frames and which not. Well, the result does not look too horrible, except for one apparent problem: every few seconds I get a 'Broken B-Frame' message on my video, meaning either there really are broken frames or the decoder doesn't handle them properly.

So is this an XVid bug or have I done something wrong? And what is the maximum 'Maximum B-Frames' guaranteed not to cause this?

[BoNz1]

Yikes, 300 b-frames, wow. Set it down to like 2 or 1 the i-frames is different. If I-frames setting is 300 that means you get a i frame every 300 frames guaranteed. But the b-frames setting is how many b-frames you have in a row. Trust me you don't want 300 in a row, thats overdoing it just a bit. Use 1 or 2. And encode a small clip just to see if you like it.

[dubious buccaneer]

Originally posted by BoNz1
But the b-frames setting is how many b-frames you have in a row. Trust me you don't want 300 in a row, thats overdoing it just a bit.
Unless I am mistaken, that setting is supposed to be a _limiter_, i.e. not the number of B-Frames in _every_ B-Frame sequence but rather the _maximum_ number of B-Frames in such a sequence. Thus setting it to 300 should not even mean there has to be any B-Frames at all in the clip, it should just mean I'm not forcing the decoder to cut off such sequences at 1 or 2 or 3.

But of course I could be wrong.

[BoNz1]

Yes, you are wrong. No probably it didn't use 300 in a row but I bet it used way too many and overloaded the buffer or something. Please just use sane values like 1 or 2. And read the stickies especially the one entitled newbie setties it will help a lot so you can get the best out of your encode.

[JimiK]

You're right, the encoder won't set too many, still it's a good idea too set max b-frames to 2-3 (best 'performance' in tests. I like 3). Your problem may be modulated quant type. You should not use it. Besides that, you could try a vertical resolution of 336. A resolution dividable by 16 is best, yours is dividable by 4. But that does not have anything to do with your problem.
Best regards,
JimiK

[BoNz1]

Wups, didn't see that either, just the b-frames setting jumped out at me. I still can't believe anyone would set it that high, wow. A couple other things, don't use luma masking it is broken and don't use gmc there is no benefit to using gmc in this build. And do like JimiK said don't use modulated quants especially not with b-frames and use a res dividable by 16.

[dubious buccaneer]

Ok, advice taken on the issue of GMC, quantization and lumi masking. But I still don't understand why the encoder uses 'too many' B-Frames; isn't it supposed to choose using a B-Frame when it is an improvement over using a P-Frame? And if so, why would quality decrease by not limiting the choice? And, regardless of whether it's a 'good idea' or not, why would _any_ setting cause 'Broken B-Frame's? Isn't that a bug?

[Koepi]

bframes and modulated quant are _absolutely_ incompatible. modulated quantization isn't mpeg4-compliant, it will be wiped out totally in xvid-1.0 (dev-api-4).

More than 3 bframes in a row tend to look very bad. limit it to 3. (And there you already get some "noisy degradation" when 3 in a row are used). If you want to have really small credits you can use higher settings, higher quants and a higher threshold - but do them separately then.

Recommanded bframe settings are more like an offset of 75. It'll give you the "old" behaviour back, i.e. you can compress a movie up to 2x (1st pass vs. 2nd pass size) with pleasant results. With those defaults it starts looking ugly already at ~1.5x...

Hope this helps
Koepi

[Didée]

Originally posted by Koepi
Recommanded bframe settings are more like an offset of 75. It'll give you the "old" behaviour back, i.e. you can compress a movie up to 2x (1st pass vs. 2nd pass size) with pleasant results. With those defaults it starts looking ugly already at ~1.5x...
Some thoughts on this, Koepi.

I know the offset of 75 is recommended by you for quite some time now. And you already stated earlier that the "1st/2nd ratio--with-good-quality" raises from ~1.5 to ~2.0, as a rule of thumb.
Now:

1. This is correct.
2. That means nothing.

The wrong point lies there:
- With 150/100, the first pass is done with B-frames at quant 4.
- With 150/75, the first pass is done with B-frames at quant 3.

For this reason, a 1st-pass with offset=75 gets *noticeably bigger* than a 1st-pass with offset=100. In other words, your (correct) statement of achieving higher compression means not really higher compression, since only the comparator was raised.

On the quantizer side:

P-quant Offset 100 Offset 75
2 4 3
3 5 5
4 7 6
5 8 8
6 10 9
If the encode will end up with an average P-frame-quant < 2.5, then your settings will produce higher quality in the parts with P-quants of 2. But in most cases, we're aiming for higher compression and don't have so much quant2-sequences.

If the encode will end up with an average P-frame-quant > 3.5~4, the parts with high quantizers will look a little better compared to 'offset 100', because 'offset 75' will give a little smaller quants. But this only gets important in quantizer ranges that IMHO should be avoided anyway.

My personal bottomline:

- For the majority of all encodes: 100/200, and that's just it. :)
- For some PITA jobs (music videos, sometimes): 100/300 (/w fixed quant, then)
- For easy-to-compress stuff, or 2CD encodes: 150/75 ;)

Everything above is just IMHO.

- Didée

[Koepi]

Didee,

I suggest those values because many people, me included, expect some behaviour of a video codec. And this 2:1 ratio is a part of it ;)

You're correct of course when stating that the first pass size will increase (not by as much as you'd expect I must add).
the 2nd pass will behave a little different then depending on your average quantizer value. At least that's what my tests did show. (I really dislike blocks like i can see them with quant offset >=100, they're not as bad with offset 75 IMO)

Regards
Koepi

[MfA]

Originally posted by Koepi
bframes and modulated quant are _absolutely_ incompatible. modulated quantization isn't mpeg4-compliant, it will be wiped out totally in xvid-1.0 (dev-api-4).

Maybe it will, maybe it wont ... as long as they keep RRV in there I see no reason not to support VOL headers for every frame including b-frames.