[x264-devel] Re: [MOD] [PATCH] Rate control

Måns Rullgård mru at mru.ath.cx
Wed Aug 11 23:55:04 CEST 2004


Loren Merritt <lorenm at u.washington.edu> writes:

> On Wed, 11 Aug 2004, [iso-8859-1] Måns Rullgård wrote:
>> Is it non-working in some specific manner?
>
> Only when I accidently specified a really small buffer, and got
> minbits > maxbits.

That doesn't sound right.  Maybe emitting a warning if the buffer is
smaller than the fill rate would make sense.  There's no way to make
such a small buffer work anyway.

>> > -    rc->buffer_size = h->param.i_rc_buffer_size;
>> > +    rc->buffer_size = h->param.i_rc_buffer_size * 1000;
>>
>> That's just a matter of taste.  If I apply that I'll have change all
>> my configuration files to use kilobits instead.  Maybe guessing
>> whether the user was thinking in bits or kilobits based on the size of
>> the number would work.  What would be a reasonable threshold?  Is it
>> safe to assume that anything below 10000 is kilobits rather than bits?
>> The same method could be used for the bitrate.  Or would this just be
>> a bad case of trying to be smart?
>
> I don't really care whether it's bits or bytes or kb or kB, but
> buffer_size and bitrate should use the same size unit.

You have a point there.

> Actually, it might be better yet to specify buffer_size in seconds,
> which is more likely to be constant over a range of inputs.

That's why I set the default to half a second.

> And guessing probably isn't a good idea: What if I wanted to encode a HD
> movie at 10+ mbit/sec?

We could look at the frame size as well.  Encoding with more than 12
bits per pixel would be nonsensical, for instance.  It's still
probably a bad idea, though.

-- 
Måns Rullgård
mru at mru.ath.cx

-- 
This is the x264-devel mailing-list
If you are in trouble, please contact <postmaster at videolan.org>



More information about the x264-devel mailing list