x264 two-pass ratecontrol less accurate in latest version?

[paulvdb]

After upgrading x264 from r1373 to r1376 I've noticed that my two-pass encodes are usually between 2 and 3 kbit/s lower than the target bitrate. With r1373 the difference between target bitrate and real bitrate was usually less than 1 kbit/s. I noticed in the change log that some changes were made in ratecontrol. Could those changes have made it less accurate?

[LoRd_MuldeR]

I'd say hat 2 or 3 kbit/s are a very minor deviance, no reason for concern ;)

Anyway: How many frames does your sample clip have? Testing 2-Pass mode with short clips may be misleading here!

Oh, and how do you "read" the average bitrate of the resulting stream?

[paulvdb]

I tested it with complete episodes from BBC HD. Those episodes are 30 or 60 minutes long at 25fps. When x264 finishes encoding it reports the average bitrate. With r1373 and earlier that used to be within 1 kbit/s from the target bitrate. It's not a big deal, but I noticed that when I upgraded to r1376 it was usually 2-3 kbit/s lower than the target bitrate and in one or two cases even more.

[LoRd_MuldeR]

Well, did you also compare the quality? With the recent change in 2-Pass mode, the size of the ABR buffer was increased. It now scales with the number of threads. So 2-Pass has more "freedom" now, which may explain why it's slightly less precise than before. However I'd say that this is perfectly okay, if the quality did increase or at least remain unchanged. According to the commit message, the quality was improved significantly, in some cases (with multiple threads). Also: If we talk about HD stuff, how many percent is 3 kbps in this case? I mean, 3 kbps for a 15 mbps video would be 0.02% and hence negligible.

[paulvdb]

15 mbps would be higher bitrate than the source material. I usually encode to 1280x720 at 3-4 mbit so it is still less than 0.1%. I'm not complaining. I was just curious about the cause and wanted to know if it was a bug or a feature. Thanks for explaining that.

[Dark Shikari]

This is intentional.

Previously, it tried to get so close that it would cause quality problems in some situations.

[prOnorama]

I noticed a similar thing: about 3-4 Kbits lower bitrate on 3 720p encodes than specified. On a 1080p encode even 15 Kbits ( --bitrate 14456 came out as 14439.26). I do note that I used --no-mbtree and --weightp 0. I guess it's nothing to worry about (oversizing would be a problem on the other hand, if you encode for target size to fit on a medium).

[bob0r]

Dark, i have gotten some reports, and seen it myself, that x264 indeed undersizes.
I guess r1375 is the cause?

commit c9cafc75352f036bdcb90f2a26e7233920567b13 r1375
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Fri Dec 11 17:22:18 2009 -0800
Fix two bugs in 2-pass ratecontrol

What solution to make x264 hit the 2 pass target size again?

Edit:
Also unrelated but: "why does subme 8 have lower ssim and psnr than subme 7"
Where should i ask this question? :)

[Dark Shikari]

Dark, i have gotten some reports, and seen it myself, that x264 indeed undersizes.
I guess r1375 is the cause?

commit c9cafc75352f036bdcb90f2a26e7233920567b13 r1375
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Fri Dec 11 17:22:18 2009 -0800
Fix two bugs in 2-pass ratecontrol

What solution to make x264 hit the 2 pass target size again?It hits the 2-pass size just fine. If you want it to hit the size within 0.1% instead of within 0.5% at the risk of serious quality problems in larger frames, lower ratetol. Or just use fewer threads.Edit:
Also unrelated but: "why does subme 8 have lower ssim and psnr than subme 7"
Where should i ask this question? :)Same reason subme 7 has lower ssim and psnr than 6, and 6 has lower than 5: psy optimizations.