Shoud 2/3 pass CBR performance really be this bad?!

[Blue_MiSfit]

Hey all,

I'm trying to do some batch CBR encoding, and I'm having a bear of a time getting x264 to produce reasonably CBR files on a relatively short source.

The source is an MPEG-2 trailer, ~15mbps CBR, 480p24, about 2:30 in duration, and overall mediocre quality.

My process is this:

1) I'm targeting 3 streaming bitrates, so I do the first pass targeting the middle bitrate, CBR (in this case, 1264 for video)


--pass 1 --bitrate 1264 --stats ".stats" --level 4.1 --bframes 3 --b-adapt 2 --weightb --subme 2
--partitions none --vbv-bufsize 1264 --vbv-maxrate 1264 --me dia --threads auto --thread-input


Then I do the secondpass + thirdpass encodes for each bitrate target (774, 1264, and 1754kbps CBR)


program --pass 2 --bitrate 1264 --stats ".stats" --level 4.1 --ref 3 --bframes 3 --b-adapt 2
--weightb --subme 9 --trellis 1 --psy-rd 1.0:0.2 --partitions all --8x8dct --vbv-bufsize 1264
--vbv-maxrate 1264 --me umh --threads auto --thread-input



program --pass 3 --bitrate 1264 --stats ".stats" --level 4.1 --ref 3 --bframes 3 --b-adapt 2
--weightb --subme 9 --trellis 1 --psy-rd 1.0:0.2 --partitions all --8x8dct --vbv-bufsize 1264
--vbv-maxrate 1264 --me umh --threads auto --thread-input


When all's said and done, here are the bitrate numbers I get:

For vanilla 2 pass encoding:

774
avg=752 UNDERSHOOT
max=1166 OVERSHOOT

1264
avg=1228 UNDERSHOOT
max=1709 OVERSHOOT

1754
avg=1703 UNDERSHOOT
max=2329 OVERSHOOT

For 3 pass encoding:
774
avg=749 UNDERSHOOT
max=943 OVERSHOOT

1264
avg=1228 UNDERSHOOT
max=1716 OVERSHOOT

1754
avg=1703 UNDERSHOOT
max=2331 OVERSHOOT

So, it looks like 3 pass helped in most cases, but the stream is still not very CBRish :)

Any suggestions?

~MiSfit

[Dark Shikari]

Sounds like someone needs a primer on how VBV works ;)

[Blue_MiSfit]

Man, why is it that I can't seem to wrap my damned head around all this nonsense!? Even after you gave me a lecture...

The numbers I generated regarding avg + max bitrates came from DGAVCIndex - for the record...

:)

[Dark Shikari]

Man, why is it that I can't seem to wrap my damned head around all this nonsense!? Even after you gave me a lecture...

The numbers I generated regarding avg + max bitrates came from DGAVCIndex - for the record...

:)You can only measure avg/max bitrate properly if you measure it with the same bufsize and initial VBV occupancy that the encoder used.

If x264 doesn't print an underflow message, maxrate never, ever exceeded your limitation.

[Blue_MiSfit]

That makes sense! I wonder how DGAVCIndex works then?!

I should be capturing the stderr for all the passes!

Looks like I get to run these encodes again.

If I use neuron2's VBVChecker app, and supply the appropriate values, I do get errors about underflow.

For example, on my 774kbps encode, if I supply buffer size = 774000, initial fill = 696600 (90% of 774k) bit rate = 774000, and frame rate=23.976, it reports:

UNDERFLOW frame size 176656 bits, underflow 9132 bits.

I'll re-run this, and save the sderr outputs.

~MiSfit

[akupenguin]

You can only measure avg/max bitrate properly if you measure it with the same bufsize and initial VBV occupancy that the encoder used.
Nitpick: you don't need to fix vbv-init (an analyser can tell you its minimum value too). And you can also not fix bufsize, but then you'll get a bitrate-vs-bufsize curve rather than a single value.

[Blue_MiSfit]

Okay, so I did 3 encodes (2 passes only this time, with a shared first pass)

x264 did not report any underflow, but VBVChecker is still reporting underflow :(

I'm not sure how to determine who's right!

Here's the giant dump...

Firstpass
x264.exe "SD_TRAILER_2ch.avs" --pass 1 --stats ".stats" --bitrate 1264 --bframes 3 --b-adapt 2 --weightb --subme 2 --partitions none --vbv-bufsize 1264 --vbv-maxrate 1264 --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output NUL
avis [info]: 720x480 @ 23.98 fps (3651 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.0
x264 [info]: slice I:122 Avg QP:15.85 size: 18152
x264 [info]: slice P:1316 Avg QP:20.20 size: 10554
x264 [info]: slice B:2213 Avg QP:21.83 size: 3564
x264 [info]: consecutive B-frames: 3.0% 17.0% 69.5% 10.5%
x264 [info]: mb I I16..4: 64.1% 0.0% 35.9%
x264 [info]: mb P I16..4: 34.0% 0.0% 0.0% P16..4: 55.6% 0.0% 0.0% 0.0% 0.0% skip:10.4%
x264 [info]: mb B I16..4: 9.3% 0.0% 0.0% B16..8: 26.3% 0.0% 0.0% direct:21.3% skip:43.1% L0:31.9% L1:48.3% BI:19.9%
x264 [info]: coded y,uvDC,uvAC intra:48.0% 67.7% 25.8% inter:21.7% 30.7% 2.1%
x264 [info]: kb/s:1260.4

encoded 3651 frames, 54.05 fps, 1260.57 kb/s




Second Pass - 774kbps

x264.exe "SD_TRAILER_2ch.avs" --pass 2 --stats ".stats" --bitrate 774 --bframes 3 --b-adapt 2 --weightb --subme 9 --8x8dct --trellis 1 --psy-rd 0.9:0.2 --vbv-bufsize 774 --vbv-maxrate 774 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output 774.264
avis [info]: 720x480 @ 23.98 fps (3651 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: slice I:122 Avg QP:19.92 size: 12998
x264 [info]: slice P:1316 Avg QP:23.82 size: 6798
x264 [info]: slice B:2213 Avg QP:26.02 size: 1833
x264 [info]: consecutive B-frames: 3.0% 17.0% 69.5% 10.5%
x264 [info]: mb I I16..4: 37.9% 55.0% 7.1%
x264 [info]: mb P I16..4: 5.5% 11.1% 0.9% P16..4: 46.7% 11.4% 5.5% 0.0% 0.0% skip:18.9%
x264 [info]: mb B I16..4: 0.4% 0.7% 0.0% B16..8: 33.5% 1.0% 1.2% direct: 2.1% skip:61.0% L0:35.0% L1:59.5% BI: 5.5%
x264 [info]: 8x8 transform intra:60.5% inter:84.7%
x264 [info]: coded y,uvDC,uvAC intra:53.6% 68.8% 21.0% inter:16.4% 25.2% 1.4%
x264 [info]: kb/s:766.4

encoded 3651 frames, 52.66 fps, 766.59 kb/s



Second Pass - 1264 kbps

x264.exe "SD_TRAILER_2ch.avs" --pass 2 --stats ".stats" --bitrate 1264 --bframes 3 --b-adapt 2 --weightb --subme 9 --8x8dct --trellis 1 --psy-rd 0.9:0.2 --vbv-bufsize 1264 --vbv-maxrate 1264 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output 1264.264
avis [info]: 720x480 @ 23.98 fps (3651 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: slice I:122 Avg QP:17.21 size: 20368
x264 [info]: slice P:1316 Avg QP:21.08 size: 10961
x264 [info]: slice B:2213 Avg QP:23.21 size: 3143
x264 [info]: consecutive B-frames: 3.0% 17.0% 69.5% 10.5%
x264 [info]: mb I I16..4: 23.0% 68.9% 8.1%
x264 [info]: mb P I16..4: 3.9% 19.2% 1.4% P16..4: 42.0% 15.2% 7.6% 0.0% 0.0% skip:10.7%
x264 [info]: mb B I16..4: 0.5% 1.7% 0.1% B16..8: 35.2% 1.9% 2.1% direct: 4.3% skip:54.2% L0:35.6% L1:53.5% BI:11.0%
x264 [info]: 8x8 transform intra:75.8% inter:78.2%
x264 [info]: coded y,uvDC,uvAC intra:71.8% 74.7% 35.2% inter:23.8% 33.2% 2.9%
x264 [info]: kb/s:1253.8

encoded 3651 frames, 45.03 fps, 1253.93 kb/s



Second Pass - 1754kbps

x264.exe "SD_TRAILER_2ch.avs" --pass 2 --stats ".stats" --bitrate 1754 --bframes 3 --b-adapt 2 --weightb --subme 9 --8x8dct --trellis 1 --psy-rd 0.9:0.2 --vbv-bufsize 1754 --vbv-maxrate 1754 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output 1754.264
avis [info]: 720x480 @ 23.98 fps (3651 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
x264 [info]: slice I:122 Avg QP:15.21 size: 27235
x264 [info]: slice P:1316 Avg QP:19.47 size: 14726
x264 [info]: slice B:2213 Avg QP:21.50 size: 4715
x264 [info]: consecutive B-frames: 3.0% 17.0% 69.5% 10.5%
x264 [info]: mb I I16..4: 12.5% 79.9% 7.6%
x264 [info]: mb P I16..4: 3.0% 27.0% 1.7% P16..4: 35.6% 16.3% 8.9% 0.0% 0.0% skip: 7.5%
x264 [info]: mb B I16..4: 0.5% 4.1% 0.1% B16..8: 34.4% 2.6% 3.1% direct: 6.4% skip:48.9% L0:34.4% L1:49.0% BI:16.6%
x264 [info]: 8x8 transform intra:84.5% inter:72.9%
x264 [info]: coded y,uvDC,uvAC intra:81.5% 77.0% 47.2% inter:29.2% 37.9% 4.4%
x264 [info]: kb/s:1740.8

encoded 3651 frames, 40.06 fps, 1741.02 kb/s



~MiSfit

[Blue_MiSfit]

Guys.. am I just being really stupid here, or is there potentially a problem?

~MiSfit

[Guest]

I can comment only if you post a link to the stream that underflows with VBV Checker. Don't cut off the user data that shows me the x264 options used!

Why do you specify such a small VBV buffer? Trying to force a real CBR is a fool's game.

[Sergey A. Sablin]

Why do you specify such a small VBV buffer? Trying to force a real CBR is a fool's game.

since when 1 second buffer is called "small"?

[Guest]

x264 does not hit the required VBV model compliance exactly in this application. To allow for that, such that a subsequent VBV check passes, one can specify the buffer size a little larger than theoretically required. My reference to small referred to this extra margin; setting it to too close to theoretical = "too small".

[Sergey A. Sablin]

x264 does not hit the required VBV model compliance exactly in this application. To allow for that, such that a subsequent VBV check passes, one can specify the buffer size a little larger than theoretically required. My reference to small referred to this extra margin; setting it to too close to theoretical = "too small".

I'm not sure what you mean by theoretical here - but minimum theoretically possible buffer size is always avg_bitrate / fps, which gives you strict CBR with all frames of equal size.
For given examples this is 1264 / 23.98 and 774 / 23.98 respectively. I guess that buffer size which is almost 24 times larger than theoretical minimum should be considered big enough. Or at least not considered "small".

[Dark Shikari]

x264 does not hit the required VBV model compliance exactly in this application. To allow for that, such that a subsequent VBV check passes, one can specify the buffer size a little larger than theoretically required. My reference to small referred to this extra margin; setting it to too close to theoretical = "too small".Wrong; I tested x264 yesterday with constant-framesize VBV and it worked correctly. It did require two modifications though: one to remove the VBV size limitation (it currently cuts you off at 3 frames' size VBV) and removing the limitation of "no frame can be larger than half the remaining VBV." And even in one-pass mode with no lookahead, it worked pretty well (http://mirror05.x264.nl/Dark/force.php?file=./constantframesize.h264).

[Guest]

It did require two modifications though Exactly my point.

My tests show the bitrate as coming out somewhat above what is asked for. It's not a lot, but it's enough to make VBV Checker fail if you test for exactly the bitrate that you asked for.

[Dark Shikari]

Exactly my point.Disabling a sanity check on commandline options hardly counts as a modification, and the other was trivial.

And now I'm confused as to what you're talking about--this thread is about a 1 second VBV. You're talking about a 1 frame VBV or something close to it.

Of course x264 "meets the required VBV model compliance" for a 1 second VBV, unless you're trying to throw more FUD around as usual.

[Guest]

I'm talking about Blue's application. He wants an exact CBR and is trying to achieve it with x264 options. I've already said to him in PM that it negates the idea of VBV but he thinks his application requires it.

I'm not throwing FUD and I don't do it "as usual". You can get a rule 4 strike for stuff like that. Knock it off!

[Dark Shikari]

I'm talking about Blue's application. He wants an exact CBR and is trying to achieve it with x264 options. I've already said to him in PM that it negates the idea of VBV but he thinks his application requires it.Er, what? Do you mean constant framesize? Because this isn't it, this is 1 second VBV:

--vbv-bufsize 1264 --vbv-maxrate 1264

I've talked with blue for hours upon hours and worked for his company: I know what he's doing, and it is not constant framesize.I'm not throwing FUD and I don't do it usually. You can get a rule 4 strike for stuff like that. Knock it off!It seems like you are when you complain about x264's supposed inability to encode with constant framesize in a thread that is not about constant framesize. At the very least, it's off-topic IMO--you should at least make clear why the complaint is relevant.

[Guest]

Blue told me in PM that he is trying to achieve CBR in the sense of "real" CBR, not just a VBV model. Even the thread title specifies CBR.

[Dark Shikari]

Blue told me in PM that he is trying to achieve CBR in the sense of "real" CBR, not just a VBV model. Even the thread title specifies CBR.He told me on IRC that he was trying to achieve CBR in terms of internet-streaming CBR with a VBV model, not "real" CBR. Anyways, regardless of what he actually wants, the latter is completely insane for streaming purposes and requires intra-only or intra-refresh to be practical.

Since I know exactly what Blue is trying to do in practical terms (internet streaming VOD), I suspect he got confused when he PM'd you ;)

[Guest]

That's why I called it "a fool's game" in my first post!

All I'm suggesting is that for the options used, x264 can create an insignificantly larger bitrate than you asked for.

[Trahald]

...not sure if this is relevant but x264 produces type I hrd streams which only consider picture data for its vbv model. I assume either this is allowed because the variation is so small, or type I hrd applications dont buffer non slice data.

the hrd patch (will be version 12 whenever i diff it) considers the extra data in the real buffer tracking since type II hrd streams must consider everything, even the aud.

[Guest]

It sure sounds relevant to me! That explains the bitrate discrepancy.

[Blue_MiSfit]

Wow, there's been quite a bit of discussion since I posted this :)

You're all right, I was quite confused, everything is fine now!

~MiSfit

[benwaggoner]

He told me on IRC that he was trying to achieve CBR in terms of internet-streaming CBR with a VBV model, not "real" CBR. Anyways, regardless of what he actually wants, the latter is completely insane for streaming purposes and requires intra-only or intra-refresh to be practical.
It seems like VBV CBR is the "real CBR." If people start calling fixed frame size CBR "real CBR" than they'll ask for it, which would be bad. There should be a different and faintly embarassing name for this to discourage interest, along the lines of Uranus.

Is there any practical utility to fixed frame size, outside of ultra-low latency like videoconferencing?

[Sharktooth]

surveillance for example. or any other case of low latency real-time streaming.