How many b-frames?

[Chengbin]

How do you find out how many b-frames are actually used in a video?

Is there a sample clip that makes x264 use 16 (or a large number of) b-frames and ref-frames?

[LoRd_MuldeR]

Look at the final output of x264 in the console. It prints the percentage for each number of consecutive b-frames.
And take care that the first number means zero b-frames, the second number means one b-frame and so on...

(You will notice that even with "--b-adapt 2" and "--bframe 16" it will hardly go above ~5 consecutive b-frames)

--[EDIT]--

It usually looks like this:

x264 [info]: slice I:1 Avg QP:20.11 size: 98726
x264 [info]: slice P:128 Avg QP:25.58 size: 16829
x264 [info]: slice B:170 Avg QP:28.69 size: 5555
x264 [info]: consecutive B-frames: 6.7% 36.2% 46.3% 10.7% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.1% 90.2% 8.6%
x264 [info]: mb P I16..4: 0.1% 9.0% 1.2% P16..4: 45.2% 19.2% 14.6% 0.4% 0.5% skip: 9.8%
x264 [info]: mb B I16..4: 0.0% 0.6% 0.1% B16..8: 48.1% 3.6% 4.2% direct: 4.9% skip:38.3% L0:39.0% L1:50.4% BI:10.5%
x264 [info]: 8x8 transform intra:86.6% inter:70.5%
x264 [info]: direct mvs spatial:97.1% temporal:2.9%
x264 [info]: ref P L0 73.4% 11.8% 5.1% 3.1% 2.2% 1.9% 1.4% 1.2%
x264 [info]: ref B L0 80.1% 11.7% 3.3% 1.8% 1.2% 1.2% 0.7%
x264 [info]: ref B L1 95.3% 4.7%
x264 [info]: kb/s:2138.7

(Of course there may be examples where much more consecutive b-frames are used)

[Chengbin]

Why is 0 b frames 6.7%? What does that mean? What does the percentages mean? I remember seeing consecutively b-frame line with 0%, and at like the 8th b-frame, there is like 1%.

[Wishbringer]

Maybe it's 1bframe=6.7%, 2bframes=36.2%...
Why should it show how many bframes are not used. It shows how usage is divided. In example --bframe 4 would be enough.

If all starting numbers are 0% and 8th is 1%, then there is one or more scenes in clip, where codec put 8 bframes in a row.
Very unusual and impossible, because all numbers together are around 100%.

---- ok, forget this, I don't delete it, but its wrong ---
I will try to explain in above example
Clip has 299 Frames
1 I-frame
128 P-frames
170 B-frames

6.7% of these bframes are solo = around 11 bframes
36.2% have another bframe as neighbor
46.3% do a triple
and so on

Following is possible but rare:
bframes: 68% 24% 0% 0% 5% 0% 2% 0% 1%
.............1.....2.....3....4...5....6...7....8....9....10....

----snap----

[LoRd_MuldeR]

Why is 0 b frames 6.7%? What does that mean? What does the percentages mean?

It means that in 6.7% of all cases x264 decided that using consecutive P-Frames with no B-Frames in between them is optimal.

Maybe it's 1bframe=6.7%, 2bframes=36.2%...

No, it's not like that! That's why I said you should take care...

(Why do you think there are 17 numbers, but the maximum number of consecutive B-Frames is only 16 ???)

I remember seeing consecutively b-frame line with 0%, and at like the 8th b-frame, there is like 1%.

It depends on the source of course! But generally you won't get much benefit from using a maximum of more than ~5 consecutive B-Frames.

Of course allowing up to 16 consecutive B-Frames never hurts quality, but the benefit will be very very small, if it all.

So it's not worth the additional time, especially when using "--b-adapt 2", which becomes really SLOW with a high number of B-Frames...

(In my example using more than three consecutive B-Frames doesn't give any benefit at all)

[Sharktooth]

coz x264 shows b-frames usage in that way. the first number represent 0 consecutive b-frames.
if you're not a coder or a power user you should not even care about the bframes distribution...

[Comatose]

It means that in 6.7% of all cases x264 decided that using consecutive P-Frames with no B-Frames in between is optimal.
Are you sure of this? Since it says "consecutive B-frames", the way I read it is that 0 consecutive B-frames means that B-frames were (may have been) used, but not one after another.

[Sharktooth]

Yes...
if what you said was true (which is not) then the non consecutive b-frames would be logged as non cosecutive... hence would be in the second column (1 bframe).

[Comatose]

Sorry, I was responding to LoRd_MuldeR. You posted inbetween and my net was being sluggish so I didn't manage to add the quote fast enough.
if what you said was true (which is not) then the non consecutive b-frames would be logged as non cosecutive... hence would be in the second column (1 bframe).
No, what I'm saying is that 0 consecutive B-frames were used, so it could look like this: I,P,B,P,P... if 1 is used, it would look like this: I,P,B,B,P,P... it's the amount of consecutive B-frames, which, in my interpretation and logic, means the amount of B-frames that follow a B-frame.

[Chengbin]

So if I only use 4 b-frames, there will only be 5 numbers on that line?

[Comatose]

Yup :P It would be redundant to have the rest, since you already know what they'll be without x264 telling you (0.0%).

[J_Darnley]

Zero B-frames indicates a sequence of zero B-frames. I forget exactly how the terms go (but akupenguin or Dark Shikari posted on this) but they indicate the number of PP, PBP, PBBP, PBBBP, etc sequences out of the total number of sequences.

See: http://forum.doom9.org/showthread.php?p=1163681#post1163681

[EDIT] Jeez, a lot of posts appeared while searching

[Dark Shikari]

Zero B-frames indicates a sequence of zero B-frames. I forget exactly how the terms go (but akupenguin or Dark Shikari posted on this) but they indicate the number of PP, PBP, PBBP, PBBBP, etc sequences out of the total number of sequences.No, it's weighted by the size of each sequence.

So, for example, if you have:

PPPPBPBB

This is really:
P <-size 1
P <-size 1
P <-size 1
PB <-size 2
PBB <-size 3

So the %s are:

(1+1+1)/(1+1+1+2+3) = 37.5%
2 / (1+1+1+2+3) = 25%
3 / (1+1+1+2+3) = 37.5%

or

37.5% 25% 37.5%

[LoRd_MuldeR]

So if I only use 4 b-frames, there will only be 5 numbers on that line?

Exactly ;)

The only possible cases with a maximum of 4 consecutive B-Frames are 0, 1, 2, 3 and 4 consecutive B-Frames.

[Comatose]

Zero B-frames indicates a sequence of zero B-frames. I forget exactly how the terms go (but akupenguin or Dark Shikari posted on this) but they indicate the number of PP, PBP, PBBP, PBBBP, etc sequences out of the total number of sequences.

See: http://forum.doom9.org/showthread.php?p=1163681#post1163681

[EDIT] Jeez, a lot of posts appeared while searching
That post doesn't seem to say what you said (just that it's 0 to 16 B-frames), but if it's 0 to 16 B-frames, and not 0 to 16 consecutive B-frames, then perhaps it should be changed to how many B-frames were used in sequence, and then the value of 0 would mean no B-frames were used.

Consecutive implies that they follow something, without interruption. So having 0 consecutive B-frames still doesn't mean there were no B-frames AT ALL, just that there weren't any cases like PBB, and that's misleading.

Again, I'm not saying this is what happens in practice, but merely that the wording is misleading.

[Dark Shikari]

Consecutive implies that they follow something, without interruption. So having 0 consecutive B-frames still doesn't mean there were no B-frames AT ALL, and is misleading.I'm pretty sure you're the only person to have ever been misled in that way (and omitting the word "consecutive" confused far more people), so I don't think this is really an issue.

[Comatose]

So then am I the only person who understands the meaning of 'consecutive'? I'm not saying it should be omitted, I'm saying it should be changed to something that, when read without prior knowledge, would give you the right idea.

[Chengbin]

Is it possible to find the time stamp where x264 uses 16 b-frames and 16 ref-frames? I want to do some stress testing on my 5, and see how many b and ref-frames it actually supports.

We've been talking about a lot about b-frames, but my other question about number of ref-frame has not been answered yet. How do you find the number of ref-frames?

[Dark Shikari]

Is it possible to find the time stamp where x264 uses 16 b-framesUse a stream analyzer, like Elecard's, or just read the passfile.and 16 ref-frames?The max number of reference frames will be used as soon as the DPB fills.So then am I the only person who understands the meaning of 'consecutive'?"Zero consecutive X" means there is no X. In the case of "One consecutive X", the "consecutive" is redundant, because there is only one X. "Two consecutive X" means there are two Xs. By your logic, "two consecutive X" means there are three Xs, which I'm pretty sure nobody else in the entire world would agree with.

There is no vagueness here except in your mind.I'm not saying it should be omitted, I'm saying it should be changed to something that, when read without prior knowledge, would give you the right idea.It was changed to the current one for exactly the reason you stated.

[LoRd_MuldeR]

So then am I the only person who understands the meaning of 'consecutive'?

Consecutive means consecutive. I don't see how this is ambiguous :confused:

Is it possible to find the time stamp where x264 uses 16 b-frames

You could play the video with ffdshow as your decoder and use the OSD. There is the "Frametype" OSD element.

The same is possible with DGAVCIndex...

How do you find the number of ref-frames?

x264 [info]: slice I:1 Avg QP:20.11 size: 98726
x264 [info]: slice P:128 Avg QP:25.58 size: 16829
x264 [info]: slice B:170 Avg QP:28.69 size: 5555
x264 [info]: consecutive B-frames: 6.7% 36.2% 46.3% 10.7% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.1% 90.2% 8.6%
x264 [info]: mb P I16..4: 0.1% 9.0% 1.2% P16..4: 45.2% 19.2% 14.6% 0.4% 0.5% skip: 9.8%
x264 [info]: mb B I16..4: 0.0% 0.6% 0.1% B16..8: 48.1% 3.6% 4.2% direct: 4.9% skip:38.3% L0:39.0% L1:50.4% BI:10.5%
x264 [info]: 8x8 transform intra:86.6% inter:70.5%
x264 [info]: direct mvs spatial:97.1% temporal:2.9%
x264 [info]: ref P L0 73.4% 11.8% 5.1% 3.1% 2.2% 1.9% 1.4% 1.2%
x264 [info]: ref B L0 80.1% 11.7% 3.3% 1.8% 1.2% 1.2% 0.7%
x264 [info]: ref B L1 95.3% 4.7%
x264 [info]: kb/s:2138.7

[Chengbin]

You could play the video with ffdshow as your decoder and use the OSD. There is the "Frametype" OSD element.

The same is possible with DGAVCIndex...



x264 [info]: slice I:1 Avg QP:20.11 size: 98726
x264 [info]: slice P:128 Avg QP:25.58 size: 16829
x264 [info]: slice B:170 Avg QP:28.69 size: 5555
x264 [info]: consecutive B-frames: 6.7% 36.2% 46.3% 10.7% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.1% 90.2% 8.6%
x264 [info]: mb P I16..4: 0.1% 9.0% 1.2% P16..4: 45.2% 19.2% 14.6% 0.4% 0.5% skip: 9.8%
x264 [info]: mb B I16..4: 0.0% 0.6% 0.1% B16..8: 48.1% 3.6% 4.2% direct: 4.9% skip:38.3% L0:39.0% L1:50.4% BI:10.5%
x264 [info]: 8x8 transform intra:86.6% inter:70.5%
x264 [info]: direct mvs spatial:97.1% temporal:2.9%
x264 [info]: ref P L0 73.4% 11.8% 5.1% 3.1% 2.2% 1.9% 1.4% 1.2%
x264 [info]: ref B L0 80.1% 11.7% 3.3% 1.8% 1.2% 1.2% 0.7%
x264 [info]: ref B L1 95.3% 4.7%
x264 [info]: kb/s:2138.7

Please explain :D Why are there 3 lines for ref-frames?

[Dark Shikari]

Please explain :D Why are there 3 lines for ref-frames?Because B-frames have two reference lists.

[laserfan]

Look at the final output of x264 in the console. It prints the percentage for each number of consecutive b-frames. And take care that the first number means zero b-frames, the second number means one b-frame and so on...If x264's console output is explained/summarized anywhere, I'd sure appreciate someone linking me to it so I can understand better.

Hoping it's not just "tribal knowledge".

[Dark Shikari]

If x264's console output is explained/summarized anywhere, I'd sure appreciate someone linking me to it so I can understand better.Much like a lot of x264's source code, the output is designed to be understandable for someone with significant familiarity with the H.264 specification, but not with x264 itself.

Most of it is not meant to be understood by someone who does not know about how H.264 works.

[turbojet]

I'll take a stab at it

x264 [info]: ref P L0 73.4% 11.8% 5.1% 3.1% 2.2% 1.9% 1.4% 1.2%
refs for p frames 1-8 = --ref 8

x264 [info]: ref B L0 80.1% 11.7% 3.3% 1.8% 1.2% 1.2% 0.7%
refs for b frames 1-7 its 1 less than --ref because bframes cannot reference other bframes unless --b-pyramid is used

x264 [info]: ref B L1 95.3% 4.7%
bframes referenced for bframes: 1-2 only when --b-pyramid is used, since --bframes 3 was used it can reference 1 or 2 other bframes

[Dark Shikari]

x264 [info]: ref B L1 95.3% 4.7%
bframes referenced for bframes: 1-2 only when --b-pyramid is used, since --bframes 3 was used it can reference 1 or 2 other bframesNumber of B-frames has nothing to do with the size of L1, only b-pyramid.

[turbojet]

Then what does it mean?

L1 doesn't exist without --b-pyramid

[Sharktooth]

if i understood it correctly ref B L1 should be the second reference list (since b-frames may have 2 reference lists - past and future).
b-pyramid enables b-frames as reference (for other b-frames).

[laserfan]

Much like a lot of x264's source code, the output is designed to be understandable for someone with significant familiarity with the H.264 specification, but not with x264 itself.

Most of it is not meant to be understood by someone who does not know about how H.264 works.Ok, I get it...thanks.

Wakari mashite!

[Chengbin]

How do I use DGAVCIndex to check for frame type? Stream is disabled for some reason.

[LoRd_MuldeR]

How do I use DGAVCIndex to check for frame type? Stream is disabled for some reason.

Use "File" -> "Play" and look at "Frame Type" in the Information window...

[Chengbin]

It says "not yet" for frame type.

[LoRd_MuldeR]

It says "not yet" for frame type.

Hmm, I get the same result. Not sure why that is. Maybe "not yet" means "not implemented yet" ;)

You may want to try H264Visa (http://www.h264visa.com/downloads.html) as an alternative...

[SeeMoreDigital]

It says "not yet" for frame type.Sadly this particular functionality was removed from DGAVCIndex a few months ago :(

[Chengbin]

Just used H264Visa. Unbelievably complicated. Where do you find frame type decisions? Do they tell you the frame type frame by frame? Do they tell you at what time stamp b/ref-frames are used the most?

[LoRd_MuldeR]

Just used H264Visa. Unbelievably complicated. Where do you find frame type decisions? Do they tell you the frame type frame by frame? Do they tell you at what time stamp b/ref-frames are used the most?

Look at "Slice Type" in the "MB Info" dialog.

[Dark Shikari]

Just used H264Visa. Unbelievably complicated. Where do you find frame type decisions? Do they tell you the frame type frame by frame? Do they tell you at what time stamp b/ref-frames are used the most?Or you can just read the passfile output... :rolleyes:

[Chengbin]

Or you can just read the passfile output... :rolleyes:

But the passfile output only lasts for a second before x264 closes. I don't think x264 outputs that to a file, or something that you can mediainfo.

Even if I can find that out, I don't know the timestamp where the video uses a large number of b/ref frames.

[b66pak]

use this option:

--stats <string>

ex:

--stats "x264_stats.log"

then read it...
_

[Dark Shikari]

But the passfile output only lasts for a second before x264 closes.What are you talking about? x264 does not have any code to delete anything. If you tell it to generate a passfile, it will, and it will stay there after encoding.

[Chengbin]

OK, how about this. What kind of video make x264 use lots of b and/or ref-frames? I heard anime use a lot of b and ref frames.

[Chengbin]

What are you talking about? x264 does not have any code to delete anything. If you tell it to generate a passfile, it will, and it will stay there after encoding.

What I meant was after x264 finish encoding, it displays the passfile, but that only lasts a second before it closes. I'll try to use --stats <string> and get a log.

[Dark Shikari]

OK, how about this. What kind of video make x264 use lots of bAnything with very slow and consistent (or no) motion.and/or ref-frames?I already answered you--the max ref frames will be used as soon as the DPB fills. It has absolutely nothing to do with the video. Read what I say before you ask questions!What I meant was after x264 finish encoding, it displays the passfile, but that only lasts a second before it closes. I'll try to use --stats <string> and get a log.What the heck are you talking about? x264 does not "display" a passfile, nor does it "only last a second" before it "closes."

[LoRd_MuldeR]

x264 does not "display" a passfile, nor does it "only last a second" before it "closes."

I think he refers to the summery that is displayed when x264 completes. That of course is something different as a "stats" file.

And on Windows the console window will close right after the encode has completed, if you didn't run x264 (or your batch file) from cmd.exe, but via doubleclick from Explorer.

Easy workaround: Put "pause" at the end of your batch file ;)

I already answered you--the max ref frames will be used as soon as the DPB fills. It has absolutely nothing to do with the video. Read what I say before you ask questions!

The more important question may be: What number of reference frames is actually still useful...

[Chengbin]

I think he refers to the summery that is displayed when x264 completes. That of course is something different as a "stats" file.

And on Windows the console window will close right after the encode has completed, if you didn't run x264 (or your batch file) from cmd.exe, but via doubleclick from Explorer.

Easy workaround: Put "pause" at the end of your batch file ;)

That's what I meant.

[b66pak]

@Chengbin read this (especially kemuri-_9's post):

http://forum.doom9.org/showthread.php?p=1272585#post1272585
_

[Chengbin]

How come I encoded this near static video and not many consecutive b-frames are used?

This is the settings used

cabac=1 / ref=10 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=0.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=1000 / keyint_min=25 / scenecut=40 / rc=crf / crf=26.0 / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=14000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.50


This is the video.

http://www.megaupload.com/?d=K397FD48

This is a screenshot of the summary (the stats file I got is a 103KB file???)

http://i40.tinypic.com/303bqxs.png

[Sagekilla]

Because x264 may have deemed it more efficient to use P frames.

Remember, (Gross simplification here) a B frame is a P frame with an extra motion vector pointing towards a future frame. In some cases, spending extra bits to have that motion vector + residual can be useful. But if x264 is able to find a nearly perfect match with one MV + a few bits of residual, then why waste more bits on a second MV?