diff options
author | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2022-09-03 20:09:18 +0200 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@outlook.com> | 2022-09-05 14:28:20 +0200 |
commit | e6d89d0efd9194198d9964e47bf428be222594ea (patch) | |
tree | 0a5ad6f805d3f037d2c690ec0d4580c6bbf86b34 /libavformat/rtpdec_svq3.c | |
parent | 9e9c99366a9606bbcdfc805b1631dac006df28b2 (diff) | |
download | ffmpeg-e6d89d0efd9194198d9964e47bf428be222594ea.tar.gz |
avcodec/cfhddata: Reduce stack usage
Creating CFHD RL VLC tables works by first extending
the codes by the sign, followed by creating a VLC,
followed by deriving the RL VLC from this VLC (which
is then discarded). Extending the codes uses stack arrays.
The tables used to initialize the VLC are already sorted
from left-to-right in the tree. This means that the
corresponding VLC entries are generally also ascending,
but not always: Entries from subtables always follow
the corresponding main table although it is possible
for the right-most node to fit into the main table.
This suggests that one can try to use the final destination
buffer as scratch buffer for the tables with sign included.
Unfortunately it works for neither of the tables if one
uses the right-most part of the RL VLC buffer as scratch buffer;
using the left-most part of the RL VLC buffer as scratch buffer
might work if one traverses the VLC entries from end to start.
But it works only for the little RL VLC (table 9), not for table 18.
Therefore this patch uses the RL VLC buffer for table 9
as scratch buffer for creating the bigger table 18.
Afterwards the left part of the buffer for table 9 is
used as scratch buffer to create table 9.
This fixes the cfhd part of ticket #9399 (if it is not already fixed).
Notice that I do not consider the previous stack usage excessive.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'libavformat/rtpdec_svq3.c')
0 files changed, 0 insertions, 0 deletions