Before After
Mean StdDev Mean StdDev Change
This function 1323.0 98.0 746.2 60.6 +77.3%
Overall 15400.0 336.4 14147.5 288.4 +8.9%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 1389.3 4.2 967.8 35.1 +43.6%
Overall 15577.5 83.2 15400.0 336.4 +1.2%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 868.2 33.5 436.0 27.0 +99.1%
Overall 15973.0 223.2 15577.5 83.2 +2.5%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 2653.0 28.5 1108.8 51.4 +139.3%
Overall 17049.5 408.2 15973.0 223.2 +6.7%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 366.2 18.3 277.8 13.7 +31.9%
Overall 18420.5 489.1 17049.5 408.2 +8.0%
Signed-off-by: Martin Storsjö <martin@martin.st>
This is similar to int32_to_float_fmul_scalar, but
loads a new scalar multiplier every 8 input samples.
This enables the use of much larger input arrays, which
is important for pipelining on some CPUs (such as
ARMv6).
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 1175.0 4.4 366.2 18.3 +220.8%
Overall 19285.5 292.0 18420.5 489.1 +4.7%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 9295.0 114.9 4853.2 83.5 +91.5%
Overall 23699.8 397.6 19285.5 292.0 +22.9%
Signed-off-by: Martin Storsjö <martin@martin.st>
libx264 has a few data exports which require X264_API_IMPORTS
to be defined if we link to libx264 dynamically on Windows.
In a similar fashion to how we handle our compat snprintf
implementation, if we define it all the time, the compiler
will first try and link to __imp_x264_symbol_name, and failing
that, as in the case of a static libx264, will attempt to link
to the non-prefixed symbol, which has already been pulled in by
other x264 functions' object files.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This was handled properly in the normal return case at the end
of the function, but not in this special case.
Returning a value larger than the input packet size can cause
problems for certain library users.
Returning the actual input buffer size unconditionally, since
it is not guaranteed that frame_size is set to a sensible
value at this point.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
A frame marked FRAMETYPE_NULL cannot be scalable and requires a
previous frame successfully decoded.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The faulty values rippled further down the codepath causing a
hard-to-track segfault in the assembly code.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
