B-frames

[MadScientist]

hello Xvid users, i am a little nervous as this is my first post in a forum. I have been using DivX5.0x and SBC for some time now and this idea of using b-frames has been implimented into the DivX5.0x
I have moved over and geting my gip on the Xvid codec, i love being able to change as much parameters and fully understand what i am doing. I have looked all over this Xvid part of the forum to find no one has asked how to use B-frames & i have not found any documantation. I hope this is not a repeated question coz i would look so uncool right now :(

Q. how can i impliment B-frames (using Koepi's latest dev codec)(XviD-08032003) into an encode and what how is this bug with I frames avoided.

if any one can explain or even post links to other places you will have my full gratitude :)

thank you for lissening

[cipher]

Under "global" tap in the "Xvid Configuration" windows, you may see
"Maximum B-frames", "B-frame quantizer ratio", "B-frame quantizer offset" and "B-frame threshold" in the "B-frame control" section. Now here are the tricks:

"Maximum B-frames": refers to the maximum number of adjacent b-frames allowed when encoding. You probably know, coz u said you were using divx 5 for a while, that the maximum b-f allowed using divx 5 is 1, here in xvid you can choose whatever number you like, but it is recommended that the number be no more than 4. setting it to a negative number disables this function as well as the following ones.

"b-frame quantizer ratio" & "b-frame quantizer offset": control the quantizers of b-frames using this equation:
B-f Quant. = ((past frame Quant. + future frame Quant.)/2*Quant. Ratio + Quant. Offset)/100, where past and future frames can be either p-frames or I-frames, but not b-frames since b-frames cannot be referenced.
For these three parameters, my favorite is: 3,100,1. However, it really depends.

"B-frame threashol" is a brandnew parameter i'm not familiar with, you may want to refer to this thread (http://forum.doom9.org/showthread.php?s=&threadid=48199) ,as i remember sysKin posted some explainations there.

make sure you check(as is default) the "DX 50 bvop compatability".

by the way, this is probably not the first thread talking about b-frame setting ;). iago has wriiten a walkthrough for xvid internal 2 pass settings, though it was for a previously released version, but the config. for b-frame were pretty much the same, you can download it from http://nic.dnsalias.com/XviD/xvid-two-pass.zip

enjoy!

[Garfield]

That's certainly the shortest and most comprehensive answer on b-frames settings i've ever read in this place.

Thank you cipher ;)

[crusty]

Ok, this is difficult stuff for me.

So B-f Quantizer ratio is basically a percentage of the average of the sum of the closest previous non-b-frame (because they can't be referred to) quantizer and the closest next non-b-frame.
(that's the closest I can get to 'basically' unfortunately)

So if the I-frame was Quantizer 3 and the P-frame was Quantizer 5 then the average would be (3+5=8)/2=4.
So if you have a b-f Quantizer ratio of 200 then the B-frame would (in this case) be encoded with an average Quantizer of 8.
So in plain english,
100 will use the same quantizer as the rest of the movie, compressing them exactly the same.
Anything under 100 will give the b-frames a smaller quantizer than the rest of the movie, compressing them LESS than the rest of the movie.
And anything above 100 will give the b-frames a bigger quantizer than the rest of the movie, compressing them more than the rest of the movie.

So three questions:
1- Is this a correct representation? (have to ask this):D
2- Are values under 100 allowed?
3- Why on earth would you want to compress the b-frames LESS than the rest of the movie?

About b-frames quantizer offset:
With an offset of 0, everything said above about b-frame quantizer ratio is true.
But offset adds another standard extra value to the quantizer decision which isn't influenced by the previous I or P frame quantizer.
Any positive value of the offset will increase the quantizer used for the b-frame, thereby increasing compression more.
4- Is this correct?
5- Are negative values possible?
6- Will a lower than standard value of this help against the visible 'I-frame pumping' effect?

From another thread I found this answer about b-frame threshold:
negative value = less bframes than default (does not work yet)
positive value = more bframes than default
So the b-frame threshold will influence the AMOUNT of b-frames in the final movie.
7- Is this correct?
8- Do negative values still don't work or are they fixed now?
9- How does the value actually effect the amount of b-frames, i.e.
a value of 100, would that mean two times the amount of b-frames?
10-Would the use of a large value of 'maximum number of consecutive b-frames' combined with a negative value of b-frame threshold allow for a more 'intelligent' decision on the amount of b-frames, would it break things, or would it simply have no possible theoretically predictable effect?

[duartix]

@cipher:
Your this thread (http://forum.doom9.org/showthread.php?s=&threadid=48199) is not a valid working thread.
Please repost it.

[sysKin]

Originally posted by crusty
So B-f Quantizer ratio is basically a percentage of the average of the sum of the closest previous non-b-frame (because they can't be referred to) quantizer and the closest next non-b-frame.
(that's the closest I can get to 'basically' unfortunately)

So if the I-frame was Quantizer 3 and the P-frame was Quantizer 5 then the average would be (3+5=8)/2=4.
So if you have a b-f Quantizer ratio of 200 then the B-frame would (in this case) be encoded with an average Quantizer of 8.
So in plain english,
100 will use the same quantizer as the rest of the movie, compressing them exactly the same.
Anything under 100 will give the b-frames a smaller quantizer than the rest of the movie, compressing them LESS than the rest of the movie.
And anything above 100 will give the b-frames a bigger quantizer than the rest of the movie, compressing them more than the rest of the movie.

So three questions:
1- Is this a correct representation? (have to ask this):D
2- Are values under 100 allowed?
3- Why on earth would you want to compress the b-frames LESS than the rest of the movie?1. Yes crusty, your interpretation is correct. By the way it should be added that rounding is done up (ie towards higher quants).
2,3. Values under 100 are allowed. However, using the same (or lower) quantizer for B-frames as for P-frames would be even more stupid than using quant 1 ;) Theoretically, the quality would be better, but you would have it even better by not using bframes at all - and the filesize would be better, too.
So using 100/1 is the highest reasonable quant (because of rounding up).About b-frames quantizer offset:
With an offset of 0, everything said above about b-frame quantizer ratio is true.
But offset adds another standard extra value to the quantizer decision which isn't influenced by the previous I or P frame quantizer.
Any positive value of the offset will increase the quantizer used for the b-frame, thereby increasing compression more.
4- Is this correct?
5- Are negative values possible?
6- Will a lower than standard value of this help against the visible 'I-frame pumping' effect?
4. Again, correct. 5. Negative values are possible, but weird ;)
6. No, no settings of b-frames will have anything to do with i-frames...From another thread I found this answer about b-frame threshold:
negative value = less bframes than default (does not work yet)
positive value = more bframes than default
So the b-frame threshold will influence the AMOUNT of b-frames in the final movie.
7- Is this correct?
8- Do negative values still don't work or are they fixed now?
9- How does the value actually effect the amount of b-frames, i.e.
a value of 100, would that mean two times the amount of b-frames?
10-Would the use of a large value of 'maximum number of consecutive b-frames' combined with a negative value of b-frame threshold allow for a more 'intelligent' decision on the amount of b-frames, would it break things, or would it simply have no possible theoretically predictable effect?7. Correct :D
8. I fixed them for Koepi a few days ago, now bug him for a new build ;) (the problem was in gui, it worked for linux all the time)
9. It's easy to predict for negative values: -110 is the theoretical minimum (internal threshold would become negative). About -100 is practical minimum, not allowing any bframes.
As for positive - no, it's not predictable. I'd recommend 10..50..100 if you like bframes. You'd have to limit 'maximum' or you'll really make things look bad. People use 255 here, which almost always means "maximum" - and this maximum of 3 looks very bad, of 2 looks better, of 1 means just divx5. *

10. Negative thresholds will not allow more than 3.. maybe 4 b-frames anyway, so changing the maximum from 4 to 10 will have no effect. However, don't count on the decision to be very smart - hard-coded maximum helps against making stupid errors, so maximum of 3 will never hurt.
As for threshold, I do my best to keep "0" as the "smartest". But you have to check for yourself. I mostly thought about it for its negative values - for example a value of -70 might be great for people who are 'afraid' of bframes, becuase the effect will be completely invisible (filesize difference will be hardly visible too ;D but still there).

Radek

[edit]* Ok a small fix (thanks Koepi for pointing it out): if you're doing low-bitrate rips (1cd maybe?) you might even want to try 255. I still say it's huge, but maybe it's needed. It should also be clear that my experience with dvd-ripping is minimal. :)

[crusty]

Thank you sysKin for verifying this and answering all my questions.
I hope my explanation was simple enough for a lot of people to understand. I know I hate maths...got a 2 on school for it. :D

As of the max consec. number of b-frames, combined with the b-frame treshold:
Would You say that a treshold of 255 is a more 'sane' setting with 2 b-frames than with 3? And that, with 3 b-frames, a lower treshold would be adequate/advisable?

And, if there is no reason whatsoever to EVER use a b-frame quantizer ratio lower than 100, wouldn't it be easier on n00bs to lock this at 100 or higher in the GUI? I mean it won't break anything to use a ratio lower than 100 but it's completely insane to do so, so you might as well prevent this. Koepi, maybe something to implement in the GUI?

About your answer on question 10:
I was thinking more in the range of max 3 to 5 b-frames, combined with a lower than 100 treshold to give a more 'intelligent' max b-frames of about 1 to 3. But if you say that at 0 b-frame treshold is the most intelligent than I'll take your word for it any day. :)

Again, thanks for the reply m8.

BTW: maybe the sticky Xvid Q&A should have a link to this thread.

[sungey]

Originally posted by sysKin
Theoretically, the quality would be better, but you would have it even better by not using bframes at all - and the filesize would be better, too.
So using 100/1 is the highest reasonable quant (because of rounding up).

I just tested using bframe 2/100/1 bframe_threshold=255 (constant quant encoding at quant 2 ) ... i was expecting to see the bframe quant to be 3 because of the rounding up ... but it turns out the bframe quants are 2 ... it rounded down ... am i doing it wrong ?

[crusty]

Either it doesn't round up that perfectly, or using constant quant encoding at quant 2 also forces the b-frames at quant 2.

[Acaila]

2/100/1 bframe_threshold=255My guess it's because you used 1 for B-frame offset instead of 100. In your case this results in a final offset of 0.01, which gives a B-frame a quantizer of 2.01, rounded down to 2 obviously.

[sungey]

Originally posted by Acaila
My guess it's because you used 1 for B-frame offset instead of 100. In your case this results in a final offset of 0.01, which gives a B-frame a quantizer of 2.01, rounded down to 2 obviously.

yes, i know ... from my previous knowledge this settings will give me bframe 2.01 rounded down to 2 ... but just now in this thread ..


Originally posted by sysKin
Theoretically, the quality would be better, but you would have it even better by not using bframes at all - and the filesize would be better, too.
So using 100/1 is the highest reasonable quant (because of rounding up).

1. Yes crusty, your interpretation is correct. By the way it should be added that rounding is done up (ie towards higher quants).


i wonder what does syskin mean by rounding up .. ? if the bframe formula result is rounded up .. why didnt 2.01 is rounded up to 3 ?


From crusty
Either it doesn't round up that perfectly, or using constant quant encoding at quant 2 also forces the b-frames at quant 2.


nope, constant quant 2 encoding doesnt affect the bframe quant directly. Bframe quant is calculated from the formula.

[mf]

Originally posted by sungey
i wonder what does syskin mean by rounding up .. ? if the bframe formula result is rounded up .. why didnt 2.01 is rounded up to 3 ?
Afaik, rounding up != ceiling.
For ceiling:
1.0000000000000001 == 2
For rounding up:
1.0000000000000001 == 1
1.5 == 2

That's what I figured anyway. You never know what to make of x.5, so, you need to either round that up or down.

[Jan Marijniszoon]

Originally posted by cipher
make sure you check(as is default) the "DX 50 bvop compatability".

Why???
It works also perfectly without this option.
It is only to make it compatible with DivX 5 isn't it? That sucks anyway.

Isn't it just better to let b-frames reference to I-frames also?
That is conform mpeg4-standard isn't it?
Maybe I am wrong on this one...can someone with more technical knowledge reply on this one?

Greetings,
Jan.

[kilg0r3]

Originally posted by mf
[B]Afaik, rounding up != ceiling.
For ceiling:
1.0000000000000001 == 2
For rounding up:
1.0000000000000001 == 1
1.5 == 2
Which is why I like to use 2/124/100 for b-frames. just muttering te same line allover again. *giggle*

[symonjfox]

Originally posted by Jan Marijniszoon
Why???
It works also perfectly without this option.
It is only to make it compatible with DivX 5 isn't it? That sucks anyway.

Isn't it just better to let b-frames reference to I-frames also?

It was the first setting i disabled when I switch to Xvid :D
Yes, I always disable it, it works on every player and Direct show filter I tried (3ivX, Xvid, FFDshow) but DivX (I never use it).

[sysKin]

Originally posted by mf
Afaik, rounding up != ceiling.
For ceiling:
1.0000000000000001 == 2
For rounding up:
1.0000000000000001 == 1
1.5 == 2
You're right mf :) but I meant 'ceiling'.
Come to think of it, I have to check it to be 100% sure. But I think it's ceiling. 2.01 is rounded to 3.

Originally posted by Jan Marijniszoon
Isn't it just better to let b-frames reference to I-frames also?
That is conform mpeg4-standard isn't it?
Maybe I am wrong on this one...can someone with more technical knowledge reply on this one? OK people, YOU SHOULD USE "CLOSED GOP" aka "DIVX5 compatibility'. There are two reasons:
1. less important one: you can't cut the bitstream without it (correctly, that is). If you cut, your first part will not have all frames (final b-frames will be missing), and the second part will have them but will not be able to decode them (and you'll even have 'broken b-frame' error).
2. more important one. You'll decrease quality and increase filesize. If the I-frame begins new scene (and it usually does), b-frame before it have no reason to reference from it - it's completely different picture, there is no part which is useful. They will be bigger (b-frames referencing from one picture are much bigger than p-frames) and will have bad quality (same reasons...).

Radek

[sungey]

Originally posted by mf
Afaik, rounding up != ceiling.
For ceiling:
1.0000000000000001 == 2
For rounding up:
1.0000000000000001 == 1
1.5 == 2

That's what I figured anyway. You never know what to make of x.5, so, you need to either round that up or down.

Nope... using bframe 3/100/50 and constant quant 2 encoding give u 100% quant 2 frame ... since the formula yields 2.5 and rounded down to 2.

[Assault]

Originally posted by sysKin
Come to think of it, I have to check it to be 100% sure. But I think it's ceiling. 2.01 is rounded to 3.
Hmm...
I just made a test with constant quantizer 2, b-frames 2,100,199,0 with Koepi's latest build. The b-frames have a quantizer of 3!!! So 3.99 was rounded down to 3. :confused:
I don't know if it helps but I read a discussion about this issue in this thread (http://forum.doom9.org/showthread.php?s=&threadid=49156&perpage=20&highlight=integer%20quantizer&pagenumber=4) some time ago.

Regards
Assault

[Selur]

2. more important one. You'll decrease quality and increase filesize. If the I-frame begins new scene (and it usually does), b-frame before it have no reason to reference from it - it's completely different picture, there is no part which is useful. They will be bigger (b-frames referencing from one picture are much bigger than p-frames) and will have bad quality (same reasons...).

I don't quite get it.
As far as I understood it 'closed gop' just prevents inter-GOP dependencies. So I understand point one, but I don't get point two.

If the next coming I-frames includes no needed data, a bframe shouldn't refer to it no matter if the gop is closed or not. But if it would contain some usefull info, wouldn't that save some and not cost some?

Could someone (maybe syskin ;) ) explain this a bit more?

thx

Cu Selur

[mf]

Originally posted by Selur
I don't quite get it.
As far as I understood it 'closed gop' just prevents inter-GOP dependencies. So I understand point one, but I don't get point two.

If the next coming I-frames includes no needed data, a bframe shouldn't refer to it no matter if the gop is closed or not. But if it would contain some usefull info, wouldn't that save some and not cost some?

Could someone (maybe syskin ;) ) explain this a bit more?

thx

Cu Selur
B-Frames are bigger than P-frames at the same quant, they're just smaller because(if) you do ratio >100.

[Selur]

Okay (I knew that one), but why should the codec create a bframe is it would be better to create a pframe ?

[mf]

Originally posted by Selur
Okay (I knew that one), but why should the codec create a bframe is it would be better to create a pframe ?
Because closed gop was turned off?

[Selur]

Okay, let me sum this up:

if "closed gop" is turned on:
B-frames won't try to refer to the next I-frame, which is good, since we asume the next I-frame never contains any helpful data. So the codec chooses a p-frame instead of a b-frame.

if "closed gop" is turned off:
B-frames will refer to the next I-frame, which is bad, since we asume the next I-frame never contains any helpful data. So with "closed gop" off one will spend a lot datarate on bframes which one refer to one useful frame, which cost more than a pframe (which naturaly refers only to one frame).

Did I get this right?
Shouldn't the codec normaly decide (at least in 2pass) when it's better to use a pframe instead of a bframe?
(so it shouldn't happen that one uses a too big bframe, instead of a pframe)

Or did I mix up something,...?
If B-frames could only refer to I-frames, I might understand it if the codec kind of prefers bframes in general,.. but as far as I remember bframes are allowed to refer to bframes and pframes and one allways has to decide if it's better to refer to 2 frames and use a bframe or just refer to one frame and use a pframe,...

Cu Selur

Ps.: damn, I'm quite sure it's just a little bug in my 'system' that confuses me,.. :)

[Teegedeck]

B-frames aren't allowed to refer to other B-frames, only to P-frames.

[Selur]

ups,.. that was a typo ment I- and pframes,...

Cu Selur

[MrBunny]

Originally posted by mf
B-Frames are bigger than P-frames at the same quant, they're just smaller because(if) you do ratio >100.

Am I correct in assuming that this is because b-frames are bidirectional and thus need to keep the motion information from both prev and next frame? And as well that the advantage to using b-frames is that it compresses better than p-frames (higher quality) since there is duplicate information, thus allowing for more accurate results at higher quants?

Edit: Slight clarification

[Selur]

Thx to ligh, I found my mistake, I kind of overlooked that bframes (in DivX) are not allowed to refer to Iframes ;)

Cu Selur