How to get x264 to vary the bitrate more?

[Dark Shikari]

"qcomp Default: 0.60
Quantizer curve compression factor. 0.0 => Constant Bitrate, 1.0 => Constant Quantizer. Note that adaptive quantization partially replaces the effect of qcomp and x264 will internally raise qcomp to compensate based on the adaptive quantization strength.

http://mewiki.project357.com/wiki/X264_Settings#qcompIs it supposed to surprise me that an unofficial guide is wrong/outdated?

[movmasty]

Sharktooth told me to set a buffer size. --vbv-buffsize is not a value.
Both max rate and buffer affects the real bitrate, a larger buffer permits a bitrate higher than the max for sometime
the VBV max could be hold also for all the movie, the buffer permits to go higher for some second,
0 buffer mens that each frame cant have higher bitrate than the max, that thus is a real max
a buffer equal to the max admits a bitrate double than the max for one second.

your device should specify both max and buffer
i have red 24000 per ps3, 15000 per xbox360 e.g.

[movmasty]

Is it supposed to surprise me that an unofficial guide is wrong/outdated?
I have asked for a not outdated guide, replied to me to do a search,

the search gave that result.

[ajp_anton]

I find it funny that you assumed the guide has more correct info than what's in Dark Shikari's posts, and kept referring to the guide as facts instead of accepting that something there is wrong and asking what that is.
Did you notice the "x264 developer"? =)


0 buffer mens that each frame cant have higher bitrate than the max, that thus is a real max
a buffer equal to the max admits a bitrate double than the max for one second.
I don't see how bufsize=0 can exist.
With any other bufsize (even =maxrate) you can have an infinitely high spike with an area (b/s * s) equal to the bufsize. The height is limited by the minimum width though (duration of a frame, 1/fps), and requires 0-byte frames around it, so this will never happen. But there's nothing that says anything about double bitrate.

[Manao]

But there's nothing that says anything about double bitrateNot quite. Over a period of time T, if the buffer starts empty and ends full, you'll have encoded bufsize + T * maxrate bits. That gives the formula for max bitrate over the period T : (bufsize + T * maxrate) / T, ie maxrate + bufsize / T. If we define buf_duration by bufsize / maxrate, then we have max bitrate over T = maxrate * (1 + buf_duration / T). So the max bitrate over a period that lasts the VBV duration is double the maxrate.

[ajp_anton]

Ah.. yes, forgot that the buffer starts empty (well, just didn't cross my mind).
And, well, that "one second" is for only one of the seconds in the movie, I thought he meant for each of them =)

[movmasty]

I find it funny that you assumed the guide has more correct info than what's in Dark Shikari's posts, and kept referring to the guide as facts instead of accepting that something there is wrong and asking what that is.
Did you notice the "x264 developer"? =)
Hi ajp :cool:

I don't see how bufsize=0 can exist.
With any other bufsize (even =maxrate) you can have an infinitely high spike with an area (b/s * s) equal to the bufsize. The height is limited by the minimum width though (duration of a frame, 1/fps), and requires 0-byte frames around it, so this will never happen. But there's nothing that says anything about double bitrate.
Bufsize=0 can exist by setting it to 0, it is never used, it is called an ideal experiment with euristics finalities..., a little like your 'infinitely high spike'

your formula (b/s * s) is wrong

The max framesize is obviously equal to the buffer size, that gives, on a per second base a bitrate of buffer*fps,
this is the only case that your formula gives a value the same as the true

But the general 'area' of the spikes is vbvbuffer/s *s + vbvmax*(s-1/fps)

this is not a regolar rectangle, so better do no speak of area and use numbers instead,
and unuseful to semplify the first member that when more than one frame is involved, isnt a rectangle itself

dont need any 0 frames around it, because the buffer can get empty during the encoding, just need a low bitrate area before the spike,
and after it there is the space vbvmax/fps that goes out of the buffer everytime a new frame gets encoded

[movmasty]

And, well, that "one second" is for only one of the seconds in the movie
No, you could have one second of double max rate every time that the buffer gets empty, the max number of that seconds is when we assume that all other frames are empty, so in my example of vbvbuffer=vbvmax, the buffer gets empty every second, thus you could have one second of double max rate every two.

So a movie 1 sec 0 - 1sec double max rate, is perfectly cbr compliant.

Now dont tell me that you are a buffer-spikes developer....

[movmasty]

But the general 'area' of the spikes is vbvbuffer/s *s + vbvmax*(s-1/fps)
.............
and after it there is the space vbvmax/fps that goes out of the buffer everytime a new frame gets encoded

Btw, for who is curios to know what 'vbv' means, google states it is 'verified by Visa'

so dont forget your card when making encodes.

[Manao]

movmasty, ajp_anton : you both obviously don't know what you're talking about and how a VBV works. A VBV can become empty if locally the bitrate is low enough for a long enough time. It can become full if the bitrate is high enough for a long enough time. And the formula I gave to compute the maximum bitrate over a period T is correct. Basically, it says the shorter T is (in comparison to the VBV duration), the larger the maximum bitrate (over T) can be. And the longer T is, the closer to the VBV maxrate the maximum bitrate will be.

[movmasty]

movmasty, ajp_anton : you both obviously don't know what you're talking about and how a VBV works. A VBV can become empty if locally the bitrate is low enough for a long enough time. It can become full if the bitrate is high enough for a long enough time. And the formula I gave to compute the maximum bitrate over a period T is correct. Basically, it says the shorter T is (in comparison to the VBV duration), the larger the maximum bitrate (over T) can be. And the longer T is, the closer to the VBV maxrate the maximum bitrate will be.
and this is what im saying too, how do you think that i found that value of double max rate??
in the ideal case that new encoded frames will have 0 size, or almost, the video buffering verifier buffer will lose the fixed amount of bytes(vbvmax/fps) at every new frame,
this means that a buffer equal to the vbvmax will get empty in one second,
this is the max, ideal, speed to empty the buffer ACCORDING TO YOUR FORMULA that i'm using

But your formula is wrong to be precise, it is not 'bufsize + T * maxrate bits'

it is 'bufsize +( T-1/fps) * maxrate bits'

because the max size per one frame is=buffer, not buffer +1/fps*maxrate

thus when both max and buffer are equal to 5mb, at 25 fps the max rate allowed will be 9,8mb, not 10.

vbvbuffer/s *s + vbvmax*(s) is exactly your formula transported in the area dimension that ajp was using

vbvbuffer/s *s + vbvmax*(s-1/fps) has the correct time as explained above

[Manao]

My bad, I should have read your posts [a bit] more attentively. Your formula is correct, and mine is just an approximation that assumes infinite framerate.

[movmasty]

mine is just an approximation that assumes infinite framerate.

will be correct also marking the first frame of a serie at time 0, as usual, then the Nth frame will have time T'=T-1

[ajp_anton]

Now dont tell me that you are a buffer-spikes developer....No I'm not. The closest to anything VBV-like I've come is to write some numbers in x264.
Which is why I have no experience in calculating anything with it, even though I myself think I somewhat understand the basics on how it works.
However, I tend to forget simple but important details even about things I should know everything about, and just mess it up even more when trying to fix my mistakes. Like here I first assumed the buffer is always full, but in that case there can never be any spikes of any kind (right?).