Why does b-adapt 1 look better than b-adapt 2?

[STaRGaZeR]

I was doing some tests with x264 when I noticed something I don't quite understand, related to b-adapt. I'll explain.

The sample is an anime Blu-ray clip. The command line is fairly trivial, with default settings except a 1 second GOP, aq-mode 2 and psy-rd at 0. Encoding the same clip with b-adapt 1 and b-adapt 2 results in the following stats. Notice that I lowered b-adapt 2's crf to match b-adapt 1 final bitrate. I used a high crf to show the issue more clearly, but at lower crf values the effect is the same, only less noticeable.

C:\Users\STaRGaZeR\Desktop>x264 --b-adapt 1 --crf 25 --keyint 24 --min-keyint 1
--deblock 0:0 --psy-rd 0.0:0.0 --aq-mode 2 a.mkv -o testb1.mkv
lavf [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ
CNT BMI2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:82 Avg QP:23.11 size: 59266
x264 [info]: frame P:774 Avg QP:26.68 size: 15813
x264 [info]: frame B:319 Avg QP:27.67 size: 2221
x264 [info]: consecutive B-frames: 55.3% 24.0% 4.3% 16.3%
x264 [info]: mb I I16..4: 30.1% 56.7% 13.3%
x264 [info]: mb P I16..4: 9.6% 13.9% 1.6% P16..4: 13.3% 3.0% 0.8% 0.0% 0
.0% skip:57.8%
x264 [info]: mb B I16..4: 0.5% 0.6% 0.1% B16..8: 6.9% 0.8% 0.1% direct:
0.5% skip:90.6% L0:51.2% L1:45.9% BI: 2.9%
x264 [info]: 8x8 transform intra:55.7% inter:77.5%
x264 [info]: coded y,uvDC,uvAC intra: 26.6% 36.6% 14.1% inter: 4.1% 3.4% 0.3%
x264 [info]: i16 v,h,dc,p: 46% 23% 10% 21%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 14% 28% 5% 4% 4% 4% 5% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 17% 18% 7% 9% 7% 6% 6% 3%
x264 [info]: i8c dc,h,v,p: 61% 16% 17% 6%
x264 [info]: Weighted P-Frames: Y:4.5% UV:4.1%
x264 [info]: ref P L0: 60.9% 10.6% 21.1% 6.7% 0.6%
x264 [info]: ref B L0: 81.9% 17.4% 0.8%
x264 [info]: ref B L1: 98.6% 1.4%
x264 [info]: kb/s:2906.91

encoded 1175 frames, 60.98 fps, 2907.03 kb/s

C:\Users\STaRGaZeR\Desktop>x264 --b-adapt 2 --crf 24.5 --keyint 24 --min-keyint
1 --deblock 0:0 --psy-rd 0.0:0.0 --aq-mode 2 a.mkv -o testb2.mkv
lavf [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ
CNT BMI2
x264 [info]: profile High, level 4.0
x264 [info]: frame I:59 Avg QP:21.95 size: 63488
x264 [info]: frame P:441 Avg QP:26.11 size: 23326
x264 [info]: frame B:675 Avg QP:27.70 size: 5665
x264 [info]: consecutive B-frames: 16.1% 12.6% 28.1% 43.2%
x264 [info]: mb I I16..4: 33.2% 52.5% 14.3%
x264 [info]: mb P I16..4: 13.5% 24.0% 3.2% P16..4: 10.8% 2.9% 0.8% 0.0% 0
.0% skip:44.8%
x264 [info]: mb B I16..4: 1.6% 1.9% 0.2% B16..8: 11.2% 1.9% 0.3% direct:
1.1% skip:81.7% L0:45.7% L1:50.9% BI: 3.4%
x264 [info]: 8x8 transform intra:56.7% inter:77.2%
x264 [info]: coded y,uvDC,uvAC intra: 28.5% 38.5% 15.3% inter: 3.9% 3.4% 0.3%
x264 [info]: i16 v,h,dc,p: 46% 23% 10% 21%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 15% 27% 6% 4% 5% 4% 5% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 17% 18% 7% 9% 7% 6% 6% 3%
x264 [info]: i8c dc,h,v,p: 60% 16% 17% 6%
x264 [info]: Weighted P-Frames: Y:6.1% UV:5.4%
x264 [info]: ref P L0: 60.1% 10.2% 22.2% 7.0% 0.5%
x264 [info]: ref B L0: 86.1% 11.0% 2.9%
x264 [info]: ref B L1: 93.0% 7.0%
x264 [info]: kb/s:2914.88

encoded 1175 frames, 46.73 fps, 2915.00 kb/s

Original: http://www.mediafire.com/?vvrz718n26bxyf5

b-adapt 1 encoded sample: http://www.mediafire.com/?prkmyo8lixkn8aj

b-adapt 2 encoded sample: http://www.mediafire.com/?ay7d02hsqizt6o1

The question is: why does b-adapt 1 look better? If you see the file in motion, you'll notice less artifacts and mosquito noise around the edges overall. If you look at the stats, the number of I, P and B frames used differ significantly, b-adapt 2 using close to twice the number of B frames. These are way more efficient, and in this kind of clip they should boost perceived quality, but that's not the case. I always use a bit of sharpening (unsharp mask in ffdshow, strength 20) which amplifies the artifacts. These two screenshots below are taken with the sharpening applied.

b-adapt 1: http://img854.imageshack.us/img854/7870/ho9e.png

b-adapt 2: http://img41.imageshack.us/img41/8875/iqu3.png

[Keiyakusha]

Personally I think that none of them is worse or better. They are too similar to be bothered. I really doubt you can tell the difference in motion, even if you'll look in the right spots with most obvious distortions that you noted beforehand.
Frame by frame I probably like badapt2 more, like in frames 145 and 260, which are P and B frames respectively (if I looked at the right encode when noted frametype, but this doesn't really matters anyway)
Also B-frames are low-quality frames. So if there is twice as much of them it is more likely that you'll be comparing B frame in one file with frame of some other type in different file. B-frames are not boosting quality of some single frame, they do the opposite. On a larger scale it should be more efficient and boost perceived quality but maybe this is what they do, just you and the algorithm "perceive" it differently?

However, to be honest, I find that many x264 features tuned for "perceived quality" to be destructive for anime in cases when you're doing something better than bitrate-starved encode. Or actually not only features but the whole concept of crf (lower quality for high motion scenes/macroblocks? - no thanks! I want constant quality for all scenes regardless of what one can "perceive" in motion). Maybe not relevant to your case as 3mbps is a pretty low bitrate for 1080p packed with details like stars etc.

P.S.
Haven't checked anything about unsharp mask and don't have ffdshow installed at all, but this is one of the worst things possible for anime. With such a powerful CPU you really should be using some better stuff. This is if you think it needs sharpening at all, which I find to be a bit strange.

[STaRGaZeR]

When I found this "issue" I was testing with CRF 18-20, go figure. It's a lot easier to see in motion for me, b-adapt 2 is more "dirty", more artifacts around the edges. In a clip with this amount of scene changes and speed, you can't really focus on most things. That's why I see it a lot better in motion, when artifacts move around fast. That said, this source is so blurred that without sharpening it's difficult to see anything. But sharper sources are consistent with this one.

B frames are lower quality, yes, but using a lot more B frames (again, close to twice) saves quite a few bits, which can be used elsewhere. Remember both files end up the same size. The fact that they look roughly the same to you and b-adapt 2 worse to me is an indicative that something is going on: b-adapt 2 should consistently look better overall, and it doesn't. Just where are the saved bits going? The background? The flat areas? I thought this could be because of mb-tree, but disabling it only makes it worse. Then I thought that maybe I could boost the quality of B frames via --pbratio, but --pbratio and mb-tree can't be used together.

I just find a touch of unsharp mask the most pleasant to my eyes. Slower algorithms either look worse to me or close to unsharp, but with the added computational cost. All in all is the best option for me, as in videos that need sharpening to look good (like this one, the original is so blurry it looks a lot better with it) I just enable it with a keyboard shortcut, and for other content I disable it just as fast.

[hello_hello]

Looking at the screen captures I'd agree with what you're saying (I haven't looked at the video samples), however some thoughts (from someone who rarely encodes animation).....

Does the result change if you use the x264 default settings for animation? ie --tune animation

A quick play with MeGUI's x264 encoder configuration seems to indicate the effect of --tune animation on x264's default settings is to use --deblock 1:1, --bframes 5, --ref 7 (each x264 speed preset seems to set those values to something higher than they otherwise would be without --tune animation), --aq-strength 0.7, --psy-rd 0.40:0.00, plus unless you specify otherwise, it'd be something like --keyint 240 --min-keyint 24 and aq-mode 1.

As I said, I rarely encode animation but I did find myself wondering if --b-adapt 1 and --b-adapt 2 would still produce different results when --tune animation is used, or for that matter if --tune animation would do a better job than using x264's default settings.

Not that I use sharpening much (I generally don't like it) but if I was to use any of ffdshow's sharpening it'd be asharp. It's an adaptive unsharp mask filter which means it might be able to do the same sharpening, better. A threshold of zero should mean it does nothing (I think negative values blur). With the adaptive sharpening at zero, "threshold" should work like "strength" does for unsharp mask. If memory severs me correctly, unsharp mask with a strength of 32 and asharp with a threshold of 1 and adaptive sharpening on zero should produce the same result. And of course asharp has block adaptive sharpening (works with adaptive sharpening enabled), although I think it should only be used for mod8/mod16.
Sometimes when converting HD to SD I use asharp with a threshold of 1 and adaptive sharpening on 3, but for me it's not animation.

[STaRGaZeR]

It changes a bit, but the difference between b-adapt 1-2 still remains. Tune animation uses more ref and b-frames but since I'm limiting them to 3 manually it doesn't matter. Also lowers psy-rd, which I'm disabling already. aq-strength changes too, but that's just personal preference. The biggest difference is deblock, but a value of 1:1 is too high for my tastes.

I already knew about asharp, but the problem I have with it is that as soon as I enable adaptive sharpening it doesn't look like unsharp mask anymore.

[mandarinka]

Do you also get the same results 1) with psyrdo on (which is default) 2) with aq mode 1 (also default)?

[Marin85]

@OP: given your observations, if I may, I would suggest following: turn off --b-frames completely and increase the crf to match the bitrate of your other samples (all other settings equal) and see how you feel about it when you compare to your other two samples. I think you may be surprised.

[STaRGaZeR]

Do you also get the same results 1) with psyrdo on (which is default) 2) with aq mode 1 (also default)?

Same results. aq-mode 2 looks better than aq-mode 1 to me, and psy-rd 1.0 looks worse than 0.0 too. In all cases b-adapt 1 still had the lead.

@OP: given your observations, if I may, I would suggest following: turn off --b-frames completely and increase the crf to match the bitrate of your other samples (all other settings equal) and see how you feel about it when you compare to your other two samples. I think you may be surprised.

This is interesting. No bframes is both better and worse than b-adapt 1 depending on the frame. In motion I still prefer b-adapt 1 though, with no bframes there is a bit of frame pulsing. What strikes me the most is the little difference there is between no bframes, b-adapt 1 and b-adapt 2. I have to test this at higher bitrates.

[burfadel]

psy-rd at 1.00 is too strong for animation, psy-rd 0.6 is probably a better choice. Also a bit of psy-trellis (say, 0.05 - 0.10) may be beneficial when used in conjunction with deblocking at 1:1 with animation. Also, AQ strength is better a bit weaker with animation too, try around 0.6. For standard content, a psy-rd of 1.0 and trellis of 0.1 may be better, with the standard settings that you decide for the rest of the features. Also why not try me of UMH, subme 10, trellis on all blocks... slower encoding yes, but might as well make use of that CPU.

[STaRGaZeR]

psy-rd at 1.00 is too strong for animation, psy-rd 0.6 is probably a better choice. Also a bit of psy-trellis (say, 0.05 - 0.10) may be beneficial when used in conjunction with deblocking at 1:1 with animation. Also, AQ strength is better a bit weaker with animation too, try around 0.6. For standard content, a psy-rd of 1.0 and trellis of 0.1 may be better, with the standard settings that you decide for the rest of the features. Also why not try me of UMH, subme 10, trellis on all blocks... slower encoding yes, but might as well make use of that CPU.

While I appreciate your answer, that has nothing to do with b-adapt and why b-adapt 1 looks better than b-adapt 2 using the same settings :p

[LoRd_MuldeR]

First of all, b-adapt 2 is known to use more B-Frames than b-adapt 1. That's simply because b-adapt 2 actually finds the "optimal" number of consecutive B-Frames (up to the selected B-Frame limit), while b-adapt 1 uses a "fast" algorithm that, most of the time, selects a rather low number of consecutive B-Frames. Of course it also depends on the content. Cartoon-like stuff will usually use much more B-Frames than "film" footage.

Secondly, B-Frames should compress more efficiently than P-Frames, given they are put at the "suitable" position. Same goes for P-Frames versus I-Frames. So if all frame types had the "same quality", we would probably get sizeof(B) < sizeof(P) < sizeof(I). But you need to consider that B-Frames intentionally are made worse quality than P-Frames. The same way P-Frames intentionally are made worse quality than I-Frames. That's the P/B and the I/P ratio, respectively. And it makes sense, because B-Frames are not referenced by other frames (ignoring B-Pyramid for now), so it's not worth spending too many bits there. P-Frames are referenced by subsequent P-Frames as well as the B-Frames located in between, so it makes sense to spend some "extra" bits there, as this will help all subsequent frames too. I-Frames are the initial reference for the complete GOP, so they get the most "extra" bits, as this will improve the whole GOP.

So, if you compare frames "frame by frame", then it is perfectly normal that B-Frames look worse, when compared against the same frame encoded as a different frame type! That's why you can only really compare frames of the same type, as has been said many times. With b-adapt 2 you usually get more B-Frames and thus you probably are more often comparing B-Frames against Non-B-Frames in your "frame by frame" test. That's why b-adapt 2 may look "worse" at a first glance.

However the ultimate goal is to optimize the quality of the clip as a whole and when watching it in motion, not to win a "frame by frame" comparison ;)

(BTW: If you still think b-adapt 1 looks better than b-adapt 2, even when watching the complete clip in motion, maybe you should play with the P/B ratio a bit rather than using b-adapt 1 instead of adapt 2)

[Marin85]

Secondly, B-Frames should compress more efficiently than P-Frames, given they are put at the "suitable" position.
Well, "suitable" is what so funny about it. Because it totally makes sense to have two consecutive and visually nearly identical frames encoded with vast difference in perceived visual quality :confused: The most funny thing is when you try to increase the bitrate from that point on.


Same goes for P-Frames versus I-Frames.
Not quite.


The same way P-Frames intentionally are made worse quality than I-Frames.
It is the other way around. ip-ratio determines the quality of the I-frames, not P-frames. If you want, you can have I-frames with same quality as P-frames. I-frames need more bits not only because they serve as reference frames, but also because they are intra-coded, which is inefficient.


So, if you compare frames "frame by frame", then it is perfectly normal that B-Frames look worse, when compared against the same frame encoded as a different frame type!
That would mean that an encode without B-frames will look same or better than the B-frame encode at every frame that is a B-frame in the B-frame encode... Since the majority of frames in a B-frame encode are B-frames, this implies that an encode without B-frames should be overall better...


That's why you can only really compare frames of the same type, as has been said many times.
So, I can't compare an encode without B-frames with an encode with B-frames, or if I want to compare them, I am allowed to compare only the P-frames from the B-frame encode against the corresponding P-frames from the P-frame encode. Which does not make any sense, since the P-frames from the B-frame encode will obviously have much higher quality. Objective frame-by-frame comparison involves much more than that nonsense about 'same frame type only' people apply without even knowing why.

That's why b-adapt 2 may look "worse" at a first glance.
Hardly relevant. OP is talking about perceived quality, and perceived quality is all that should matter.

[LoRd_MuldeR]

It is the other way around. ip-ratio determines the quality of the I-frames, not P-frames. If you want, you can have I-frames with same quality as P-frames.

Whether you say I/P ratio improves the quality of I-Frames compared to P-Frames or if you say it worsens the quality of P-Frames compared to I-Frames, it means exactly the same thing ;)

(But to my understanding it basically is defined as a multiplier > 1.0 that is multiplied with the I-Frame's quantizer to determine the P-Frame's quantizer)

I-frames need more bits not only because they serve as reference frames, but also because they are intra-coded, which is inefficient.

Of course. If you encode the same input frame with same quantizer as I-Frame and as P-Frame, the I-Frame will usually be much larger. But, on top of that, P-Frames are made worse quality than I-Frame (or if you want to see it the other way around: I-Frames are made better quality then P-Frames) by increasing the quantizer values of the P-Frames (or the other way around: lowering the quantizer values of the I-Frames). This is also known as "Key-Frame Boost".

And the same principle applies to the B-Frames vs. P-Frames compression.

That would mean that an encode without B-frames will look same or better than the B-frame encode at every frame that is a B-frame in the B-frame encode

If we compare two encodes A and B with different frame type decisions, then every frame that has been encoded as B-Frame in A but has been encoded as a different type (P-Frame or I-Frame) in B, will probably look better in B. And, analogously, every frame that has been encoded as B-Frame in B but has been encoded as a different type (P-Frame or I-Frame) in A, will probably look better in A.

Doesn't say anything about "how much" those B-Frames look worse (or "how much the Non-B-Frames look better) though. And doesn't say anything about the "overall quality" of the clips either!

Conclusion: If you do frame-by-frame comparison, make sure you compare frames of the same type. And to judge overall quality, you better watch it in motion...

So, I can't compare an encode without B-frames with an encode with B-frames, or if I want to compare them, I am allowed to compare only the P-frames from the B-frame encode against the corresponding P-frames from the P-frame encode.

Exactly. At least it you want a meaningful comparison.

(If you compare the same frame, encoded as P-Frame in A and encoded as B-Frame in B, and you find it looks better in A, then you haven't learned anything)

[Marin85]

Whether you say I/P ratio improves the quality of I-Frames compared to P-Frames or if you say it worsens the quality of P-Frames compared to I-Frames, it means exactly the same thing ;)

(But to my understanding it basically is defined as a multiplier > 1.0 that is multiplied with the I-Frame's quantizer to determine the P-Frame's quantizer)
We are almost getting lost in semantics now :-) First of all, speaking of improving or worsening the quality of I-frames relative to P-frames (or vice versa) is a bad choice of words, because it leaves the reference effect unaccounted for, e.g. going from ip-ratio 1.0 to 1.4 (thus "worsening the quality of P-frames compared to I-frames" according to your words) will likely improve the absolute quality of both the I-frames and P-frames for reasons already mentioned previously. Secondly and back to my point, at same CQ, changing the ip-ratio will only change the I-frame quantizer, but not the P-frame quantizer. And since you are talking about ip and pb-ratios and quality, quantizer appears to be the only meaningful interpretation of "quality compared to" in this context.


And the same principle applies to the B-Frames vs. P-Frames compression.
Again, at same CQ, changing the pb-ratio will influence only the quantizers of B-frames, but not of P-frames.


If we compare two encodes A and B with different frame type decisions, then every frame that has been encoded as B-Frame in A but has been encoded as a different type (P-Frame or I-Frame) in B, will probably look better in B. And, analogously, every frame that has been encoded as B-Frame in B but has been encoded as a different type (P-Frame or I-Frame) in A, will probably look better in A.
I think you missed my point here. I gave you one rather extreme counter-example where the logic "same frame type" fails miserably, in particular a counter-example to your statement: "So, if you compare frames "frame by frame", then it is perfectly normal that B-Frames look worse, when compared against the same frame encoded as a different frame type!"


Conclusion: If you do frame-by-frame comparison, make sure you compare frames of the same type.
Again same counter-example: what if the encode you are comparing against does not have B-frames? (see below)


Marin: "So, I can't compare an encode without B-frames with an encode with B-frames, or if I want to compare them, I am allowed to compare only the P-frames from the B-frame encode against the corresponding P-frames from the P-frame encode"

Exactly. At least it you want a meaningful comparison.

No, that was precisely the counter-example. Since your B-frame encode has so many B-frames, the P-frames from it will likely look noticeably better than the corresponding (P-)frames from the encode without B-frames. However, this is misleading, because the majority of frames in the B-frame encode will be B-frames, which can look pretty shitty (thus leaving much more bits for P-frames in the B-frame encode). Yet, following your suggested logic, I am not allowed to obtain information for the bigger part of the encodes.


(If you compare the same frame, encoded as P-Frame in A and encoded as B-Frame in B, and you find it looks better in A, then you haven't learned anything)
Depends.

The point is that if you ever need to obtain information about the quality of some encodes based on comparison of individual frames, the whole 'logic' of "same frame-type nazis" completely disregards elementary statistics considerations, namely the percentage of P-frames vs. B-frames in each encode and the consistency of quality for P-frames and B-frames across the encode, at which B-frames can fail pretty badly. Let alone certain correlations with the source codec.

[LoRd_MuldeR]

We are almost getting lost in semantics now :-)

Remember that you started with the hairsplitting.

Whether you improve the I-Frame relative to the P-Frame or whether you worsen the P-Frame alternative to the I-Frame, it is the same thing.

Still you insisted that only the former is correct :rolleyes:

Again, at same CQ, changing the pb-ratio will influence only the quantizers of B-frames, but not of P-frames.

Wrong. It changes the quantizer of the B-Frame relative to the P-Frame. Or in other words: It changes the quantizer of the P-Frame relative to the B-Frame.

Which one you regard as "fixed" (or as the reference) depends on your specific point of view.

"So, if you compare frames "frame by frame", then it is perfectly normal that B-Frames look worse, when compared against the same frame encoded as a different frame type!"

That is correct, yes.

Again same counter-example: what if the encode you are comparing against does not have B-frames?

What would happen? The clip with B-Frames probably would look a lot better overall - assuming both clips still have the same average bitrate, of course.

Though, in a (meaningless) frame-by-frame comparison, you may still find that its B-Frames look worse than the same frame (encoded as P-Frame or I-Frame) in the other "No B-Frames" clip.

Now I urge you to stop nitpicking and either contribute to the topic or not post at all!

[STaRGaZeR]

Lord, it'll be helpful if you actually read what I post instead of posting canned responses. This is a very specific and located "issue" I'm trying to get explained. Of course frame by frame comparisons are meaningless, but since the very first post it's made clear that overall, in motion AND in most frame by frame comparisons, b-adapt 1 looks better (for me at least) in this particular scenario despite having a lot less bframes. I only care about the final result in motion. I have played with ipratio, aq-mode, aq-strength, qcomp, mb-tree... and still find that b-adapt 1 looks better or, at least, equal to b-adapt 2, which is illogical given the saved bits thanks to the sheer number of bframes and their "optimal position" in the b-adapt 2 encode. You can check the encoded samples or download the original and do some encodes yourself.

Also, Marin is right. In x264, when you set --qp X you are setting the P frame quantizer, which will be fixed, and I-B quantizers are derived from your setting applying ipratio and pbratio. As he says, I-B quantizers are derived from the P quantizer, not the other way around. This is how it is, not a point of view.

PS: pbratio has no effect in my tests, as mb-tree is used.

[LoRd_MuldeR]

Lord, it'll be helpful if you actually read what I post instead of posting canned responses. This is a very specific and located "issue" I'm trying to get explained. Of course frame by frame comparisons are meaningless, but since the very first post it's made clear that overall, in motion AND in most frame by frame comparisons, b-adapt 1 looks better (for me at least) in this particular scenario despite having a lot less bframes. I only care about the final result in motion. I have played with ipratio, aq-mode, aq-strength, qcomp, mb-tree... and still find that b-adapt 1 looks better or, at least, equal to b-adapt 2, which is illogical given the saved bits thanks to the sheer number of bframes and their "optimal position" in the b-adapt 2 encode. You can check the encoded samples or download the original and do some encodes yourself.

As I said in my previous post: If you find that the encode with more consecutive B-Frames looks worse overall and when watching it in motion, then using b-adapt 1 instead of b-adapt 2 - just because it happens to use fewer consecutive B-Frames - doesn't really address the underlying problem, I think. Instead, I would rather try to adjust the P/B ratio. Maybe you could also try with/without B-Pyramid enabled.

If nothing else helps and you need to limit the number of consecutive B-Frames, you can simply set "--bframe" to a lower value. That's a more reliable/obvious "workaround" to limit the number of B-Frames.

Also, Marin is right. In x264, when you set --qp X you are setting the P frame quantizer, which will be fixed, and I-B quantizers are derived from your setting applying ipratio and pbratio. As he says, I-B quantizers are derived from the P quantizer, not the other way around. This is how it is, not a point of view.

If X is 1.5x greater than Y, then X is 1.5x greater than Y :p

Whether you express this as "X = 1.5 * Y" or equivalently as "Y = X / 1.5" changes absolutely nothing about the relation between X and Y. Neither the former nor the latter equation is more (or less) "correct".

The same way, the P/B ratio and I/P ratio refer to the relation between the P-/B-Frame quantizers and to the relation between the I-/P-Frame quantizers, respectively.

This is unrelated to whether - at a particular place in the code - X is derived from Y, or Y is derived from X. Also I did not say P-Frame quantizers are derived from I-Frame quantizers. Nor did I say the opposite!

I said that, if you increase the quality of I-Frames compared to P-Frames, then you therewith are making the quality of P-Frames worse compared to I-Frames (and vice versa). It is one and the same thing.

PS: pbratio has no effect in my tests, as mb-tree is used.

Well, did you try without MB-Tree then?

[IanB]

Strikes me the comparisons here are meaningless because the bit rate of the 2 samples is not the same. Of course the higher bit rate sample will "look" better. The game is getting visually acceptable results with a lower bit rate.

Presumably b-adapt 2 results in a smaller file size with the setting in use. For a fair comparison other setting should be adjusted to distribute the saved bits back into that encode so we are comparing same size files. Or adjust the settings to make the 2 encodes look the same then compare the file sizes.

[LoRd_MuldeR]

Well, according to the logs he posted above, both files came out pretty much at the same size (2907.03 kb/s vs. 2907.03 kb/s). And the b-adapt 2 one even has a slightly higher average bitrate.

[Stereodude]

Isn't the CRF setting supposed to sort it all out (ideally)?

IE: A CRF of 22 should visually look the same (in motion) regardless of which specific encoding options you're using. The resulting bitrate changes as the specific encoding options change, but the perceived visual quality is relatively constant.

[the_weirdo]

Isn't the CRF setting supposed to sort it all out (ideally)?

IE: A CRF of 22 should visually look the same (in motion) regardless of which specific encoding options you're using. The resulting bitrate changes as the specific encoding options change, but the perceived visual quality is relatively constant.

Actually, it isn't:
CRF does not mean "constant quality regardless of the settings you use".
CRF is not a measure of quality. It is an arbitrary point on the curve between quality and bitrate that is only "constant" at a certain combination of settings. If you change those settings, you move the point on the curve.

[LoRd_MuldeR]

Isn't the CRF setting supposed to sort it all out (ideally)?

IE: A CRF of 22 should visually look the same (in motion) regardless of which specific encoding options you're using. The resulting bitrate changes as the specific encoding options change, but the perceived visual quality is relatively constant.

Nope. CRF mode is far away from an accurate quality measure!

The same CRF value gives roughly the same quality for different sources, but only as long as no other influential settings are changed. As soon as you change your other settings, it also changes the "meaning" of the CRF values.

It has been discussed many times before why you can not compare different encoder settings in CRF mode. At least not simply by using the same CRF value with different settings and then comparing file sizes.

Instead you have to compare the quality of files with the same file size (i.e. the same average bitrate). This can be achieved more easily in 2-Pass mode. You can also adjust the CRF value, until both files come out at the same size.

Alternatively, it's also possible to generate files that visually look the same, e.g. by adjusting the CRF value until none of the files looks better (or worse). Then you can compare file sizes. But that's more difficult to do!

EDIT: the_weirdo was faster ;)

[STaRGaZeR]

As I said in my previous post: If you find that the encode with more consecutive B-Frames looks worse overall and when watching it in motion, then using b-adapt 1 instead of b-adapt 2 - just because it happens to use fewer consecutive B-Frames - doesn't really address the underlying problem, I think. Instead, I would rather try to adjust the P/B ratio. Maybe you could also try with/without B-Pyramid enabled.

If nothing else helps and you need to limit the number of consecutive B-Frames, you can simply set "--bframe" to a lower value. That's a more reliable/obvious "workaround" to limit the number of B-Frames.

Tried with b-pyramid on and off, results are more or less the same. Also read below for more tests.

The number of bframes is already capped at a low value (3, hardware limitation). Lowering this seems counter-productive, specially when no bframes at all is worse than any b-adapt mode.

If X is 1.5x greater than Y, then X is 1.5x greater than Y :p

Whether you express this as "X = 1.5 * Y" or equivalently as "Y = X / 1.5" changes absolutely nothing about the relation between X and Y. Neither the former nor the latter equation is more (or less) "correct".

The same way, the P/B ratio and I/P ratio refer to the relation between the P-/B-Frame quantizers and to the relation between the I-/P-Frame quantizers, respectively.

This is unrelated to whether - at a particular place in the code - X is derived from Y, or Y is derived from X. Also I did not say P-Frame quantizers are derived from I-Frame quantizers. Nor did I say the opposite!

That's correct, but you're missing the point. You said:

Wrong. It changes the quantizer of the B-Frame relative to the P-Frame. Or in other words: It changes the quantizer of the P-Frame relative to the B-Frame.

Which one you regard as "fixed" (or as the reference) depends on your specific point of view.

And this is just wrong: in the case of x264 if you set --qp 23 and --ipratio 1.4, P frame quantizer will be fixed at 23 and I frame quantizer will be something lower than 23. Now, if you set --qp 23 and --ipratio 1.6, P frame quantizer will still be fixed at 23, and I frame quantizer will be lower than before. Same with --pbratio. The reference is the P frame quantizer in all cases.

Well, did you try without MB-Tree then?

Yes. Tried playing with mbtree, ip and pb ratios, and even tweaked b-bias so b-adapt 2 uses comparable number of bframes to b-adapt 1. The result is always the same: b-adapt 2 always looks a little worse than b-adapt 1, my tweaks always result in worse quality than the defaults, and mbtree on beats mbtree off each and every time. It seems to distribute bits a lot better. So the best quality is still mbtree on + b-adapt 1 followed by mbtree on + b-adapt 2.

Strikes me the comparisons here are meaningless because the bit rate of the 2 samples is not the same. Of course the higher bit rate sample will "look" better. The game is getting visually acceptable results with a lower bit rate.

Presumably b-adapt 2 results in a smaller file size with the setting in use. For a fair comparison other setting should be adjusted to distribute the saved bits back into that encode so we are comparing same size files. Or adjust the settings to make the 2 encodes look the same then compare the file sizes.

Of course. But if you see the first post, crf is adjusted so that the final bitrate between the two is roughly the same. That's the whole point of the thread.

[LoRd_MuldeR]

And this is just wrong: in the case of x264 if you set --qp 23 and --ipratio 1.4, P frame quantizer will be fixed at 23 and I frame quantizer will be something lower than 23. Now, if you set --qp 23 and --ipratio 1.6, P frame quantizer will still be fixed at 23, and I frame quantizer will be lower than before. Same with --pbratio. The reference is the P frame quantizer in all cases.

If you increase the quantizers of the P-Frames relative to the quantizers of I-Frames, then you therewith decrease the quantizers of the I-Frames relative to the quantizers of P-Frames. And if you would decrease the quantizers of the P-Frames relative to the quantizers of the I-Frames, then you therewith would increase the quantizers of I-Frames relative to the quantizers of P-Frames. That's what I said. And I stand correct.

What you say about the implementation detail of x264's QP mode is correct and I did not say otherwise. Actually it's perfectly in accordance to what I said. Whether you start with the P-Frame quantizer and divide it trough 1.4, or whether you start with the I-Frame quantizer and multiply it by 1.4, the end result is exactly the same: In the end the P-Frame quantizer will be 1.4x greater than the I-Frame quantizer. And that's what the I/P ratio is. The choice to make the "--qp" command-line interface option of x264 specify the P-Frame quantizer (and derive the I-Frame quantizers from that) is completely arbitrary, though perfectly reasonable. End of story.


As this thread seems to encourage nitpicking about pointless details, this is the last warning! Any more of this, and I will have to close the thread...

[Stereodude]

Nope. CRF mode is far away from an accurate quality measure!

The same CRF value gives roughly the same quality for different sources, but only as long as no other influential settings are changed. As soon as you change your other settings, it also changes the "meaning" of the CRF values.Thanks for the replies and education guys. Do the QP values listed at the end of an encode have a similar shift as you change the encoding parameters?

[LoRd_MuldeR]

Do the QP values listed at the end of an encode have a similar shift as you change the encoding parameters?

Not quite sure what "shift" you are expecting to see. Those are the actual QP values (should be the average of all macro-blocks of all frame of the particular frame-type) that have been used in the encode. CRF mode does not use fixed quantizers, but instead adapts the quantizers to the content. Though, the interface of x264 was designed in a way that a CRF value of X will result in an average quantizer of roughly X.

This is never really accurate. But it is quite possible that it is more (or less) accurate with some settings than with others.

Aside from that, the average QP values are not a useful "quality indicator" anyway. Just think about AQ, as one example. With AQ enabled, the quantizers in some blocks are decreased, while the quantizers in other blocks are increased. The average QP should remain pretty much the same as without AQ. Still, the visual difference can be stunning!

[Stereodude]

Not quite sure what "shift" you are expecting to see. Those are the actual QP values (should be the average of all macro-blocks of all frame of the particular frame-type) that have been used in the encode. CRF mode does not use fixed quantizers, but instead adapts the quantizers to the content. Though, the interface of x264 was designed in a way that a CRF value of X will result in an average quantizer of roughly X.

This is never really accurate. But it is quite possible that it is more (or less) accurate with some settings than with others.

Aside from that, the average QP values are not a useful "quality indicator" anyway. Just think about AQ, as one example. With AQ enabled, the quantizers in some blocks are decreased, while the quantizers in other blocks are increased. The average QP should remain pretty much the same as without AQ. Still, the visual difference can be stunning!What I meant was if you encode the same source multiple times at a constant bitrate (2 pass VBR) using different encoding settings, can you use the QP values at the end to make any sort of judgements about the efficiency of the compression? From your statement I gather that the meaning of a QP of say 18 isn't changed by the encoding settings though I understand your point that you can have two drastically different looking versions of the same frame that both have the same QP.

[STaRGaZeR]

As this thread seems to encourage nitpicking about pointless details, this is the last warning! Any more of this, and I will have to close the thread...

What? This is a joke, right? It's you, not me or anybody else, who are writing most of the offtopic text here. Just read the thread. I even had to tell you to read the first post because what you posted didn't make any sense in the context of the thread. Don't close it because you don't like something you are doing in the first place :rolleyes:

Now please, stop the offtopic and back to the original question: after all the tests, why does b-adapt 1 still look better than b-adapt 2 in this scenario?

[LoRd_MuldeR]

~closed for rule #4 and rule #11~