diff options
author | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2020-08-29 16:12:05 +0200 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2020-08-30 03:02:13 +0200 |
commit | 0166b1d1a6d052ef49aba3523d64f3c6d4f26372 (patch) | |
tree | dd6c361d1a553531edb85c1b4a16cc3c488f1165 /libavutil/Makefile | |
parent | 7c8cf40adcee516caaa16e7da364c87b204d31a6 (diff) | |
download | ffmpeg-0166b1d1a6d052ef49aba3523d64f3c6d4f26372.tar.gz |
avcodec/wnv1: Use LE bitstream reader, avoid copying packet, fix memleak
The Winnov WNV1 format is designed for a little-endian bitstream reader;
yet our decoder reversed every byte bitwise (in a buffer only
allocated for this purpose) to use a big-endian bitstream reader. This
commit stops this.
Two things needed to be done to achieve this: The codes in the table used
to initialize a VLC reader needed to be reversed bitwise (when
initializing a VLC in LE mode, it is expected that the first bit to be
read is in the least significant bit; with BE codes the first bit to be
read is the most significant bit of the code) and the following
expression needed to be adapted:
ff_reverse[get_bits(&w->gb, 8 - w->shift)]
But this is easy: When only the bits read are reversed, they coincide
with what a little-endian bitstream reader reads that reads the
original, not-reversed data. But ff_reverse always reverses the full
eight bits and this also performs a shift by (8 - (8 - w->shift)) on top
of reversing the bits read. So the above line needs to be changed to
get_bits(&w->gb, 8 - w->shift) << w->shift
and this also shows why the variable shift is named the way it is.
Finally, this also fixes a hypothetical memleak: For gigantic packets,
initializing a GetBitContext can fail and in this case, the buffer
containing the reversed data would leak.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'libavutil/Makefile')
0 files changed, 0 insertions, 0 deletions