Hi, On Fri, May 27, 2011 at 6:23 PM, Justin Ruggles <[email protected]> wrote: > On 05/27/2011 04:57 PM, Ronald S. Bultje wrote: > >> Hi, >> >> On Fri, May 27, 2011 at 4:08 PM, Justin Ruggles >> <[email protected]> wrote: >>> >>> This does all the actual bit counting as a final step. >>> --- >>> Updated the x86 implementation of compute_mantissa_size() based on Ronald's >>> suggestions. >>> >>> Instead of shifting by 17, I just used 16, which is still accurate enough >>> for the range here and simplifies a couple things. First of all, it gets rid >>> of the right shift altogether when using pmulhuw. Secondly, 65536 won't fit >>> in a word, but 32768 does. >>> >>> >>> libavcodec/ac3dsp.c | 42 +++++++++++------- >>> libavcodec/ac3dsp.h | 20 ++++++++- >>> libavcodec/ac3enc.c | 92 >>> ++++++++++++++++++++------------------ >>> libavcodec/arm/ac3dsp_arm.S | 52 --------------------- >>> libavcodec/arm/ac3dsp_init_arm.c | 2 - >>> libavcodec/x86/ac3dsp.asm | 53 ++++++++++++++++++++++ >>> libavcodec/x86/ac3dsp_mmx.c | 3 + >>> 7 files changed, 150 insertions(+), 114 deletions(-) >>> delete mode 100644 libavcodec/arm/ac3dsp_arm.S >> >> Is this bitexact? The asm code looks nice here, but it's different >> enough from the C and from the previous version that I'm not sure. I >> suppose you're doing a FASTDIV()-type-thing, in which case this may be >> "good enough", but if it's not bitexact, you may want to >> if(!(avcodeccontext->flags & bitexact)) it... >> >> Otherwise, nice work! > > > Yes, the division is bit-exact as long as the sum is below 32768, which > it always will be in this case. This is basically the same as the > previous sse4.1 version, except that it works with words instead of > dwords and right shifts by 16 instead of 17.
OK, if that's the case, looks good. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
