search for: flac__bitmath_ilog2

The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=0a0a10f358345f749e4a05021301461994f1ffc5 (from 31 Mar 2007) adds the following conditional: if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) And the commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=f081524c19eeafd08f4db6ee5d52a9634c60f475 has this: if(FLAC__bitmath_ilog2(default_partition_samples) + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS < 32) The question is: why ... < 32, no...

...explanation of this patch. 1. The first parameter of _BitScanReverse() and _BitScanReverse64() is a pointer to unsigned long (4-byte int). However _BitScanReverse64() is called with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug and this patch changes the type of idx variable inside FLAC__bitmath_ilog2_wide() from FLAC__uint64 to unsigned long. The type of idx variable inside FLAC__bitmath_ilog2() was also changed (from FLAC__uint32 to unsigned long), for symmetry. 2. FLAC__clz_uint32() returns the result of BitScanReverse() XOR 31. FLAC__bitmath_ilog2() returns 31-FLAC__clz_uint32() == 31-(...

...predictor_order); #if defined(FLAC__CPU_IA32) && !defined FLAC__NO_ASM && defined FLAC__HAS_NASM && 0 - /* WATCHOUT: "+ bps" is an assumption that the average residual magnitude will not be more than "bps" bits */ - /* previously the condition was: if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) */ - /* see http://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b */ - if(bps <= 16) { + /* WATCHOUT: "+ bps + FLAC__MAX_EXTRA_RESIDUAL_BPS" is the maximum + * assumed size of the average residual magnitude */ + i...

...; /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) > */ > if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > > Is it really "not pessimistic enough"? Can it be changed similarly to your patch > for stream_encoder.c? Good question. I'm not sure what exactly Josh meant by that comment. The git message says just "minor comments". I think the right size o...

...9, 2014 at 06:25:57PM +0400, lvqcl wrote: > Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains > almost the same code, but without any comments that it's not enough pessimistic: > evaluate_lpc_subframe_(): > > if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(subframe_bps <= 16 && qlp_coeff_precision <= 16) > encoder->private_->local_lpc_compute_residual_from_qlp_coefficients_16bit(...); > else > encoder->private_->local_lpc_compute_residual_from_qlp_coefficients(...); > else > enc...

...c/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see http://git.xiph.org/?p=flac.git;a=commitdiff;h=8534bbe4e92300609fd6dc289d882130b69d48cd First, I suspect that there's a typo and the intended code is ... < (((FLAC__uint64)1) << 32) ) (without an unary minus). Second, this condition (in algebraic form)...

The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc specific optimizations (2012-03-28 15:43:48 -0300) are available in the git repository at: git://github.com/crrodriguez/flac.git master for you to fetch changes up to 3a060556772c5d6a6464afddfda7c3ad2f93a306: Remove winamp2 plugin. (2012-...

Miroslav Lichvar wrote: > On Wed, Jul 17, 2013 at 07:45:53PM +1000, Erik de Castro Lopo wrote: > > The fix was changing one local variable from FLAC_uint32 to FLAC_uint64 > > in function precompute_partition_info_sums_(). > > > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b > > I don't like this fix. It will

...6 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c b/src/libFLAC/bitmath.c index 189977c..4fdde4b 100644 --- a/src/libFLAC/bitmath.c +++ b/src/libFLAC/bitmath.c @@ -36,54 +36,6 @@ #include "private/bitmath.h" #include "FLAC/assert.h" -/* An example of what FLAC__bitmath_ilog2() computes: - * - * ilog2( 0) = assertion failure - * ilog2( 1) = 0 - * ilog2( 2) = 1 - * ilog2( 3) = 1 - * ilog2( 4) = 2 - * ilog2( 5) = 2 - * ilog2( 6) = 2 - * ilog2( 7) = 2 - * ilog2( 8) = 3 - * ilog2( 9) = 3 - * ilog2(10) = 3 - * ilog2(11) = 3 - * ilog2(12) = 3 - * ilog2(13) = 3 - * ilog2(14) =...

...d with a pointer to FLAC__uint64 > (8-byte int). IMHO it's a bug I would not call that a bug, just a result of trying to write cross platform code and relying on functions that are not specified by any standard. > 2. FLAC__clz_uint32() returns the result of BitScanReverse() XOR 31. > FLAC__bitmath_ilog2() returns 31-FLAC__clz_uint32() == 31-(BSR^31). > > As 0<=BSR<=31 so 31-(BSR^31) == BSR. But I don't think that compilers > are so smart that can optimize this expression. So it is better to change > FLAC__bitmath_ilog2() so it simply calls BitScanReverse() when possible. I...

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m; m=(_v>0xFFFFFFFFU)<<5; v=(FLAC__uint32)(_v>>m); v|...

Cristian Rodr?guez wrote: > The following changes since commit b78d8e4db10e57b8d82bb82e4e3662d5dedd7255: > > FLAC__bitmath_ilog2,FLAC__bitmath_ilog2_wide,COUNT_ZERO_MSBS: add gcc > specific optimizations (2012-03-28 15:43:48 -0300) > > are available in the git repository at: > > git://github.com/crrodriguez/flac.git master > > for you to fetch changes up to 3a060556772c5d6a6464afddfda7c3ad2f93a306...

...e src/libFLAC/include/private/fixed.h: "The _wide() version uses 64-bit integers which is statistically necessary when bits-per-sample + log2(blocksize) > 30" I mean the word "statistically". libFLAC uses FLAC__fixed_compute_best_predictor_wide() if "bits_per_sample + FLAC__bitmath_ilog2(blocksize)+1 > 30" is true (see encoder->private_->use_wide_by_block variable in stream_encoder.c)

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 subf...

...c: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) > */ > if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > which is equivalent to the current > > bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32 > > So IMHO the comment is incorrect. Yeah, the current code looks right to me. I think we already discussed this some time ago. I'd just re...

Here I attach a preliminary version of a patch for precompute_partition_info_sums_() function that should accelerate encoding of 24-bit input data. 1) SSE2, SSSE3 and AVX2 versions of this function should be updated, too 2) the patch also changes if(FLAC__bitmath_ilog2(default_partition_samples) + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS < 32) into (in effect) if(FLAC__bitmath_ilog2(default_partition_samples) + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS <= 32) So, should the value of FLAC__MAX_EXTRA_RESIDUAL_BPS be increased (to 5? or to 6?) 3) any comments? -----...

...the same for 64-bit version). "sizeof(FLAC__uint32) * CHAR_BIT" must be 32, or the code won't work. So it's simpler to use "31 - FLAC__clz_uint32(v)" or even better, "FLAC__clz_uint32(v) ^ 31". Why XORing is better: gcc implements __builtin_clz as bsr^31, so FLAC__bitmath_ilog2() now calculates 31 - (bsr^31). GCC is unable to simplify it to just bsr. But it can do it for (bsr^31)^31. 5) The patch adds FLAC__U64L() for a big constant. -------------- next part -------------- A non-text attachment was scrubbed... Name: 2_bitmath_h.patch Type: application/octet-stream Size:...

Erik de Castro Lopo wrote: > There should be some indication of why in the git history. http://git.xiph.org/?p=flac.git;a=commitdiff;h=27846708fe6271e5e3965a4bbad99baa1ca24c49 Now I remember a discussion about a bug in -p switch: the old code substracts lpc_order instead of FLAC__bitmath_ilog2(lpc_order), and this commit fixes this. It seems that the logic in process_subframe_() and in evaluate_lpc_subframe_() is the same, so the constants in the conditions should be the same: either both equal to 16, or both equal to 17. I built two flac executables, the 1st is from current git head...

..._sample == 16) { if(encoder->protected_->blocksize <= 192) @@ -880,7 +871,7 @@ static FLAC__StreamEncoderInitStatus init_stream_internal_( encoder->private_->current_frame_number = 0; encoder->private_->use_wide_by_block = (encoder->protected_->bits_per_sample + FLAC__bitmath_ilog2(encoder->protected_->blocksize)+1 > 30); - encoder->private_->use_wide_by_order = (encoder->protected_->bits_per_sample + FLAC__bitmath_ilog2(max(encoder->protected_->max_lpc_order, FLAC__MAX_FIXED_ORDER))+1 > 30); /*@@@ need to use this? */ + encoder->private_->...

...>private_->local_lpc_restore_signal(decoder->private_->residual[channel], decoder->private_->frame.header.blocksize-order, subframe->qlp_coeff, order, subframe->quantization_level, decoder->private_->output[channel]+order); + if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) + if(bps <= 16 && subframe->qlp_coeff_precision <= 16) + decoder->private_->local_lpc_restore_signal_16bit(decoder->private_->residual[channel], decoder->private_->frame.header.blocksize-order, subframe->qlp_coeff, order, subframe->quanti...