[FFmpeg-devel] [PATCH] Long-term prediction for ALS
Thu Nov 12 18:04:12 CET 2009
Ronald S. Bultje schrieb:
> On Thu, Nov 12, 2009 at 11:30 AM, Thilo Borgmann
> <thilo.borgmann at googlemail.com> wrote:
>> Ronald S. Bultje schrieb:
>>> ltp_lag_length = 8 + samplerate >= 96000 + samplerate >= 192000;
>>> (might need brackets).
>> I like that one, too. Revision 1 attached.
> One more:
>> + ltp_gain = get_unary(gb, 0, 4);
>> + ltp_gain <<= 2;
>> + ltp_gain += get_bits(gb, 2);
>> + ltp_gain = ltp_gain_values[ltp_gain];
> No need to store the temp. variable in ltp_gain. Might confuse the
> compiler into doing something silly.
> int idx = get_unary(gb, 0, 4) << 2 + get_bits(gb, 2);
> ltp_gain = ltp_gain_values[idx];
I did it that way and also added clipping the index before actually
accessing the array.
> Or even:
> int a = get_unary(gb, 0, 4), b = get_bits(gb, 2);
> ltp_gain = ltp_gain_values[a][b];
> (The compiler will handle these two equivalent if it's not completely
> retarded.) I also think that (if the order / behaviour is defined, I'm
> not sure if it is) you could get rid of the temporary variables then,
> so it fits on a single line:
> ltp_gainp = ltp_gain_values[get_unary(gb, 0, 4)][get_bits(gb, 2)];
Accessing a one-dimensional array via x would compile? Well at least
this might lead to confusion... and with clipping this would also loose
Thanks, revision 2 attached.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the ffmpeg-devel