[FFmpeg-devel] [PATCH] Added integer 32 bits support to wavpack

[Michael Niedermayer]

On Fri, May 01, 2009 at 04:05:54PM +0200, Laurent Aimar wrote:
> Hi,
> 
> On Fri, May 01, 2009, Michael Niedermayer wrote:
> > On Fri, May 01, 2009 at 01:49:37PM +0200, Laurent Aimar wrote:
> > >  The attached patch completes the support for files with INT32INFO chunk
> > > with non zero sent_bits.
> > 
> > [...]
> > > @@ -344,6 +348,7 @@ static inline int wv_unpack_stereo(WavpackContext *s, GetBitContext *gb, void *d
> > >      int A, B, L, L2, R, R2, bit;
> > >      int pos = 0;
> > >      uint32_t crc = 0xFFFFFFFF;
> > > +    uint32_t crc_extra = 0xFFFFFFFF;
> > >      int16_t *dst16 = dst;
> > >      int32_t *dst32 = dst;
> > >  
> > 
> > > @@ -424,6 +429,18 @@ static inline int wv_unpack_stereo(WavpackContext *s, GetBitContext *gb, void *d
> > >          if(s->joint)
> > >              L += (R -= (L >> 1));
> > >          crc = (crc * 3 + L) * 3 + R;
> > > +        if(s->extra_bits){
> > > +            L <<= s->extra_bits;
> > > +            R <<= s->extra_bits;
> > > +
> > > +            if(s->got_extra){
> > > +                L |= get_bits(&s->gb_extra, s->extra_bits);
> > > +                crc_extra = crc_extra * 9 + (L&0xffff) * 3 + ((L>>16)&0xffff);
> > 
> > the second & can be avoided if the >> is unsigned
>  Something like (uin32_t)L >> 16 (or (unsigned)L) ?

(unsigned)L
if thats not correct then the int L is likely wrong too


> 
>  I think it is more obfuscated and it's the job of the compilo to remove
> it if unneeded.

suggestions for better compilers are welcome ...

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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-devel/attachments/20090501/0e09c20d/attachment.pgp>