More cleanups to compute_allocation().
The bisection search in compute_allocation() was not using the same
method to count psum as interp_bits2pulses, i.e., it did not
include the 64*C<<BITRES<<LM allocation ceiling (this adds at most
84 max operations/frame, and so should have a trivial CPU cost).
Again, I wouldn't want to try to explain why these are different in
a spec, so let's make them the same.
In addition, the procedure used to fill in bits1 and bits2 after the
bisection search was not the same as the one used during the
bisection search.
I.e., the
if (bits1[j] > 0)
bits1[j] += trim_offset[j];
step was not also done for bits2, so bits1[j] + bits2[j] would not
be equal to what was computed earlier for the hi line, and would
not be guaranteed to be larger than total.
We now compute both allocation lines in the same manner, and then
obtain bits2 by subtracting them, instead of trying to compute the
offset from bits1 up front.
Finally, there was nothing to stop a bitstream from boosting a band
beyond the number of bits remaining, which means that bits1 would
not produce an allocation less than or equal to total, which means
that some bands would receive a negative allocation in the decoder
when the "left over" negative bits were redistributed to other
bands.
This patch only adds the dynalloc offset to allocation lines greater
than 0, so that an all-zeros floor still exists; the effect is that
a dynalloc boost gets linearly scaled between allocation lines 0 and
1, and is constant (like it was before) after that.
We don't have to add the extra condition to the bisection search,
because it never examines allocation line 0.
This re-writes the indexing in the search to make that explicit;
it was tested and gives exactly the same results in exactly the
same number of iterations as the old search.
1 file changed