[FFmpeg-cvslog] r9848 - trunk/libavcodec/ac3dec.c

[Michael Niedermayer]

Hi

On Thu, Aug 02, 2007 at 09:44:15AM +0200, Benjamin Larsson wrote:
> Justin Ruggles skrev:
> > Benjamin Larsson wrote:
> >> jbr wrote:
> >>> Author: jbr
> >>> Date: Wed Aug  1 03:13:58 2007
> >>> New Revision: 9848
> >>>
> >>> Log:
> >>> align array used in mdct. fixes segfault.
> >>>
> >>> Modified:
> >>>    trunk/libavcodec/ac3dec.c
> >>>
> >>> Modified: trunk/libavcodec/ac3dec.c
> >>> ============================================================================== 
> >>>
> >>> --- trunk/libavcodec/ac3dec.c    (original)
> >>> +++ trunk/libavcodec/ac3dec.c    Wed Aug  1 03:13:58 2007
> >>> @@ -686,7 +686,7 @@ static void do_rematrixing(AC3DecodeCont
> >>>  static void do_imdct_256(AC3DecodeContext *ctx, int chindex)
> >>>  {
> >>>      int i, k;
> >>> -    float x[128];
> >>> +    DECLARE_ALIGNED_16(float, x[128]);
> >>>      FFTComplex z[2][64];
> >>>      float *o_ptr = ctx->tmp_output;
> >>
> >> This wont work on win32/beos with regular gcc's. Please use an array
> >> allocated in the AC3DecodeContext.
> >
> > Rather than allocate more memory in the AC3DecodeContext, here is a 
> > way to avoid the stack alignment issue by first deinterleaving the 
> > MDCT coefficients within the already-allocated (and aligned) array.  
> > Does this look okay?

NO! it is not ok to perform an additional memcpy() its not even needed
here simply aligning the pointer by hand would do
and no wasting space in the context is not correct either unless the
data really is needed in the context (i didnt review the code carefully
but it didnt seem like thats the case)

also you could maybe decode directly in interleaved format?


> >
> > -Justin
> >
> 
> Sure looks ok, this will save us some future bugreports.

droping win32 support saves us from more
also if i had to choose between drping suport for a buggy gcc on a buggy os
vs. some senseless double memcpy() then i would instantly choose the first

please do not suggest to add such terrible hacks for things which have
several clean soltions like droping win32 support, disabling SSE on win32, 
requireing gcc 4.2 and realignung the stack on win32, decoding data
interleaved, ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070802/3d0f6a05/attachment.pgp>