[FFmpeg-soc] [soc]: r5570 - in amr: amrnbdata.h amrnbdec.c
Vitor Sessak
vitor1001 at gmail.com
Sat Jan 9 04:19:54 CET 2010
cmcq wrote:
> Author: cmcq
> Date: Fri Jan 8 18:16:25 2010
> New Revision: 5570
>
> Log:
> Save about 1KB of space using a field-to-bit lookup instead of bit-to-field.
>
> Modified:
> amr/amrnbdata.h
> amr/amrnbdec.c
>
> Modified: amr/amrnbdata.h
> ==============================================================================
> --- amr/amrnbdata.h Fri Jan 8 18:13:05 2010 (r5569)
> +++ amr/amrnbdata.h Fri Jan 8 18:16:25 2010 (r5570)
> @@ -68,15 +68,6 @@ enum Mode {
> #define LP_FILTER_ORDER 10 ///< linear predictive coding filter order
[...]
> +// Each field in AMRNBFrame is stored as:
> +// one byte of 16 * index in AMRNBFrame relative to previous field
> +// + number of bits in the field
> +// then, one byte for each bit of the field (from most-significant to least)
> +// of the position of that bit in the AMR frame.
> +static const uint8_t order_MODE_4k75[] = {
> + 0x28, 7, 6, 5, 4, 3, 2, 1, 0,
> + 0x18, 15, 14, 13, 12, 11, 10, 9, 8,
> + 0x17, 51, 35, 34, 50, 33, 49, 32,
> + 0x38, 23, 22, 21, 20, 19, 18, 43, 42,
[...]
> if (mode <= MODE_DTX) {
> uint16_t *data = (uint16_t *)&p->frame;
> - const AMROrder *order = amr_unpacking_bitmaps_per_mode[mode];
> - int i;
> + const uint8_t *order = amr_unpacking_bitmaps_per_mode[mode];
> + int field_header; // 16 * relative field index + number of field bits
>
> memset(&p->frame, 0, sizeof(AMRNBFrame));
> - for (i = 0; i < mode_bits[mode]; i++)
> - data[order[i].index] += get_bits1(&gb) << order[i].bit;
> + buf++;
> + while ((field_header = *order++)) {
> + int field = 0;
> + data += field_header >> 4;
> + field_header &= 0xf;
> + while (field_header--) {
> + int bit = *order++;
> + field <<= 1;
> + field |= buf[bit >> 3] >> (bit & 7) & 1;
> + }
> + *data = field;
> + }
I think that this is only guaranteed to work if you declare the
AMRNBFrame struct as packed, since the spec allows the compiler to add
some padding space inside structs otherwise.
Also I'm undecided if the extra complexity is worth the 1kb smaller
tables (of whose only 400 bytes at most would be used in a single
frame). Michael, since you are the one who suggested trying to make the
tables smaller, was that you had in mind?
-Vitor
More information about the FFmpeg-soc
mailing list