]> git.sesse.net Git - ffmpeg/commit
avcodec/rv34: Don't needlessly copy VLC length and symbol arrays
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Thu, 22 Oct 2020 08:57:40 +0000 (10:57 +0200)
committerAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Mon, 26 Oct 2020 06:16:10 +0000 (07:16 +0100)
commitf033e6d2e635820ec3deb9b936ed3f27ac7ad0a7
treedff1853f70f95ad587f8de1456d5af3ef483aa17
parentc69392a54c161fc679a31cecc4ab8fbe3a46c84b
avcodec/rv34: Don't needlessly copy VLC length and symbol arrays

Most of the VLCs used by RealVideo 3 and 4 obey three simple rules:
Shorter codes are on the left of the tree, for each length, the symbols
are ascending from left to right and the symbols either form a
permutation of 1..size or 0..(size - 1). For the latter case, one just
needs to store the length of each symbol and create the codes according
to the other rules; no explicit code or symbol array must be stored.
The former case is also treated in much the same way by artificially
assigning a length of zero to the symbol 0; when a length of zero was
encountered, the element was ignored except that the symbol counter was
still incremented. If the length was nonzero, the symbol would be
assigned via the symbol counter and the length copied over into a new
array.

Yet this is unnecessary, as ff_init_vlc_sparse() follows exactly the
same pattern: If a length of zero is encountered, the element is ignored
and only the symbol counter incremented. So one can directly forward the
length array and also need not create a symbol table oneself, because
ff_init_vlc_sparse() will infer the same symbol table in this case.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
libavcodec/rv34.c