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

[Michael Niedermayer]

On Thu, Oct 15, 2020 at 04:12:01PM +0200, Andreas Rheinhardt wrote:
> 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.

right, i missed that this was of course also used in the encoder

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201015/52273465/attachment.sig>