b-pyramid modes quality-difference?

[Forteen88]

About how much quality-difference is it between the b-pyramid modes (normal and strict)? Is 'normal'-mode like going from me-umh to me-tesa (almost placebo quality-difference), or is it bigger change?
I guess it depends on which source also.
EDIT: Ok, thanks DS! I guess it's more quality-difference than going from me-umh to me-tesa then :)

[Dark Shikari]

Strict is always worse than normal and should never be used unless you absolutely need it.

[shon3i]

What is averge gain in percent of quality with normal b-pyramid? i think than strict have no sense then if not have at least of 80% power as normal mode.

[juGGaKNot]

strict is for blu-ray, normal is for the rest, what are you asking ?

[egrimisu]

strict is for blu-ray, normal is for the rest, what are you asking ?

does MB-tree work with b-pyramid? if no what to chose MB tree or b-pyramid normal?

[nm]

does MB-tree work with b-pyramid?
Not yet, but maybe soon.

if no what to chose MB tree or b-pyramid normal?

MB-tree. Use presets if you don't know what you're doing.

[juGGaKNot]

It will soon, ask dark when, i see 0.5 lower qp with mb-tree than with b-pyramid normal on my source.

[RainyDog]

It will soon, ask dark when, i see 0.5 lower qp with mb-tree than with b-pyramid normal on my source.

Juggaknot, is that qcomp=0.5 or 0.5 less than the standard setting (qcomp=0.1)? Just curious as I preferred a lower qcomp value with mbtree on my tests as well (all film sources). I found the bitrate distribution was far too aggressive otherwise, sometimes with double the peaks of no-mbtree and in turn half as many, or even less than that, bits in dark/still scenes that clearly needed more.

[juGGaKNot]

Juggaknot, is that qcomp=0.5 or 0.5 less than the standard setting (qcomp=0.1)? Just curious as I preferred a lower qcomp value with mbtree on my tests as well (all film sources). I found the bitrate distribution was far too aggressive otherwise, sometimes with double the peaks of no-mbtree and in turn half as many, or even less than that, bits in dark/still scenes that clearly needed more.

not qcomp, qp, as in average qp ( or final ratefactor smaller by 0.5 )

default is 0.6

BTW Raising qcomp lowers MB-tree strength

so less qcomp = more mbtree

[RainyDog]

not qcomp, qp, as in average qp ( or final ratefactor smaller by 0.5 )

default is 0.6

BTW Raising qcomp lowers MB-tree strength

so less qcomp = more mbtree

Ok, cheers for clarifying. Yeah, I was aware that less qcomp=more mbtree and visa versa. But from all my tests, I found that lower qcomp led to less 'aggressive' bitrate distribution using mbtree, if that's the right word. Which led to compression balanced more akin to no-mbtree, at least for my sources (Blu-Ray, film). Though I don't claim to know whether it would even be possible, I still think it'd be ideal to have an mbtree rate control that was independent of qcomp...

[shon3i]

strict is for blu-ray, normal is for the rest, what are you asking ?
I ask, what is point of B-pyramid strict then if incrase of quality is almots zero, or half of normal mode or anything?

[LoRd_MuldeR]

B-Pyramid enabled will compress more efficient than B-Pyramid disabled. This applies to both modes, "normal" and "strict". But "normal" mode is even better than "strict" mode.

So if you can't use "normal" mode (e.g. BluRay compatibility is required) then it's still better to use "strict" mode than nothing. Otherwise you'd prefer "normal" mode ;)

However it should be noted that at the moment MB-Tree RC will completely disable B-Pyramid anyway, no matter what mode you select. Unless you disable MB-Tree, of course.

Therefore this topic will become more important once MB-Tree starts supporting B-Pyramid...

[Dark Shikari]

B-Pyramid enabled will compress more efficient than B-Pyramid disabled. This applies to both modes, "normal" and "strict". But "normal" mode is even better than "strict" mode.Not necessarily true. Though I can't say for sure until I write MB-tree support for B-pyramid and do some optimizing of the quantizer offsets, it's possible that strict will be worse than none in some cases.

[LoRd_MuldeR]

Not necessarily true. Though I can't say for sure until I write MB-tree support for B-pyramid and do some optimizing of the quantizer offsets, it's possible that strict will be worse than none in some cases.

Good to know. Even more reason to stick with "normal", if possible ;)

[RainyDog]

Is b-pyramid normal any better/more efficient than the old b-pyramid?

[LoRd_MuldeR]

Is b-pyramid normal any better/more efficient than the old b-pyramid?

The "normal" B-Pyramid in current x264 is like to the "old" B-Pyramid, but spec compliant. Only "strict" mode is really new.

[Dark Shikari]

The "normal" B-Pyramid in current x264 is identical to the "old" B-Pyramid.No it isn't. It's worse than the old pyramid (albeit spec-compliant). It's probably only marginally worse though, nothing that seriously matters.

[LoRd_MuldeR]

No it isn't. It's worse than the old pyramid (albeit spec-compliant). It's probably only marginally worse though, nothing that seriously matters.

Argh, he's replying faster than I can edit :D

[Trahald]

The "normal" B-Pyramid in current x264 is like to the "old" B-Pyramid, but spec compliant. Only "strict" mode is really new.

'Spec Compliance' involves making sure there is a spot in the dpb for possible delayed display time of a b-frame.

That part of normal involves removing frames from the dpb which leaves less references hurting quality. Normal only does it when it absolutely must (which is not every minigop especially when badapt == 1/2 is used.) But often enough to hurt quality a bit

Strict maintains h264 spec compliance by doing the following. After its bframes refer to it, bref is removed to maintain hierarchy (blu-ray requirement), then the frame with the lowest poc for spec compliance (even when there are no delayed frames that gop since its 'strict' )

[benwaggoner]

Do we have any sense about the general relative value of B-pyramid versus MB-Tree? Since they're exclusive choices for the moment, any sense on what the appropriate choice would be.

Anime/animation/motion graphics clearly get a huge MB-tree win and so that should be a slam dunk, but what about film/video? Any cases where we're better off with B-pyramid?

[Dark Shikari]

Do we have any sense about the general relative value of B-pyramid versus MB-Tree? Since they're exclusive choices for the moment, any sense on what the appropriate choice would be.MB-tree is at least 10 times more useful.

[benwaggoner]

MB-tree is at least 10 times more useful.
That's a big difference!

And not entirely unsurprising; the content where pyramid-B would be useful is continent where MB-tree would be easily as useful.

In fact, I suppose one properly tinted glasses could see MB-tree as a macroblock-level implementation of what pyramid-B does on the frame level given.

[akupenguin]

In fact, I suppose one properly tinted glasses could see MB-tree as a macroblock-level implementation of what pyramid-B does on the frame level given.
No. B-pyramid keeps some pixels for predicting others, that would otherwise be thrown away. MB-tree moves bits into the pixels that will be used for predicting others, but doesn't change which those are. Other than that both are related to inter prediction (as is half of the rest of the codec), I don't see a relation.
And not entirely unsurprising; the content where pyramid-B would be useful is continent where MB-tree would be easily as useful.
Meaning, content that isn't intra-only?

[benwaggoner]

No. B-pyramid keeps some pixels for predicting others, that would otherwise be thrown away. MB-tree moves bits into the pixels that will be used for predicting others, but doesn't change which those are. Other than that both are related to inter prediction (as is half of the rest of the codec), I don't see a relation.
Fair enough

Meaning, content that isn't intra-only?
Well, more specifically content where inter prediction yields good matches, and in turn are good matches for future predictions.

[djesteban]

Guys... please help me understand... when I look at the x264 wiki page (http://mewiki.project357.com/wiki/X264_Settings#b-pyramid)
and look at the b-pyramid section... it display 3 choices: none, strict and normal. Though, when I try to set it in meGUI, it seems I am only able to choose between 0 and 1 (true and false)...
So..hmmm... how the hell do I specify between strict and normal... I would've guess the command for it would've been b-pyramid=2, but maybe I am just confused... So why is meGUI not giving me the option between those 3 choices and only between true or false?!?!

[kemuri-_9]

So why is meGUI not giving me the option between those 3 choices and only between true or false?!?!

the Simple answer: megui is outdated and broken with recent x264 builds.
use another gui that is being maintained or use x264 via cli

[djesteban]

the Simple answer: megui is outdated and broken with recent x264 builds.
use another gui that is being maintained or use x264 via cli

ok, but I was right with the fact that there's now an extra choice and that it use to be only a boolean right?
BTW... how did it work before
Was it only none or normal, or none or strict... just curious, thanks

[kemuri-_9]

the commit log contains your answer (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e2659dbdc0aed2d2cd4f6538faddf370e7740ada)

[Xavius]

now, finally, it is possible to use both MB-Tree and B-Pyramid

so:
what does it happen, using them both?
(Dark Shikari, previously, talked about the chance that b-Pyramid strict can mess-up something if used with MB-Tree....)

[LoRd_MuldeR]

now, finally, it is possible to use both MB-Tree and B-Pyramid

so:
what does it happen, using them both?
(Dark Shikari, previously, talked about the chance that b-Pyramid strict can mess-up something if used with MB-Tree....)

MB-Tree + B-Pyramid do work flawlessly now (AFAIK with both Pyramid modes). One effect seems to be that x264 tends to use more B-Frames overall.

[julius666]

MB-Tree + B-Pyramid do work flawlessly now (AFAIK with both Pyramid modes). One effect seems to be that x264 tends to use more B-Frames overall.

Does that mean good or bad (or neutral), quality wise?

[wyti]

that mean x264 think that using more bframe is good.
Don't know if it's really what sould be done, but using mbtree + b-pyramid give an overall better quality than mb-tree only

[LoRd_MuldeR]

Generally we should assume the B-Pyramid gives an advantage over no B-Pyramid, otherwise there would be no reason for B-Pyramid to exists.

The same thing applies to MB-Tree. Therefore we can further assume that B-Pyramid + MB-Tree combined are even better than either B-Pyramid or MB-Tree alone.

Last but not least, if B-Adapt 2 decides to use more B-Frames, we can assume that it does so, because more B-Frames are beneficial in that case.

[Wishbringer]

we can further assume that B-Pyramid + MB-Tree combined are even better than either B-Pyramid or MB-Tree alone.

I have added b-pyramid strict to my Ripbot encodes and see some speedwise changes i didn't expect:

C:\>"C:\Program Files (x86)\RipBot264\tools\avs2yuv\pipebuf.exe" "C:\Program Files (x86)\RipBot264\tools\avs2yuv\avs2yuv.exe" "C:\temp\RipBot264temp\job9\job9.avs" -raw - : "C:\Program Files (x86)\RipBot264\tools
\x264\x264_x64.exe" --pass 1 --bitrate 2540 --stats "C:\temp\RipBot264temp\job9\job9.stats" --fps 25 --frames 72225 --sar 1067:1000 --profile high --preset veryslow --tune film --slices 4 --level 4.0 --keyint 24
--min-keyint 2 --aq-mode 2 --b-pyramid strict --aud --nal-hrd --vbv-bufsize 32768 --vbv-maxrate 25000 --direct auto --output "C:\temp\RipBot264temp\video.264" - 720x576 : 2

x264 [info]: 720x576 @ 25.00 fps
x264 [info]: using SAR=1067/1000
x264 [warning]: VBV bitrate (25000) > level limit (20000)
x264 [warning]: VBV buffer (32768) > level limit (25000)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile Main, level 4.0
C:\temp\RipBot264temp\job9\job9.avs: 720x576, 25 fps, 72225 frames
x264 [info]: frame I:3339 Avg QP:13.00 size: 58327
x264 [info]: frame P:16907 Avg QP:16.39 size: 21735
x264 [info]: frame B:51979 Avg QP:18.33 size: 6603
x264 [info]: consecutive B-frames: 2.4% 3.6% 19.6% 13.5% 11.0% 48.9% 0.7% 0.3% 0.1%
x264 [info]: mb I I16..4: 22.7% 0.0% 77.3%
x264 [info]: mb P I16..4: 31.3% 0.0% 0.0% P16..4: 61.5% 0.0% 0.0% 0.0% 0.0% skip: 7.2%
x264 [info]: mb B I16..4: 5.6% 0.0% 0.0% B16..8: 36.6% 0.0% 0.0% direct:24.3% skip:33.4% L0:27.3% L1:42.5% BI:30.2%
x264 [info]: final ratefactor: 12.70
x264 [info]: direct mvs spatial:100.0% temporal:0.0%
x264 [info]: coded y,uvDC,uvAC intra: 63.0% 78.7% 41.4% inter: 27.6% 32.6% 3.0%
x264 [info]: i16 v,h,dc,p: 31% 19% 32% 19%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 15% 18% 7% 8% 8% 7% 8% 7%
x264 [info]: Weighted P-Frames: Y:2.6%
x264 [info]: kb/s:2507.29
encoded 72225 frames, 39.82 fps, 2507.29 kb/s

C:\>"C:\Program Files (x86)\RipBot264\tools\avs2yuv\pipebuf.exe" "C:\Program Files (x86)\RipBot264\tools\avs2yuv\avs2yuv.exe" "C:\temp\RipBot264temp\job9\job9.avs" -raw - : "C:\Program Files (x86)\RipBot264\tools\x264\
x264_x64.exe" --pass 2 --bitrate 2540 --stats "C:\temp\RipBot264temp\job9\job9.stats" --fps 25 --frames 72225 --sar 1067:1000 --profile high --preset veryslow --tune film --slices 4 --level 4.0 --keyint 24 --min-keyint 2
--aq-mode 2 --b-pyramid strict --aud --nal-hrd --vbv-bufsize 32768 --vbv-maxrate 25000 --direct auto --output "C:\temp\RipBot264temp\video.264" - 720x576 : 2

x264 [info]: 720x576 @ 25.00 fps
x264 [info]: using SAR=1067/1000
x264 [warning]: VBV buffer (32768) > level limit (31250)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.0
x264 [info]: frame I:3339 Avg QP:15.39 size: 50538
x264 [info]: frame P:16907 Avg QP:17.23 size: 24091
x264 [info]: frame B:51979 Avg QP:19.76 size: 6566
x264 [info]: consecutive B-frames: 2.4% 3.6% 19.6% 13.5% 11.0% 48.9% 0.7% 0.3% 0.1%
x264 [info]: mb I I16..4: 4.8% 85.1% 10.1%
x264 [info]: mb P I16..4: 1.8% 27.7% 1.8% P16..4: 32.3% 15.5% 12.3% 0.8% 0.9% skip: 6.8%
x264 [info]: mb B I16..4: 0.3% 3.8% 0.2% B16..8: 43.9% 1.8% 2.6% direct: 7.3% skip:40.2% L0:31.1% L1:43.8% BI:25.1%
x264 [info]: 8x8 transform intra:87.6% inter:63.2%
x264 [info]: direct mvs spatial:95.9% temporal:4.1%
x264 [info]: coded y,uvDC,uvAC intra: 88.5% 87.7% 58.2% inter: 24.5% 26.8% 6.0%
x264 [info]: i16 v,h,dc,p: 24% 14% 17% 44%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 12% 31% 5% 6% 7% 6% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 11% 7% 9% 13% 14% 11% 11% 11%
x264 [info]: Weighted P-Frames: Y:2.7%
x264 [info]: ref P L0: 69.0% 10.1% 15.2% 3.3% 1.6% 0.5% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: ref B L0: 92.3% 5.3% 1.7% 0.5% 0.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: ref B L1: 95.4% 4.6%
x264 [info]: kb/s:2540.25
encoded 72225 frames, 11.96 fps, 2540.25 kb/s

Episodes before "--b-pryramid strict" took average 2:45 hrs to encode, now they are around 2:10 hrs.

I can't see a difference in quality, but I am somewhat worried about speed gain. It's nice, but how does it come?
Episodes are SD DVD content (22x 1082MB to fit onto BD-R),
x264 1373 x64 techouse

[Dark Shikari]

I didn't at all expect this, but the difference is huge with b-adapt 2. Because of the way the Viterbi analysis algorithm works, it seems that pyramid vastly improves lookahead performance.

600 frame video with --b-adapt 2 --b-pyramid none --bframes 3:

L0 MBs analyzed: 3781008
L1 MBs analyzed: 2832192
Bidir MBs analyzed: 5661216

600 frame video with --b-adapt 2 --b-pyramid normal --bframes 3:

L0 MBs analyzed: 3781008
L1 MBs analyzed: 1889712
Bidir MBs analyzed: 2832192

Holy crap. No wonder it's a ton faster. This would be a good reason to make b-pyramid default.

[Sharc]

Holy crap. No wonder it's a ton faster. This would be a good reason to make b-pyramid default.
Would it adversely affect standalone player (blu-ray, AVCHD) compatibility?

[Atak_Snajpera]

Does xbox360 support b-pyramid?

[Dark Shikari]

Do note you will have to re-check every single device and player for B-pyramid compatibility, since all the old tests were done before the new B-pyramid.

Anything that supports Blu-ray should support B-pyramid, at a minimum.

[shon3i]

Do note you will have to re-check every single device and player for B-pyramid compatibility, since all the old tests were done before the new B-pyramid.

Anything that supports Blu-ray should support B-pyramid, at a minimum.
What B-pyramid normal exactly does to break compatibility? incrase b-frames?

[Sharc]

Do note you will have to re-check every single device and player for B-pyramid compatibility, since all the old tests were done before the new B-pyramid.

Anything that supports Blu-ray should support B-pyramid, at a minimum.
Noted, thanks. The speed gain is impressive.

[Dark Shikari]

What B-pyramid normal exactly does to break compatibility?Nothing. It should work fine.

[shon3i]

Nothing. It should work fine.
Then why we have strict and normal? what things can normal can change during encoding which can result out of specs stream? DBP is incrased?

[juGGaKNot]

read the wiki.

[Fr4nz]

I didn't at all expect this, but the difference is huge with b-adapt 2. Because of the way the Viterbi analysis algorithm works, it seems that pyramid vastly improves lookahead performance.

[...]

Holy crap. No wonder it's a ton faster. This would be a good reason to make b-pyramid default.

Let's make it default then :D

[shon3i]

read the wiki.
There is no technical stuff on wiki. I ask Dark, what is difference then if he suggest to use Normal mode for Blu-Ray encodings. My question is then what normal mode can break which make stream violate blu-ray specification. What b-pyramid tend to do, incrase bframes, DBP or what else?

[LoRd_MuldeR]

Then why we have strict and normal? what things can normal can change during encoding which can result out of specs stream? DBP is incrased?

This should have the answer:

Make B-pyramid spec-compliant
The rules of the specification with regard to picture buffering for pyramid coding are widely ignored.
x264's b-pyramid implementation, despite being practically identical to that proposed by the original paper, was technically not compliant. Now it is.

Two modes are now available:
1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.

So "strict" should only be needed when targeting for BluRay, as it requires further restrictions over the H.264 standard.

Fully H.264 compliant decoders should handle the "normal" mode perfectly fine now...

[Sharc]

Here my test results for a crf encode of 169'800 frames

--crf 19.15 --preset medium --level 4.0 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --me umh --aud --vbv-bufsize 14500 --vbv-maxrate 17500 --b-pyramid strict --threads auto --thread-input --tune film

a) No b-pyramid: Encoding duration 2:45:24
b) --b-pyramid strict: Encoding duration 2:44:18

Not much speed difference in this case.

[Fr4nz]

Here my test results for a crf encode of 169'800 frames

--crf 19.15 --preset medium --level 4.0 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --me umh --aud --vbv-bufsize 14500 --vbv-maxrate 17500 --b-pyramid strict --threads auto --thread-input --tune film

a) No b-pyramid: Encoding duration 2:45:24
b) --b-pyramid strict: Encoding duration 2:44:18

Not much speed difference in this case.

As DS said, you have considerable performance improvements if you use b--adapt 2; see here:

http://forum.doom9.org/showpost.php?p=1352301&postcount=35

[Sharc]

As DS said, you have considerable performance improvements if you use b--adapt 2; see here:

http://forum.doom9.org/showpost.php?p=1352301&postcount=35
Hmmm... I am about to repeat the test with --b-adapt 2.
The speed improvement of --b-pyramid seems still not to be too exciting. Maybe it depends on other factors?

[LoRd_MuldeR]

Hmmm... I am about to repeat the test with --b-adapt 2.
The speed improvement of --b-pyramid seems still not to be too exciting. Maybe it depends on other factors?

Use "--b-adapt 2" and "--bframe 16" ;)

[Sharc]

Use "--b-adapt 2" and "--bframe 16" ;)
Ah yes, the speed-killer combo!
But as far as I know --bframe 16 would be beyond Blu-Ray specs. I may have to try with my standalone what it accepts.
Anyway, it seems that even for Blu-ray compliant settings of --bframes 3 the --b-pyramid compensates the speed loss of b-adapt 2 compared to b-adapt 1.

[LoRd_MuldeR]

AFAIK there should be no encoder-side limit on consecutive B-Frames. Also with B-Adapt 2 and B-Pyramid enabled, significant more B-Frames are useful:

[B-Pyramid: normal]
x264 [info]: frame I:1
x264 [info]: frame P:43
x264 [info]: frame B:156
x264 [info]: consecutive B-frames: 0.5% 7.0% 12.1% 14.1% 20.1% 15.1% 3.5% 16.1% 0.0% 5.0% 0.0% 0.0% 6.5% 0.0% 0.0%

[B-Pyramid: none]
x264 [info]: frame I:1
x264 [info]: frame P:66
x264 [info]: frame B:133
x264 [info]: consecutive B-frames: 2.5% 23.1% 31.7% 14.1% 15.1% 6.0% 3.5% 4.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

[Trahald]

What B-pyramid normal exactly does to break compatibility? incrase b-frames?
Its what it doesnt do. It leaves bframes in the dpb after the mini-gop is over. bluray doesnt allow p frames referencing b frames and doesnt allow b frames to reference B refs that arent next to it (the h264 spec does .)

I P B b b P B b b P...
0 4 2 1 3 8 6 5 7 12
ref frame 2 is removed during frame 8
ref frame 6 is removed during frame 12
with b-pyramid strict. with b-pyramid normal the frames are not removed early (until they get forced out in order later)

[nurbs]

Do you know why they implemented it like that on blu-ray? What's the benefit?

[Dark Shikari]

Do you know why they implemented it like that on blu-ray? What's the benefit?You can guarantee (as long as there are B-frames) are relatively effective fast-forward capability, since you can simply drop all B-frames.