[FFmpeg-soc] [soc]: r5570 - in amr: amrnbdata.h amrnbdec.c
Michael Niedermayer
michaelni at gmx.at
Sat Jan 9 19:01:50 CET 2010
On Sat, Jan 09, 2010 at 09:29:47AM -0500, Vitor Sessak wrote:
> Michael Niedermayer wrote:
>> On Fri, Jan 08, 2010 at 10:19:54PM -0500, Vitor Sessak wrote:
>>> 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.
>> the struct contains only uint16_t fields, so this would seem odd to me if
>> a compiler did it but iam not saying no compiler does ...
>
> Is there any disadvantage in using "packed"?
dunno, benchmark
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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-soc/attachments/20100109/e2a9eb77/attachment.pgp>
More information about the FFmpeg-soc
mailing list