[FFmpeg-devel] [PATCH 0/3] AC3 fixed-point encoder sample shifting
Sat Mar 12 03:12:23 CET 2011
On Fri, Mar 11, 2011 at 05:08:39PM -0500, Justin Ruggles wrote:
> On 03/08/2011 01:49 PM, Michael Niedermayer wrote:
> > On Tue, Mar 08, 2011 at 01:21:43PM -0500, Justin Ruggles wrote:
> >> On 03/08/2011 01:18 PM, Justin Ruggles wrote:
> >>> This patch set changes how and when the fixed-point encoder does sample
> >>> value shifting. Currently it left-shift normalizes samples to 16-bit in
> >>> each block for each channel, then adjusts the exponents accordingly so
> >>> that the final coefficient scale will be correct. With the addition of
> >>> channel coupling, it now becomes important to have greater than 16-bit
> >>> accuracy in the coefficients. The floating-point encoder converts the
> >>> coefficients to 25-bit fixed-point since that is the internal scale for
> >>> AC3. This patch does the same for the fixed-point encoder by shifting
> >>> the coefficients back to their original scale, but in the 25-bit range.
> >>> Patch 1 is needed to handle the higher coefficient scale in channel
> >>> coupling.
> >>> Patch 2 is what I describe above.
> >>> Patch 3 adds x86 SIMD optimization for both pre-MDCT and post-MDCT
> >>> shifting.
> >>> Total encoding time:
> >>> current: 4.16s
> >>> patch 1: 4.16s
> >>> patch 2: 4.07s
> >>> patch 3: 4.01s
> >>> Justin Ruggles (3):
> >>> ac3enc: use MUL64() to multiply fixed-point coefficients
> >>> ac3enc: shift coefficients to 24-bit following MDCT rather than using
> >>> an exponent offset.
> >>> ac3enc: add SIMD-optimized shifting functions for use with the
> >>> fixed-point AC3 encoder
> >> I forgot something... PEAQ comparison.
> >> http://www.flickr.com/photos/justinruggles/5431711148/
> > great work, all commited will push later
> Michael, I also recommend reverting the other 2 patches. I'm sending a
> new patch set which does something similar but better.
ok, ill revert them when i pull the new things in
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel