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? :confused:

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? :confused: 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
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.


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. :D

[malkion]

Hi lordadmira, I did a test in Vdub and Xvid setting zones for dropped frames with b-frames. It still results in dropped frames. Did I do something wrong?

First zone starts 0 frame
2nd zone starts (last frame -1) start with keyframe

Glad you feeling going back to using default bvops. :)

[SeeMoreDigital]

Originally posted by 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. :D There is quite a lot of detailed information in "DivX's Official Guide/Manual" (sorry) about this subject: -

Intra-frames and Predicted-frames

An intra-frame is one in which all of the macroblocks are stored as images rather than as motion vectors. As noted previously, recording the image of a block is the most expensive method in terms of storage and hence I-frames are the most expensive type of frame. Fewer I-frames in the video generally translates to better compression and I-frames are normally used by the encoder only when too few blocks can be tracked from the reference frame by the motion search algorithm.

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/Intra_01.GIF

I-frames serve a very important purpose: All of the blocks in an I frame are stored as images, thus decoding an I frame reveals a complete picture without dependency on reference frames. For this reason I frames are also known as key-frames, and they are the only type of frame completely independent of all others. A predicted frame is one that can contain forward-predicted blocks in other words blocks that have been predicted via a motion vector from the previous frame by the motion search.

It is normally unlikely that all of the blocks in a P-frame can be predicted, and where blocks can not be tracked from the previous frame an intra-block is used in its place, similar to those found in an I-frame. Because P-frames reconstruct much of the frame by applying motion vectors to the previous frame (motion compensation) they are far less expensive in terms of storage than I-frames. One or more P-frames may follow an I-frame:

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/Intra_02.GIF

A greater ratio of P-frames to I-frames leads to a higher compression ratio.


Bi-directional Frames (B-VOP)

Recall that in an I-frame all blocks are intra-blocks and are encoded as the image filling the block. In a P-frame blocks can be either intra-blocks or forward predicted blocks those described by a vector referencing a matching area of image in the previous frame (known as forward prediction).

Bi-directional frames can contain blocks that are intra, forwards predicted, backwards predicted, or both forwards and backwards predicted. This means that B-frames reference not only the previous frame but the next frame also.

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/B-VOP_01.GIF

In the diagram frames 2 and 4 are bi-directional frames and any macro-block may be predicted from either the previous (forward) or next (backward) frame. If a block is both forwards and backwards predicted then when motion compensation takes place the block image will be the result of blending the appropriate areas of the forwards and backwards frames together. Notice that frame 4 contains some intra-blocks because in the example these blocks could not be predicted from either the forwards or backwards frame.

As described earlier in the guide, predicting blocks consumes far less bits than encoding them intra-blocks. Because B-frames can be both forwards and backwards predicted in general B-frames will have a lower proportion of intra-blocks than any other type of frame. Since B-frames themselves are never referenced by any other frame it is possible for the encoder to use a higher quantizer than is normal for their coding since it need not be concerned with impacting upon the quality of other frames due to compound errors. These two key features of B-frames lead them to offer the greatest compression ratio of any of the available frame types.

The ordering of frames
Backward prediction introduces issues relating to the sequence in which frames must be encoded and decoded. Whereas forward prediction, as used by P-frames, simply references the last frame that was decoded, a backwards predicted block in a B-frame makes reference to some future frame that has not yet been decoded. Therefore, in order to decode B-frames it is necessary to decode future frames first. This is why frames may appear out-of-order in the multi-pass log file.

Consider once again the above illustration. Here the blue arrows represent forwards prediction in the P-frames and the red arrows represent either forward (left) or backward (right) prediction in the B-frames.

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/B-VOP_02.GIF

It is clear from the diagram that the B-frames can make reference to future frames because there are red arrows pointing to the right. The encoder must re-order these frames so that they are in the correct order for decoding.

Now consider the re-ordered sequence of frames:

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/B-VOP_03.GIF

Although Frame 2 still makes reference to both frame 1 and frame 3, frame 3 is decoded first. It is now clear that in the re-ordered sequence all frames can be decoded, as every frame makes reference only to others that have been previously decoded (all arrows point left). The decoder is responsible for displaying the decoded frames in the correct order.Now that's simple to understand... isn't it!

My apologies to DivX for extracting sections of their guide without asking permission first.

I will of course remove the above immediately if instructed to do so.


Cheers

[lordadmira]

Ewww! I've been slapped with a "RTFM n00b!" post! http://www.onlyeverything.com/forums/images/smiles/icon_crying.gif But seriously, that post contradicts you Syskin, it says BVOPs can contain intra-blocks. An Xvid/Divx difference?

[Sulik]

The MPEG-4 spec does NOT allow intra-coded blocks in B-frames (only P-frames can contain intra and non-intra coded blocks).

This differs from the MPEG-2 spec, which does allow intra blocks in B-frames.

[sysKin]

Yeah, "Divx official guide" thingy has some small mistakes. I remember it saying that b-frames can reference to another b-frames, which is also incorrect.

Mpeg-4 allows four macroblock modes in b-frames: Bit pattern "1" for direct mode, "01" for intrpolate, "001" for forward and "0001" for backward.
Now, you might wonder why the list is open, and "0000" is illegal. No idea. It's one of the weirnessess of mpeg-4. Maybe they wanted "0000" to be intra? Why was it dropped then....

[lordadmira]

Originally posted by malkion
I did a test in Vdub and Xvid setting zones for dropped frames with b-frames. It still results in dropped frames. Did I do something wrong?
Hmm, yeah I've experience that too. I don't know what's going on. Maybe VDub isn't passing the right number of frames so the zone never get's used. I started backing off a few more frames for the zone start and setting a super low BVOP sensitivity just to be safe. Like n-10 Bsens -100.

LA

[skal]

Hi all,

to complement Syskin's posting, you may notice that the
real magic of b-frames is to be found in the 'interpolate'
mode, and it's succubus "skipped" which is where the gain
comes from. Other modes cost more than the equivalent
in a p-frames. Not to mention INTRA which are often coded
as "forward + (0,0)" when entering panic-mode :)
Additional mode is bidirectional + delta-mv, but it's
often hard to find good use for it (there's 1 mv to
signal, and it's a clear departure for skip-only mode).

So: you should have a good reason to go for a
b-frame, but it's often worth.
[too bad that it's close to impossible to backtrack
a bad b-frame decision and demote it to p-frame on the fly]

As a rule of the thumb: b-frames are good for high motion
(with low quant) and slow steady motion too (panning, e.g.),
where b-skip mode gives good result.

(statement to be discussed, of course)

bye!
Skal

[Prettz]

Originally posted by skal
Not to mention INTRA which are often coded
as "forward + (0,0)" when entering panic-mode :)

That actually seems like a much better alternative to coding Intra blocks in b-frames, since it takes very little to code that after entropy coding does its thang, and you get a block with a lower quantization. Intra coded blocks in a b-frame would have to be at a higher quant and so wouldn't really be useful.

Originally posted by skal

Additional mode is bidirectional + delta-mv, but it's
often hard to find good use for it (there's 1 mv to
signal, and it's a clear departure for skip-only mode).

Could you explain what this one means in more detail?

[skal]

@Prettz:

Could you explain what this one means in more detail?


the BDIRECT mode in b-vops is a skipped one (no texture transmitted),
where you infer two motion vectors by interpolating the forward one,
according to the b-vop's distance from its past and future anchors.

Now, you can afterward add a "delta-mv" to these two motion
vectors, but you will have to transmit this delta-mv. For a pure
BDIRECT mode, the delta-mv is assumed to (0,0), which is often
a good assumption, RD-wise.


Skal

[lordadmira]

I finished the next round of tests. This time testing VHQ against "free" BVOPs. The same Inuyasha ep, same other settings. Even without VHQ the no BVOP encode blew away the BVOP one. VHQ gave little savings with BVOPs on but did save several megs with BVOPs off. I did another encode with ME precision 1 (ME 0 disables PVOPs) and that cost almost 10 megabytes. Therefore it has to be the ME 6 setting that is doing most of the P frame work. The B/P ratio was about 3 to 1.

Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP noVHQ ME1].avi 149,746 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP noVHQ].avi 139,562 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 28.1.0.30 BVOP noVHQ].avi 162,688 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 28.1.0.30 BVOP].avi 162,114 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP].avi 131,742 KB So my conclusion is yet again that B frames are totally useless for full quality encodes. We need a VHQ-like mode for B frames so we can take advantage of their bi-prediction abilities!


LA

[Prettz]

Originally posted by lordadmira
So my conclusion is yet again that B frames are totally useless for full quality encodes.
What a terrible conclusion. If you use b-frames you can up the resolution significantly. If even low-quant b-frames cause too much artifacts in some scenes, you can use zones to disable them in those scenes. I don't think you realize just how much space b-frames save in no-motion scenes without even affecting quality.

[lordadmira]

B frames don't save u anything in no-motion scenes. In a static scene the most efficient way to encode that is with P frames. All the blocks will be forward predicted and the frame will just consist of the motion vectors. These frames can be under 400 bytes at 640x480. And remember that we're talking about minimally lossy encoding here. B frames with offsets just increase the lossiness.

LA

[Prettz]

Originally posted by lordadmira
B frames don't save u anything in no-motion scenes. In a static scene the most efficient way to encode that is with P frames. All the blocks will be forward predicted and the frame will just consist of the motion vectors. These frames can be under 400 bytes at 640x480. And remember that we're talking about minimally lossy encoding here. B frames with offsets just increase the lossiness.

LA
By "no motion" I mean scenes with little enough motion that quant 3 b-frames come out to over 800 bytes. I've never seen a p-frame that was only 400 bytes, even with no motion, but in such a situation a quant 3 b-frame would come out to 9 bytes.

[Teegedeck]

Originally posted by lordadmira

Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP noVHQ ME1].avi 149,746 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP noVHQ].avi 139,562 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 28.1.0.30 BVOP noVHQ].avi 162,688 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 28.1.0.30 BVOP].avi 162,114 KB
Inuyasha - Kikyo & the Dark Priestess[Q4 noBVOP].avi 131,742 KB So my conclusion is yet again that B frames are totally useless for full quality encodes. We need a VHQ-like mode for B frames so we can take advantage of their bi-prediction abilities!
Holy cow! lordadmira, you must have learnt enough through our dicussion to understand that
a)you should have tested the standard b-vop setting against these settings above because
b)more than 3 b-frames in a row don't help but might actually hurt, and
c)0.3 as offset and 1.0 as ratio are hardly better than 0.0/1.0
d)I already told you in the very beginning that b-frames, if not compressed considerably stronger than p-frames, compress worse than p-frames!

lordadmira, if you continue like that, you'll make me give up on you, and that's pretty sad because usually I don't do that. Stop lamenting and use the defaults...

[stephanV]

I must agree with teegedeck here. your test only shows that your extreme b-frame settings are not really good.

@skal, syskin or anyone else who knows these things:

since it somewhat related to this topic; how much would b-frames benefit from VHQ (in human language talk ;) ). would it be the same as p-frames? more, less, not at all?
im guessing its less because B-frames (usually ;) ) already have a higher quant... also, what would the effect be speed wise, would it slow down more on b-frames as on p-frames?

thx in advance for sharing your thoughts

[SeeMoreDigital]

What are the 'max I frame intervals' some of you guys are using?

[unmei]

@Prettz: i assume you mean you've never seen a quantiser 2 P-frame below 400 byte. Else i could show you a xvid status picture with a P-frame of 369 bytes at a resolution of 688x560 wich is most likely quantiser 5 (the stream is 743kbit/s with many b-frames and quantiser averages 3.05/4.13/6.46 (total 5.92)).


@SeeMoreDigital: i never felt like changing the default. 300 seems reasonable to me even if some people say it should be 250 for pal. I had no reason so far to doubt XviD's keyframe decisions so i think 250 or 300 ..it doesn't really matter that much. BTW i don't cut up my encodes so i don't have to care about possible cut points.

[SeeMoreDigital]

Originally posted by unmei
SeeMoreDigital: i never felt like changing the default. 300 seems reasonable to me even if some people say it should be 250 for pal. I had no reason so far to doubt XviD's keyframe decisions so i think 250 or 300 ..it doesn't really matter that much. BTW i don't cut up my encodes so i don't have to care about possible cut points. I would have thought having the I frames closer together might help the b-frames become more accurate.

As a PAL user I must admit I do set the I frames to 250 (every 10 seconds) and not the default 300. But I can't see why going even lower, to say 125 (every 5 seconds) would harm the encode. Although the file size would need to increase.

However, much as I'd like to, it's pointless for me to experiment more in this field, because XviD encodes with B-VOP (or B-VOP's) don't work properly in hardware.


Cheers

[Teegedeck]

@SeeMoreDigital: I set my max. i-frame dist. value astronomically high (even if it means very slow seeking sometimes) because they're big bitrate-wasters and I don't like the visual effect of suddenly having a keyframe in the middle of a still-scene. It shouldn't make that much of a difference because few still-scenes exceed 10 seconds. But still, it may happen and I don't recommend that to people who like to jump back and forth in a video.

[SeeMoreDigital]

Arrh yes, thanks for pointing this out Teegedeck.

I guess forcing I frames to suddenly appear in a still scene might well look a bit odd...

Back to the drawing board for me then!


Cheers

[Sagittaire]

Originally posted by SeeMoreDigital


As a PAL user I must admit I do set the I frames to 250 (every 10 seconds) and not the default 300. But I can't see why going even lower, to say 125 (every 5 seconds) would harm the encode. Although the file size would need to increase.

Cheers

250 or 2500 frames that doesn't change anything ... it's Max Key Frame Interval. XviD (and other codec) place automaticaly Iframe for "Change Scene Frame". For exemple Matrix II: 1000 Iframe for 35000 Frame thus 35 for average Iframe Interval. Max Key Frame Interval is important for navigation ...


For Bframe I confirm lordadmira test. For a true quant encoding (I,P,B with same quant) the size gain is small ... but bframe must have a superior quant than reference frame: the bframe are able to support an increase quantification without losing as much quality than Pframe ...

To simplify ...

I(q3)P(q4)P(q4)P(q4) and I(q3)P(q4)B(q4)P(q4) are equivalent with same size

I(q3)P(q3)B(q6)P(q3) could be better than I(q3)P(q4)P(q4)P(q4) with same size

[Leak]

Originally posted by SeeMoreDigital
However, much as I'd like to, it's pointless for me to experiment more in this field, because XviD encodes with B-VOP (or B-VOP's) don't work properly in hardware.

That's not true - B-VOPs (even more than one in a row) work fine on my Elta 8883 as long as packed bitstream stays off.

np: Four Tet - As Serious As Your Life (Rounds)

[SeeMoreDigital]

Originally posted by Leak
That's not true - B-VOPs (even more than one in a row) work fine on my Elta 8883 as long as packed bitstream stays off.

np: Four Tet - As Serious As Your Life (Rounds) You're lucky.

The Elta 8883 is an MediaTek chip-set player. Curious how even some MK players can cope with consecutive B-VOP and others can't.

I'm using Sigma's EM8475 chip-set!


Cheers

[lordadmira]

Originally posted by Teegedeck
Holy cow! lordadmira, you must have learnt enough through our dicussion to understand that
a)you should have tested the standard b-vop setting against these settings above because Why? The point of all this is to test full qual BVOP encodes, x/1/0, and characterize their effects. Nothing more.

c)0.3 as offset and 1.0 as ratio are hardly better than 0.0/1.0 That's 28/1/0 sens 30. :p
d)I already told you in the very beginning that b-frames, if not compressed considerably stronger than p-frames, compress worse than p-frames! I had to touch the stove to know not to touch it anymore. :p

[lordadmira]

Originally posted by Sagittaire
I(q3)P(q4)P(q4)P(q4) and I(q3)P(q4)B(q4)P(q4) are equivalent with same size U have an encode that gave u those results? Because my results would indicate that that is not the case. Having same quant (P=B) frames yeilded drastically higher file size whereas P frames only was smaller. On the order of over 30 MB.

[Sagittaire]

Here my test with true q2 ...

HP II 640*272 ~3000 frames

VHQ4, Ultra High, GMC, Qpel, AQ, Trelli, q2 for I,P et B

Bframe 0/1.00/0.00 et sensivity=0: 33 374 Ko
Bframe 1/1.00/0.00 et sensivity=0: 33 180 Ko
Bframe 2/1.00/0.00 et sensivity=0: 33 264 Ko
Bframe 3/1.00/0.00 et sensivity=0: 33 260 Ko
Bframe 1/1.00/0.00 et sensivity=100: 33 322 Ko

2 pass with Bframe 2/1.50/1.00 is very better for PSNR than 2 pass with Bframe 2/1.00/0.00 ...