Xvid BVOP test

[lordadmira]

Thanks to Teeg's prompting, I did some testing on various "extreme" B frame settings. The results were stunning. I think we may have uncovered a flaw in Xvid's B frame decision. Here are the results:

Coors Lite NFL[Xvid 1.0.1 Q5 28-1-0-0-BVOP].avi		     21,770 KB
Coors Lite NFL[Xvid 1.0.1 Q5 2-1-0-0-BVOP].avi		     21,770 KB
Coors Lite NFL[Xvid 1.0.1 Q5 2-1-0-80-BVOP].avi		     22,262 KB
Coors Lite NFL[Xvid 1.0.1 Q5 28-1-0-80-BVOP].avi	     22,734 KB
Coors Lite NFL[Xvid 1.0.1 Q5 noBVOP].avi		     21,550 KB
Coors Lite NFL[Xvid 1.0.1 Q2 28-1-0-80-BVOP noGMC].avi	     56,324 KB
Coors Lite NFL[Xvid 1.0.1 Q2 28-1-0-80-BVOP noGMC noAQ].avi  57,530 KB
Coors Lite NFL[Xvid 1.0.1 Q2 28-1-0-80-BVOP].avi	     56,274 KB
Coors Lite NFL[Xvid 1.0.1 Q2 noBVOP].avi		     53,100 KB

It was done with Koepi's 1.0.1 build, single pass constant quant, the numbers in the file names are Bmax, ratio, offset, Bsens. Other settings for all were Trellis, Chroma Motion, Chroma Smoother, Adaptive Quantization, GMC, Motion 6, VHQ 4, H.263 matrix. I couldn't believe what I was seeing so I also did some without GMC and AQ. The clip I encoded was a Coors Light Superbowl commercial I recorded off TV at 10Mbps 720x480. There was heavy static in the signal. The most striking result was that *any* B frames increased the size of the clip!

While I was trying to make sense of this I started thinking about the clip itself and then realized something. There is only one type of motion that B frames can take advantage of. B frames won't help u on any kind of pans, zooms, rotations, or other small motions. B frames can only bi-predict motion on translational motion within the frame, something this clip contained very little of. It was a typical beer commercial, lots of fast pans and cuts, babe, beer, field, babe, beer, crowd, beer, etc.

So I think what we can take away from this is that the utility of B frames is highly source dependant. I'll be doing some more tests to see how it reacts to other motion types. But the million dollar question for now is how can the mere presence of B frames result in a higher file size?

LA

edit: B frames can take advantage of pans.

[chilledoutuk]

First thing the quant ratio you have used is 1 which means that the bframes will have the same quantizier as all the pframes it refers to.

This has caused the larger filesizes as the bframes are going to take up just as much space as the pframes (and you have more motion vectors with bframes).

bframes can be quantisied more becuase they use bidirectional motion prediction, which means that less intra blocks have to be coded to construct an entire frame when compared to a pframe.

If your going to do tests on fixed quants then I suggest that you use the default settings for bframes.(Which are 2,1.50,1.0)

You can use 1.0 quant ratio but dont expect the video stream to be smaller but the quality of the video stream (psnr) should be improved over not using bframes.

[chilledoutuk]

you can analyse the video streams you encode with this little app which is quite useful for looking at quant distribution.


http://www.geocities.com/analyzerdrf/index.html

[Prettz]

Originally posted by chilledoutuk

bframes can be quantisied more becuase they use bidirectional motion prediction, which means that less intra blocks have to be coded to construct an entire frame when compared to a pframe.

You assume that less intra blocks have to be coded. That's entirely source dependent. The REAL reason they can be quantized more is that the following frames do not reference them, they only reference the most recent p-frame.

They come in handy I believe when there's very little motion or noise, so the predicted residual can be quantized more without it hurting the resulting picture too much.

[Teegedeck]

Hi, lordadmira,
thanks for conducting that test, good work!

Originally posted by lordadmira
I think we may have uncovered a flaw in Xvid's B frame decision.

I don't know what you are surprised about, really; everybody told you that b-frames by themselves would not be smaller than p-frames. sysKin, who's post I quoted in that other thread, explains that b-frames are not supposed to have the same quantizer as p-frames. They look like their preceding p-frames even when they are quantized more strongly. They should be quantized more strongly.

Originally posted by lordadmira
But the million dollar question for now is how can the mere presence of B frames result in a higher file size?

There have been several threads about that.

[lordadmira]

I was making my statements based on motion compensation. For my claims to be true the savings from motion compensation have to be greater than other considerations. This clip didn't contain much motion that B frames could exploit but the codec put them in anyway. So let's call it an opportunity for advancement. A VHQ-like mode that tests for BVOP friendly motion types. If this kind of algorithm decided on when to put in a B frame I think quality would increase for all encodes. Now we have to do a "visual inspection" to see if full quality BVOPs will be of any use for a particular encode. We'll know for sure when I do the same tests on another clip with more translational motions.

[chilledoutuk]

erm why have you changed the name of the thread it was call "Xvid BVOP failure"

As to pretz its not source dependant if your comparing encodes of the same sequence one with bframes and one without. The one without should have more intrablocks.

please run you tests with the default bframe settings and then you will see why its the default setting

[Teegedeck]

I guess he did it because there is no failure. XviD's b-frames, I dare say, work fine.

If XviD's b-frames don't do something that no developer ever claimed they would do - i. e. being smaller than p-frames at the same quant - then this isn't a shortcoming. If anyone has his/her own ideas about what XviD's b-frames should do, please cite a reference (like MPEG documents) where it says they should do just that. That would be helpful and give an incentive to change something. Otherwise - well; not.

[RadicalEd]

It's cause you used VHQ 4 :_
Without VHQ, the behavior looks to be as you predicted.

[lordadmira]

I did another no BVOP vs. full qual BVOP head to head matchup. And this time using one of my beloved Inuyasha eps as the subject. All settings the same as the first test. It wasn't even close, it was a complete rout. As RadicalEd has pointed out, the benefits and power of VHQ 4 are so dominating that no BVOP setting can make up for their loss. Having a B frame means no VHQ and therefore worse motion compensation. Not even the bi-predicted ME can give as good a result as VHQ on the P frames. The B/P frame ratio was about 2 to 1. The results:

Inuyasha - Kikyo and the Dark Priestess[Q4 28.1.0.30 BVOP].avi  162,114 KB
Inuyasha - Kikyo and the Dark Priestess[Q4 noBVOP].avi          131,742 KB 

After seeing this I am probably going to just quit using B frames altogether. Atleast until we have VHQ or something like it for B frames. As Teeg points out BVOPs work as "marketed" but by no means do they work to the level that theory allows.

On another note this points out just how darn good Xvid's VHQ mode really is.

LA

[Tommy Carrot]

The main reason of the size increment is not the VHQ search. Simply the p-frames are getting bigger because they are farther from each other thus they have to compensate more motion. Usually the more quantized b-frames can offset this behavior, but if they have the same quant, they cannot anymore.

[stephanV]

Originally posted by lordadmira
After seeing this I am probably going to just quit using B frames altogether. Atleast until we have VHQ or something like it for B frames. As Teeg points out BVOPs work as "marketed" but by no means do they work to the level that theory allows.

i wouldnt go that far in your conclusion. your result only indicates that your (extreme) b-frame settings are not as good as assumed (thats what testing is for ). several people, including XviD-developers, have pointed out that B-frames shouldnt be encoded with equal quants. if i understand it correctly, the whole point of b-frames is that you can use higher quants for them. so unless you can point us out to the "theory" were your kind of use of b-frames is justified, i would say your conclusion is not correct.

or, do a test with b-frames/no b-frames without VHQ. if your test shows a smaller filesize with your b-frame settings then there still is hope

what all of this means quality wise, is another discussion of course.

[lordadmira]

Originally posted by stephanV
the whole point of b-frames is that you can use higher quants for them. so unless you can point us out to the "theory" were your kind of use of b-frames is justified, i would say your conclusion is not correct.

That's not entirely correct. Quant offsets is just one mode of B frame use. The spec allows for any decision algorithm u want. It's the same flexibility that gave us VHQ.

I'm doing another encode with VHQ off and the same BVOP settings. Ed has indicated that high B frame usage gave size savings with no VHQ.

[stephanV]

Originally posted by lordadmira
That's not entirely correct. Quant offsets is just one mode of B frame use. The spec allows for any decision algorithm u want. It's the same flexibility that gave us VHQ.

of course, but that does not mean that every setting that can be used makes sense. That b-frames can have any quant does not mean that they should be used in this way.

I'm doing another encode with VHQ off and the same BVOP settings. Ed has indicated that high B frame usage gave size savings with no VHQ.

I'm following it with interest.

[lordadmira]

Originally posted by Tommy Carrot
p-frames are getting bigger because they are farther from each other thus they have to compensate more motion.

Actually it's the opposite. The less motion is compensated the bigger the frame. Motion compensation reduces the frame size since there are fewer blocks that have to be quantized. If the file size goes up with full qual BVOPs it means that less motion compensation is going on and more data is being quantized from scratch.

LA

[sysKin]

Originally posted by lordadmira
Actually it's the opposite. The less motion is compensated the bigger the frame. Motion compensation reduces the frame size since there are fewer blocks that have to be quantized. If the file size goes up with full qual BVOPs it means that less motion compensation is going on and more data is being quantized from scratch.

I think you b0rked something here...

[Didée]

OUCH!

Originally posted by lordadmira

Actually it's the opposite. The less motion is compensated the bigger the frame. Motion compensation reduces the frame size since there are fewer blocks that have to be quantized. If the file size goes up with full qual BVOPs it means that less motion compensation is going on and more data is being quantized from scratch.

lordadmira,

you have a big talent in mixing up things - are you working as a barman?

Your conclusion is mostly right. But your "correction" of Tommy Carrot is just ridiculous!

The farther away P-frames are, the more the frames between them change, simply because there are more frames between them in which motion occurs.

Shortly: the farther away, the more motion *has* happend that must be compensated. Just as Tommy said, period.

But then, your conclusion is not too way off. Since much more motion has to be compensated, the ME will fail to compensate sufficiently for some moving blocks, giving either a suboptimal and therefore more expensive compensation, or even trigger an intra block instead of a compensated one.
But that's only a small part of the story. XviD will still compensate more motion still quite good, I assume. The problem simply is: when more motion must be compensated, this means that the actual motion vectors will become *longer*. And the longer a motion vector is, the more bits it will need to get stored in the bitstream. *That* is a big point why P-frames are getting larger with increasing distance.

Therefore, a good balanced algorithm has to do its magic, to balance out the gain of putting B-frames with the loss of longer vectors & less optimal matchings on ME.
And the sweetspot is - in the range of #B-VOPS = 1|2 & sensitivity around zero.
The sweetspot definetly is NOT at #B-VOPS = 28 & overdriven sensibility.

Please consider the PM, too.

- Didée

[lordadmira]

Maybe we are thinking of two different things by the words "motion compensation" (i.e. ME, motion estimation). When I say motion compensation, and compensated blocks, I'm talking about a macroblock that has been predicted into a following frame. Frame n+1 has taken the macroblock from frame n and therefore doesn't have to code for it. There is just the motion vector. The farther away the P frames are the more blocks have to be intra-coded, the less blocks can be compensated for by motion compensation, prediction; because, the block has to exist in both P frames to be handled by motion compensation. Greater distance -> fewer common blocks -> less motion compensation -> more intra-blocks. The motion distance is trivial since even a full length vector can be encoded in just a few bits.

I think both of u are saying compensation when u really mean full block coding.

I'm not a mad scientist u know. I take my ideas from the Mpeg spec and H264 especially. Maybe I'm too enthusiastic? %-)

LA

[sysKin]

Originally posted by lordadmira
When I say motion compensation, and compensated blocks, I'm talking about a macroblock that has been predicted into a following frame. Frame n+1 has taken the macroblock from frame n and therefore doesn't have to code for it. There is just the motion vector. The farther away the P frames are the more blocks have to be intra-coded, the less blocks can be compensated for by motion compensation, prediction; because, the block has to exist in both P frames to be handled by motion compensation. Greater distance -> fewer common blocks -> less motion compensation -> more intra-blocks. The motion distance is trivial since even a full length vector can be encoded in just a few bits.

Okay here's your mistake. A predicted block doesn't have to be predicted without any texture, it actually rarely happens. Yes, on one end you've got blocks that are motion-predicted and nothing else, and on the other end - you've got intra blocks.

You kinda forgot about all the possibilities in the middle (motion+texture), which are definitely most common.

[edit]In particular, "the block has to exist in both P frames to be handled by motion compensation" is false. A "good" (sane) codec will only compensate of block is good enough, but in theory, it's always possible to compensate from anything. For example, b-frames don't have intra blocks at all, and all blocks are always motion-compensated.

[lordadmira]

A B frame can have no intra-blocks? Are u sure about that, I find that surprising. Can u expound some more on ur use of the word "texture"? Are u talking about some kind of diff or deformation that's done on blocks after they're taken from their source frame? But atleast u accepted my basic explanation as correct.