This is more spec-compliant because it does not rely
on dead-code elimination by the compiler. Especially
MSVC has problems with this, as can be seen in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
or
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
This commit does not eliminate every instance where we rely
on dead code elimination: It only tackles branching to
the initialization of arch-specific dsp code, not e.g. all
uses of CONFIG_ and HAVE_ checks. But maybe it is already
enough to compile FFmpeg with MSVC with whole-programm-optimizations
enabled (if one does not disable too many components).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
WMApro actually support 13-bits block sizes (potentially even up to 14),
and thus we should support that also. If we get block sizes beyond what
the decoder can handle (14 is possible depending on s->decode_flags),
error out instead of crashing.
These windows do not really belong in fft/mdct files and were
easily confused with the similarly named tables used by rdft.
Signed-off-by: Mans Rullgard <mans@mansr.com>