This is so we can sync to x264's version of FMA4 support.
This partialy reverts commit 79687079a9.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
With the forthcoming VEX instruction emulation, mulps
must have only the third operand point to memory, as
this is what vmulps expects.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In some cases when an input contributes fully to the corresponding
output, other inputs may also contribute to the same output. This is the
case, for example, for the default 5.1 to stereo downmix matrix without
normalization.
This is needed if a custom matrix is set by the user after opening the
AVAudioResampleContext because the matrix channel count can change if
different mixing coefficients are used.
CC:libav-stable@libav.org
If the matrix results in an output channel not getting a contribution
from any input channel and the corresponding input channel does not
contribute to any outputs, we can skip the channel during mixing and
silence it after mixing.
If the matrix results in an input channel not contributing to any output
channels and it is not in the output mix, or if the input channel only
contributes fully to the same output channel, we can skip the channel
during mixing.
If the matrix results in an output channel only getting full
contribution from the corresponding input channel and that input channel
does not contribute to any other output channels, we can skip the
channel during mixing.
It adds unnecessary complication for insignificant usability improvement.
The user really should know if they'll need resampling compensation before
opening the context.
Note that only the documentation has changed. The current functionality will
still work until the next major bump.
This allows AudioMix to be treated the same way as other conversion contexts
and removes the requirement to allocate it at the same time as the
AVAudioResampleContext.
The current matrix get/set functions are split between the public interface
and AudioMix private functions.
If there are any samples remaining in the output fifo from previous conversion
calls, we have to output those samples first instead of doing direct output
of the current samples.
We cannot clip to INT_MAX because that value cannot be exactly
represented by a float value and ends up overflowing during conversion
anyway. We need to use a slightly smaller float value, which ends up
with slightly inaccurate results for samples which clip or nearly clip,
but it is close enough. Using doubles as intermediates in the conversion
would be more accurate, but it takes about twice as much time.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
