[flac-dev] Residual bps and encoding speed

[Erik de Castro Lopo]

lvqcl wrote:

> I changed the condition in *_precompute_partition_info_sums_*()
> functions from
>      if(bps <= 16)
> to
>      if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32)
> 
> and then changed the 'subframe_bps' argument of find_best_partition_order_()
> in evaluate_fixed_subframe_() and evaluate_lpc_subframe_() as follows:
> 
>     evaluate_fixed_subframe_():    evaluate_lpc_subframe_():
> 1) subframe_bps + order           subframe_bps + 0
> 2) subframe_bps + order           subframe_bps + 2
> 3) subframe_bps + order           subframe_bps + 4
> 4) subframe_bps + 4               subframe_bps + 4
> 
> Version 0 hangs during encoding. So Miroslav was right, it is necessary
> to increase bps for lpc subframes as well. Versions 1...3 have identical
> encoding speed. So it's possible to play safe and just choose
> "subframe_bps + 4" in both cases. This is equivalent to the patch in
> http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
> (this patch also adds 4 to subframe_bps, but in different place).
> 
> So I think it's a matter of taste which patch to prefer: this --
> http://lists.xiph.org/pipermail/flac-dev/2014-June/004771.html
> or this --
> http://lists.xiph.org/pipermail/flac-dev/2013-July/004303.html

I much prefer the second version because its such a trivial patch.

Howver, exactly because it is such a trivial patch it would be
easy for someone to remove the "+ 4" again and break it.

Before I commit this, I'd like to have a test that triggers this
problem. Let me work on that.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/