[x264-devel] Re: clarification on rate control

[Jeff Clagg]

On Wed, Apr 05, 2006 at 12:42:15PM -0700, Daniel Rogers wrote:

> Q1: So, in the rc struct the first four parameters (all prefixed with
> i_qp) are constant, min, max and step.  This is referred to CQP, which I
> assume means Constant QP.  Am I correct in noticing that this affects
> non-bitrate constrained video files and:

Yes, this affects non-bitrate constrained video files.

You have two choices: either constrain the quantizer only, or choose a
bitrate, and let IT choose the quantizers itself. This type of choice
isn't in any way specific to x264. Any encoder that offers ratecontrol
has to address these issues, usually in about the same way.

> qp is either constant or it is a range defined by "min" and "max", and
> the encoder is allowed to step up or step down qp between frames by the
> about "step?"

Yes, and it varies the qp in such a way as to meet the ratecontrol
target. (I'm ignoring crf)

> Q2: if I am correct about Q1, does that mean that you can reduce the bit
> rate of a constant qp file by increasing qp_min and qp_max and qp_step,
> as well as increase the bit rate by lowering min, max and step?

qp_min, qp_max, qp_step have no effect on a constant qp encode.

> Q3: if qp_constant is set, are min, max and step ignored?

Yes.

> Q2: Are the next block of parameters (cbr, bitrate, rf_constant,
> rate_tolerance, vbv_max_bitrate, vbv_buffer_size, vbv_buffer_init,
> ip_factor, bp_factor) are for a defined bitrate encoding, which is known
> only as VBR? (I see the abbreviation ABR too, but not in the header file
> and I don't know what it means).

Hey, you jumped back to two!

ip_factor and pb_factor both actually DO affect "constant qp" encodes as
well, so there's this little caveat that "constant qp" isn't TRULY
constant unless you set those factors to 1.0. As for the others, yes
they are for encodings with a defined bitrate, except for rf_constant,
which I'm still ignoring.

I don't think there's any really super official definition about what
VBR and ABR mean, but you've got the wrong idea.

VBR: bitrate VARIES. A constant qp encode is VBR.

ABR: Local bitrate vary, perhaps by arbitrary large amounts, but overall
there is some target average bitrate.

CBR: Local bitrate varies within constraints that are defined by
vbv_buffer size and vbv_max_bitrate.

> Q4:  What is rf_constant?

It's x264's attempt to implement a nice "constant quality" mode. No
target bitrate, but there is a target quality. QP still varies because
QP and quality aren't exactly the same thing.

> Q5: how does rate_tolerance affect the variability of the bitrate?  (e.g
> is it a percentange variability, or what?)

Wish I knew. Loren might reply to this.

> Q6: I get the feeling that the vbv_X parameters are the ones that are
> most powerful for controlling maximum bit rate.  I want to understand
> how to set a max bitrate in a file.  If my max_bitrate is, for example,
> 768, and I want the stream to be encoded as baseline (or main) level 1.3
> so for conformance I cannot _ever_ exceed this value, what length of
> vbv_buffer_size to I need to choose to ensure this happens?

I am pretty sure the spec addresses vbv buffer size (annex A). I'll let
you figure out whether I'm right or wrong ;) Note that just because your
decoder claims it supports level 1.3, doesn't mean it'll never tolerate
slightly out-of-bounds input...

> Essentially, I want ffmpeg (or QuickTime) to report that the bitrate of
> the file as more more than 768.  Another way of asking this question is,
> how is the bitrate of the entire stream caculated, and how to I pick a
> vbv_buffer_size and vbv_max_bitrate such that vbv_max_bitrate is greater
> than or equal to the bitrate of the entire file?

If vbv_buffer_size and vbv_max_bitrate are set, and you've requested a
bitrate < vbv_max_bitrate, you'll generally get this, although the
ratecontrol is not quite perfect and you may get buffer underflows in my
experience.

> Q7: My guess here is that the max 1 second long bit rate in the stream
> determines the bitrate of the entire stream. If so, does this mean that
> a vbv_buffer_size equal to one second at my desired max bitrate will
> suit me?  How does picking a larger or smaller vbv_buffer_size affect
> the final bitrate of the stream.  Also, as an important clarification,
> what are the units of vbv_buffer_size (ie bits or bytes)?

There's nothing special about 1 second.

vbv_max_bitrate determines max bitrate... why would you think the size
of vbv_buffer_size does?

x264.h's i_vbv_buffer_size is in bits. the x264 executable takes
arguments that are bits*1000 (kbits).

> Q8: How do vbv_max_bitrate and rate_tolerance affect each other?

They don't. rate_tolerance is for "abr" which ignores vbv_max_bitrate (I
think).

> Q9: I belive that vbv_buffer_init represents how "full" the vbv_buffer
> is considered at the beginning.  How is this value useful in limiting
> the bitrate?  My guess is that it keeps the bitrate from getting too
> high in the beginning.  Is this correct?

Not really useful for limiting the bitrate. Can possibly be used to
reduce initial decoder delay/wait time in "streaming" situations, I
guess.

> the next block (labeled 2pass) is obvious to me.
> 
> Q10: the 2pass params section doesn't make sense to me.  If anyone wants
> to clarify these, I'd be grateful.

b_stat_write: whether we're writing stats this pass
psz_stat_out: statsfile name
b_stat_read: whether reading stats this pass
psz_stat_in: statsfile name

The rest, to save myself some typing, I suggest reading somewhere else,
both xvid and libavcodec use the terms "qcomp" iirc, and I know
libavcodec uses qblur.

And now, the intrusive pushy part ;)

What exactly are you trying to achieve? What led you to ask all these
questions?

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html