Real CBR x264 settings?

[gumimaci]

Hi

I'd like to create real cbr x264 coded movie.
I try to use vbv-maxrate vbv-bufsize and ratetol 0.1 options, but the result is vbv and the bitrate is very fluctuate.
If i use --qcomp option the movie isn't playable.
I use these settings:

x264 -B 400 --vbv-maxrate 400 --vbv-bufsize 400 --ratetol 0.1 -o foo.mp4 foo.avs

with these setting the bitrate sometimes go over 500 kbit/s.

How can i make real cbr movie?

[DarkZell666]

This question has already been answered many times, and a typical answer would be to try the following things (and/or combinaisons) :

1) Change MinQP to 1 and MaxQP to 100 (allows VERY ugly degradation of the picture to respect the specified bitrate)
2) use --qcomp 0.0
3) use --ratetol 0.0 (not 0.1, but this may be some disinformation, I'm not sure if 0.0 is a valid value)

--qcomp shouldn't affect the "readibility" of the video, this option should be rather stable by now :/

Anyway, try step 1 in addition to your settings, this should suffice :)

[akupenguin]

--qcomp 0 should help.
--ratetol 0 is invalid, and will tell you so if you try.
Changing minqp won't help, and maxqp defaults to the highest possible value.

How do you measure bitrate when you say 500kbit/s? Does x264 report "VBV underflow"?

[Blue_MiSfit]

I'm just curious as to what exactly would require / benefit from such an outdated rate control mode?

[gumimaci]

Thank you for the answers.
maxqp 100 solve my problem.
I got some VBV underflow messages, but i raise vbv-bufsize and it disappear.

[akupenguin]

maxqp 100 solve my problem. The fact that maxqp=100 does anything at all is a bug, and will be fixed shortly. It certainly shouldn't solve your problem.
I got some VBV underflow messages, but i raise vbv-bufsize and it disappear.
You still haven't answered why you want CBR in the first place. If arbitrarily changing vbv-bufsize is even an option for you, then CBR isn't what you should use. If you really needed CBR, then you would have decided the necessary values of vbv-maxrate and vbv-bufsize before encoding, and not changed them.
Hint: the VBV underflow messages aren't something you can just fix. They're telling you that x264 used more bits than you asked it to. If you increase vbv-bufsize, that just tells x264 that it's ok to be more lax in the constantness of bit allocation, so the same variation as before would no longer trigger a warning.

[gumimaci]

I want to use x264 for streaming. That's why i want cbr.
I noticed that vbv-bufsize don't affect the bitrate.
When i got VBV underflow message the picture quality was very bad.
--qcomp 0 option produce a quite good cbr result.
What is the optimal vbv-maxrate vbv-bufsize size.
I use --vbv-maxrate 400 --vbv-bufsize 1000.
Is these correct?

[akupenguin]

vbv-maxrate should be equal to your bandwidth (or maybe slightly less if you want to be sure).
vbv-bufsize should be as large as possible, but the streaming client must use an equally large buffer. 1000 may be a reasonable value if you don't know what your media player uses.

[DarkZell666]

The fact that maxqp=100 does anything at all is a bug, and will be fixed shortly. It certainly shouldn't solve your problem.


Hmm, what is the link between maxqp, minqp and the --qcomp parameter then ? *gettings really curious about this*

I found logical that MaxQP should solve the problem, since it is normal
that a very complex frame should be compressed more for it to fit with it's <GOP-size> neighbours in a GOP that has a fixed size. (Not very correct sentence but you get the idea I guess). Limiting MaxQP to 51 would mean "well, whatever the complexity of the frame, you can't compress it more than that, so tough : it'll take up more space"

Up to what extent does --qcomp alterate this statement ?

akupenguin, please explain ^^

[Kopernikus]

The biggest allowed quantizer is 51, so h.264 cannot compress any further.
But because of the exponential quantizer scale 51 compresses very very strong.

[DarkZell666]

The biggest allowed quantizer is 51, so h.264 cannot compress any further.
But because of the exponential quantizer scale 51 compresses very very strong.

Is 51 defined in the h264 specs ? Or are you just talking about the default max setting in x264vfw ? *sceptical*

[Kopernikus]

No, its in the specs.

[krasi0]

gumimaci, Is it VLC u use to streaming h264 video with? Because I see no qcomp parameter in `vlc -H --advanced` though there are options vbv... Maybe in VLC --sout-x264-tolerance equals to qcomp?

[Riki]

This is such an old thread but its the best I could find in the search. I tried this outdated technique in my testing but it doesnt seem to work anymore, unless Im missing something. Is it still possible with x264 to encode a CBR or near CBR?

[Dark Shikari]

This is such an old thread but its the best I could find in the search. I tried this outdated technique in my testing but it doesnt seem to work anymore, unless Im missing something. Is it still possible with x264 to encode a CBR or near CBR?It's always been possible. As long as maxrate == bitrate and bufsize is set, x264 will encode CBR. There's nothing else to it; there's even an example in the help.

[Riki]

Thanks, I think Im beginning to understand this. So if I set the bufsize to 1 its essentially caps it to my bitrate, in this case 200. If I set the bufsize higher, it allows for higher peaks because the buffer will be able to handle those peaks. So if I set the bufsize to 200, it caps the peaks to 300 kbps and so on.

What took me a while to understand was the buffer allowing for peaks and if your client buffer is set accordingly and the end users bandwidth is predictably high enough for the max bitrate, then the stream should never hitch.

Excellent job with all of this, its brilliant :)

[Dark Shikari]

Thanks, I think Im beginning to understand this. So if I set the bufsize to 1 its essentially caps it to my bitrate, in this case 200.Not really correct. The minimum possible buffer size is the size of a single frame (maxrate / fps), which would imply constant framesize encoding.

[benwaggoner]

Not really correct. The minimum possible buffer size is the size of a single frame (maxrate / fps), which would imply constant framesize encoding.
...and would look pretty lousy, particularly for I-frames.

The only codec I can think of that even kind of tried that strategy was Cinepak Pro, which used precisely fixed sizes for P-frames and a specified multiple of that for I-frames.

It wasn't a good RD strategy, but the improvements in motion estimation were big enough that most of the time it looked better than the old canonical Radius Cinepak encoder. But it could really freak out with fast pans, since those P-frames would be seriously bit-starved compared to even the old and relatively lousy 1-pass rate control mode.

When I did the first Mindstorms CD-ROM for Lego circa 1999, we actually did all the cut scenes in both version of Cinepak and just picked whichever version looked best.

[Blue_MiSfit]

While we're on the touchy subject - is it correct to believe that the only way to have "100% pure CBR" is to have the codec attempt constant framesize encoding, and the muxer pad as necessary?

@benwaggoner:

Cool story! :) Thanks for sharing! I'd always wondered more about the early days of video compression.

~MiSfit

[DarkZell666]

Constant BitRate => By definition, means "Allocate a constant amount it bits over a period N" (no matter what unit N is in nor how much of that unit it is). (Wiktionary : Rate (http://en.wiktionary.org/wiki/rate), definition n°1 says "An amount measured in relation to another amount.").

If you set the period to 1 hour, and you ask for a constant bitrate of 700,000 KBytes per hour, then a 1,400,000 KBytes file of 2 hours technically has a constant bitrate. Any one-second section of that file might have recieved either 5,000 Kbytes or 20KBytes, it doesn't matter, the statement is still correct : the file has constant bitrate over a one hour period.

If you set the period to 1 second, and you ask for a constant bitrate of 1,000 KBytes per second, then a 2,000 Kbytes file of two seconds technically has a constant bitrate. Any frame of that file might have recieved either 3 Kbytes or 10 Kbytes, it doesn't matter, the statement is still correct : the file has constant bitrate over a one second period.

If you set the period to 1/fps seconds (0.04s for 25fps), and you ask for a constant bitrate of 10 Kbytes per 1/fps seconds, then a 20 Kbytes of 2/fps seconds technically has a constant bitrate over a 1/fps seconds period, yes indeed. 1/fps being the shortest timeframe you can get using the fps unit, I can't go down further, but I assume you got my point ;)

[ocal5]

About this "max per frame" CBR, it cause troubles on every I frames (a least on very static pictures).
That's totaly normal.
Is there a way to make that different with Periodic Intra Refresh ?
I've made some trys (using VLC last snapshots), it sometimes works, but quite never when lookahead is off (in order to reduce delay).

Thanks for any clue.

[Dark Shikari]

About this "max per frame" CBR, it cause troubles on every I frames (a least on very static pictures).
That's totaly normal.
Is there a way to make that different with Periodic Intra Refresh ? --intra-refresh.

CRF + VBV is recommended over CBR when using intra refresh though.