aboutsummaryrefslogtreecommitdiffstats
path: root/libavfilter
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-10-22 10:57:40 +0200
committerAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-10-26 07:16:10 +0100
commitf033e6d2e635820ec3deb9b936ed3f27ac7ad0a7 (patch)
treedff1853f70f95ad587f8de1456d5af3ef483aa17 /libavfilter
parentc69392a54c161fc679a31cecc4ab8fbe3a46c84b (diff)
downloadffmpeg-f033e6d2e635820ec3deb9b936ed3f27ac7ad0a7.tar.gz
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>
Diffstat (limited to 'libavfilter')
0 files changed, 0 insertions, 0 deletions