--crf encoding producing larger files in new revisions

[MetalPhreak]

A while back I noticed that the file sizes of my crf encodes have gotten bigger, I'm also not talking about a bit, I'm talking like on one 30 minute ep that I tested it was bigger by 64Mb. I used exactly the same commandline for both encodes. I'm not sure exactly when this started happening but it was definitely between revision 604 an 617 - I missed a few revisions so I can't check any further.
So is this intended behavior? Was there some change to ratecontrol that I'm not aware of?
According to the log files all the newer revisions have much lower avg frame quants compared to older revisions. So yeah, was just wondering what's up with that?

[akupenguin]

older builds, so you can check exactly which revision it was.

Do only the quantizers differ, or also the numbers of I/P/B-frames?

[MetalPhreak]

Okay, it was between revision 606 and 609 (x264.nl doesn't have 607 or 608, so I can't narrow it down any further).

Here's the commandline I was using, just for reference:

x264.exe --crf 16 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --deblock 0:0 --subme 7 --trellis 2 --partitions all --8x8dct --direct spatial --me umh --sar 64:45 --progress --no-psnr --no-ssim --output "F:\enc\x264_test\605.mkv" "F:\test\size_test.avs"

Log for 606:

avis [info]: 704x544 @ 24.00 fps (849 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:6     Avg QP:12.33  size: 38654:00
x264 [info]: slice P:252   Avg QP:14.56  size: 11971
x264 [info]: slice B:591   Avg QP:16.09  size:  3362
x264 [info]: mb I  I16..4: 41.1% 36.4% 22.5%
x264 [info]: mb P  I16..4:  3.4%  4.9%  1.5%  P16..4: 44.7% 12.8%  6.1%  0.2%  0
.1%    skip:26.2%
x264 [info]: mb B  I16..4:  0.1%  0.2%  0.1%  B16..8: 24.4%  0.9%  2.6%  direct:
 5.2%  skip:66.4%
x264 [info]: 8x8 transform  intra:47.6%  inter:49.6%
x264 [info]: ref P  63.5% 17.9%  6.1%  4.3%  2.9%  2.4%  1.7%  1.2%
x264 [info]: ref B  76.3% 14.1%  4.3%  1.7%  1.2%  1.0%  0.8%  0.6%
x264 [info]: kb/s:1183.9

encoded 849 frames, 2.05 fps, 1184.14 kb/s

Log for 609:

avis [info]: 704x544 @ 24.00 fps (849 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:6     Avg QP:11.83  size: 41791:00
x264 [info]: slice P:377   Avg QP:12.84  size:  9152
x264 [info]: slice B:466   Avg QP:16.55  size:  4340
x264 [info]: mb I  I16..4: 42.7% 33.6% 23.7%
x264 [info]: mb P  I16..4:  2.3%  3.2%  1.0%  P16..4: 46.1%  8.8%  4.7%  0.2%  0
.1%    skip:33.8%
x264 [info]: mb B  I16..4:  0.2%  0.3%  0.2%  B16..8: 29.4%  1.1%  3.3%  direct:
 6.7%  skip:58.8%
x264 [info]: 8x8 transform  intra:46.2%  inter:42.7%
x264 [info]: ref P  72.7% 13.8%  4.6%  3.1%  1.9%  1.7%  1.2%  0.9%
x264 [info]: ref B  75.5% 15.0%  4.4%  1.7%  1.2%  1.0%  0.7%  0.6%
x264 [info]: kb/s:1294.3

encoded 849 frames, 1.97 fps, 1294.53 kb/s

Thanks for your quick reply akupenguin.

[akupenguin]

Ratecontrol has not changed, except in that it indirectly uses some results from B-adapt.
r607 did change B-adapt. It was only sort of intentional: I had to change some parts of the algorithm in order to implement threading, but I tried not to change the results.
If people conclude that quality-per-bitrate has suffered, I'll go and tweak it some more. Otherwise, just accept that CRF has changed scale (it always was arbitrary).

[MetalPhreak]

Thanks akupenguin, good to know that it isn't a "real" bug, I'll just play around 'till I find a crf value that works for me.