This is required placement by standard [[maybe_unused]] attribute, works
the same for __attribute__((unused)).
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Saves 16KiB from SwrContext.
(FATE would also pass if one made the double matrix part of
the union, too, but I don't know whether this is truely correct,
because swri_rematrix() accesses the double matrix (to check whether
it is equal to 1.0) even when one of the other matrices is in use.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calling a function via a different function pointer type is
undefined behavior (C11, 6.3.2.3 8); two pointer parameters
of different type are not equivalent in this regard, although
it happens to work in practice; the current code relies on this.
This patch brings the code in line with the spec. This fixes the
following FATE-tests when run with Clang-UBSan:
ac3-fixed-encode-2 audiomatch-afconvert-{16000,44100}-mono-he-{adts,m4a}
audiomatch-dolby-44100-mono-he-mp4 filter-metadata-avf-aphase-meter-mono
filter-pan-{downmix1,downmix2,mono2,stereo2,stereo3,stereo4,upmix1,upmix2}
lavf-dv_{pal,ntsc} matroska-encoding-delay
The error was something like
src/libswresample/rematrix.c:621:17: runtime error: call to function sum2_float through pointer to incorrect function type 'void (*)(void *, const void *, const void *, void *, int, int, int)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use "bx lr", or "pop {lr}", which do proper mode switching
between thumb and arm modes. A plain "mov pc, lr" does not switch
from thumb mode to arm mode (while in arm mode, it does switch
mode for a thumb caller).
This is normally not an issue, as CONFIG_THUMB only is enabled if
the C compiler defaults to thumb; but stick to patterns that can
do mode switching if needed, for consistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
The function av_opt_set_channel_layout has been removed since
version 7.0, and the replacement is av_opt_set_chlayout.
The documentation needs to be updated accordingly.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also update the checks that guard against inserting
a new enum entry in the middle of a range.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Depending on input chunk size noticable corrpution was hearable, here is an
example command line:
ffplay -f lavfi -i "sine=440:r=8000:samples_per_frame=32,aresample=24000:filter_size=1:phase_shift=0"
Fix this by rounding the fixed point fractions up instead of down.
Signed-off-by: Marton Balint <cus@passwd.hu>
Makes it robust against adding fields before it, which will be useful in
following commits.
Majority of the patch generated by the following Coccinelle script:
@@
typedef AVOption;
identifier arr_name;
initializer list il;
initializer list[8] il1;
expression tail;
@@
AVOption arr_name[] = { il, { il1,
- tail
+ .unit = tail
}, ... };
with some manual changes, as the script:
* has trouble with options defined inside macros
* sometimes does not handle options under an #else branch
* sometimes swallows whitespace
During a resampling operation where
1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)
then upon first encountering a delay where a soft compensation is
required, swr_set_compensation will lead to another init of swr which
will reset outpts to the specified firstpts thus leading to an output
frame having its pts = firstpts. When the next input frame is received,
swr will see a large delay and inject silence from firstpts to the
current frame's pts. This can lead to severe desync and in worst case,
loss of audio playback.
Parameter firstpts initialized to AV_NOPTS_VALUE in swr_alloc and then
checked in swr_init to avoid resetting outpts, thus avoiding reapplication
of firstpts.
Fixes#4131.
libavcodec/aarch64/vc1dsp_neon.S is skipped here, as it intentionally
uses a layered indentation style to visually show how different
unrolled/interleaved phases fit together.
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead use float one by default for sample rate conversions.
The s16p internal transfer format produces visible and hearable
quantization artifacts.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
for S8 we continue to use S16 as it should have enough precision
Fate is adjusted so bitexactness is maintained between mips/arm/x86
if more tests became bit-inexact on some platform, the same change
can be done to them
The use of higher precision and float intermediates inevitably
leads to more differences between platforms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We've been fuzzing torchvision with [sydr-fuzz](https://github.com/ispras/oss-sydr-fuzz)
and found out of bounds error in ffmpeg project at audioconvert.c:151.
To prevent error we need to fix checks for in and out fmt in swr_init.
Signed-off-by: Eli Kobrin <kobrineli@ispras.ru>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
0th order modified bessel function of the first kind are used in multiple
places, lets avoid having 3+ different implementations
I picked this one as its accurate and quite fast, it can be replaced if
a better one is found
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
From x86inc:
> On AMD cpus <=K10, an ordinary ret is slow if it immediately follows either
> a branch or a branch target. So switch to a 2-byte form of ret in that case.
> We can automatically detect "follows a branch", but not a branch target.
> (SSSE3 is a sufficient condition to know that your cpu doesn't have this problem.)
x86inc can automatically determine whether to use REP_RET rather than
REP in most of these cases, so impact is minimal. Additionally, a few
REP_RETs were used unnecessary, despite the return being nowhere near a
branch.
The only CPUs affected were AMD K10s, made between 2007 and 2011, 16
years ago and 12 years ago, respectively.
In the future, everyone involved with x86inc should consider dropping
REP_RETs altogether.
If it's unsupported or invalid, then there's no point trying to rebuild it
using a value that may have been derived from the same layout to begin with.
Move the checks before the attempts at copying the layout while at it.
Fixes ticket #9908.
Signed-off-by: James Almer <jamrial@gmail.com>
