[FFmpeg-devel] [PATCH 6/9] avcodec/asvenc: Avoid reversing output data twice

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, Oct 13, 2020 at 11:10:14AM +0200, Andreas Rheinhardt wrote:
>> The ASUS V2 format is designed for a little-endian bitstream reader, yet
>> our encoder used an ordinary big-endian bitstream writer to write it;
>> the bits of every byte were swapped at the end and some data (namely the
>> numbers not in static tables) had to be bitreversed before writing it at
>> all, so that it would be reversed twice.
>>
>> This commit stops doing so; instead, a little-endian bitstream writer is
>> used. This also necessitated to switch certain static tables, which
>> required trivial modifications to the decoder (that uses the same
>> tables).
> [...]
> 
>> -const uint8_t ff_asv2_level_tab[63][2] = {
>> -    { 0x3F, 10 }, { 0x2F, 10 }, { 0x37, 10 }, { 0x27, 10 }, { 0x3B, 10 }, { 0x2B, 10 }, { 0x33, 10 }, { 0x23, 10 },
>> -    { 0x3D, 10 }, { 0x2D, 10 }, { 0x35, 10 }, { 0x25, 10 }, { 0x39, 10 }, { 0x29, 10 }, { 0x31, 10 }, { 0x21, 10 },
>> -    { 0x1F,  8 }, { 0x17,  8 }, { 0x1B,  8 }, { 0x13,  8 }, { 0x1D,  8 }, { 0x15,  8 }, { 0x19,  8 }, { 0x11,  8 },
>> -    { 0x0F,  6 }, { 0x0B,  6 }, { 0x0D,  6 }, { 0x09,  6 },
>> -    { 0x07,  4 }, { 0x05,  4 },
>> -    { 0x03,  2 },
>> -    { 0x00,  5 },
>> -    { 0x02,  2 },
>> -    { 0x04,  4 }, { 0x06,  4 },
>> -    { 0x08,  6 }, { 0x0C,  6 }, { 0x0A,  6 }, { 0x0E,  6 },
>> -    { 0x10,  8 }, { 0x18,  8 }, { 0x14,  8 }, { 0x1C,  8 }, { 0x12,  8 }, { 0x1A,  8 }, { 0x16,  8 }, { 0x1E,  8 },
>> -    { 0x20, 10 }, { 0x30, 10 }, { 0x28, 10 }, { 0x38, 10 }, { 0x24, 10 }, { 0x34, 10 }, { 0x2C, 10 }, { 0x3C, 10 },
>> -    { 0x22, 10 }, { 0x32, 10 }, { 0x2A, 10 }, { 0x3A, 10 }, { 0x26, 10 }, { 0x36, 10 }, { 0x2E, 10 }, { 0x3E, 10 },
>> +const uint16_t ff_asv2_level_tab[63][2] = {
>> +    { 0x3F0, 10 }, { 0x3D0, 10 }, { 0x3B0, 10 }, { 0x390, 10 }, { 0x370, 10 },
>> +    { 0x350, 10 }, { 0x330, 10 }, { 0x310, 10 }, { 0x2F0, 10 }, { 0x2D0, 10 },
>> +    { 0x2B0, 10 }, { 0x290, 10 }, { 0x270, 10 }, { 0x250, 10 }, { 0x230, 10 },
>> +    { 0x210, 10 },
>> +    { 0x0F8,  8 }, { 0x0E8,  8 }, { 0x0D8,  8 }, { 0x0C8,  8 }, { 0x0B8,  8 },
>> +    { 0x0A8,  8 }, { 0x098,  8 }, { 0x088,  8 },
>> +    { 0x03C,  6 }, { 0x034,  6 }, { 0x02C,  6 }, { 0x024,  6 },
>> +    { 0x00E,  4 }, { 0x00A,  4 },
>> +    { 0x003,  2 },
>> +    { 0x000,  5 },
>> +    { 0x001,  2 },
>> +    { 0x002,  4 }, { 0x006,  4 },
>> +    { 0x004,  6 }, { 0x00C,  6 }, { 0x014,  6 }, { 0x01C,  6 },
>> +    { 0x008,  8 }, { 0x018,  8 }, { 0x028,  8 }, { 0x038,  8 }, { 0x048,  8 },
>> +    { 0x058,  8 }, { 0x068,  8 }, { 0x078,  8 },
>> +    { 0x010, 10 }, { 0x030, 10 }, { 0x050, 10 }, { 0x070, 10 }, { 0x090, 10 },
>> +    { 0x0B0, 10 }, { 0x0D0, 10 }, { 0x0F0, 10 }, { 0x110, 10 }, { 0x130, 10 },
>> +    { 0x150, 10 }, { 0x170, 10 }, { 0x190, 10 }, { 0x1B0, 10 }, { 0x1D0, 10 },
>> +    { 0x1F0, 10 }
>>  };
> 
> would it be worth it to handle codes with length > the 8*sizeof in such a way
> that this fits still in uint8 ?
> 
You seem to believe that the reason I switch to little-endian codes
(which entails switching to uint16_t) in this array lies in the VLC API.
This is not so. The reason for the switch is that the little endian
values are now directly written by put_bits_le(). If the values were not
reversed, one would have to reverse them at runtime in the encoder.

- Andreas