[FFmpeg-devel] [PATCH] updated LGPL AC-3 decoder

[Michael Niedermayer]

Hi

On Mon, May 07, 2007 at 08:50:00PM -0400, Justin Ruggles wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Sun, May 06, 2007 at 06:49:00PM -0400, Justin Ruggles wrote:
> > [...]
> > 
> >>>[...]
> >>>
> >>>
> >>>>+    /* convert float to 16-bit integer */
> >>>>+    for(ch=0; ch<ctx->out_channels; ch++) {
> >>>>+        for(i=0; i<256; i++) {
> >>>>+            ctx->output[ch][i] = ctx->output[ch][i] * ctx->mul_bias +
> >>>>+                                 ctx->add_bias;
> >>>>+        }
> >>>>+        ctx->dsp.float_to_int16(ctx->int_output[ch], ctx->output[ch], 256);
> >>>
> >>>
> >>>this isnt exactly ideal
> >>>the bias should be applied in some more efficient way like multiplying some
> >>>scaling coefficients, allthough i dunno if thats possible in AC3 ...
> >>
> >>I changed it so that the bias is multiplied in before the IMDCT along
> >>with the dialogue normalization and dynamic range compression.
> >>
> >>On top of your suggestions, I also did several other changes.  I added
> >>dialogue normalization, put in some references to the specs in various
> >>places, fixed some bugs, simplified a few things, added more checks for
> >>error conditions, and removed some unused variables.
> >>
> >>I still can't figure out why the 5.1 decoding is so much slower than
> >>liba52.  My guess is the downmixing, but it might be other things as
> >>well.  Stereo decoding is pretty much the same speed on my system as
> >>liba52, but 5.1 decoding takes twice as long...
> > 
> > 
> > you mean 5.1 with downmixing to stereo or true 5.1 ?
> > 
> > the downmixing should be done before the imdct, that way you dont need to
> > do the imdct on 6 channels but rather just on 2 (i didnt check where the
> > downmix is done exactly but its just IIRC ...)
> > 
> > 
> > [...]
> > 
> > 
> >>+    /* the rest of the bsi. read twice for dual mono mode. */
> >>+    for(i=0; i<=(ctx->acmod == AC3_ACMOD_DUALMONO); i++) {
> >>+        ctx->dialnorm[i] = dialnorm_tbl[get_bits(gb, 5)]; // dialogue normalization
> >>+        if(get_bits1(gb))
> >>+            skip_bits(gb, 8); // skip compression gain
> >>+        if(get_bits1(gb))
> >>+            skip_bits(gb, 8); // skip language code
> >>+        if(get_bits1(gb))
> >>+            skip_bits(gb, 7); // skip audio production information
> >>+    } while(i--);
> > 
> > 
> > hmm for(){}while(); ?
> 
> yeah, you haven't heard of that construct? ;)
> 
> really though, mans is right, i missed that one when i converted it from
> a do{}while() to a for().
> 
> > and patch looks ok
> 
> great.  now...
> 
> Should I apply it all at once or try to go back to the original SoC code
> and do incremental changes?  I looked back at the original, and my best
> guess is that I changed about 75% of the code.  I could do it either way
> really.

incremental is better if its easy, but if you use some script to
automatically check all the revissions in then test it on a dummy
repository first and ensure it can deal with errors
the precommit check script might reject changes due to whitespace/tab issues
or there might be a conflicting commit in the middle (extreemly unlikely i 
know, but the script should stop if something unexpected happens ...)

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070508/c5e925d7/attachment.pgp>