> 2012/2/29 Christophe Gisquet <[email protected]>: >>> + int mclms_prevvalues[64]; >> [...] >>> + int lms_prevvalues[512]; >> >> Those should probably be int32_t > > Actually, all samples I tested it on never overflow int16_t. Even with > dsp functions doing a lot of work, switching to int16_t is a 14% > decoding speed gain. > > If I'm not mistaken, this was produced through reverse-engineering. > Does the binary use the same buffers/accesses whether it is 16bits or > 24bits content?
As far as I remember, the binary has two different set of functions for 16-bit and 24-bit and they use different filter buffers. (16-bits and 32- bits respectively.) Initially the filter buffers were int16_t, but then I changed them all to int out of laziness. But ideally, we would have two different sets of buffers. Kostya suggested that I use a union, but I was too lazy to implement that. > > Christophe > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel > _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
