[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