| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Non-RGB output always uses full chroma interpolation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes integer multiplication overflows in RGB48 output
(vertical) scaling as detected by IOC. What happens is that for
certain types of filters (lanczos, spline, bicubic), the
intermediate sum of coefficients in the middle of a filter can
be larger than the fixed-point equivalent of 1.0, even if the
final sum is 1.0. This is fine and we support that.
However, at frame edges, initFilter() will merge the coefficients
for the off-screen pixels into the top or bottom pixel, such as
to emulate edge extension. This means that suddenly, a single
coefficient can be larger than the fixed-point equivalent of
1.0, which the vertical scaling routines do not support.
Therefore, remove the merging of coefficients for edges for
the vertical scaling filter, and instead add edge detection
to the scaler itself so that it copies the pointers (not data)
for the edges (i.e. it uses line[0] for line[-1] as well), so
that a single coefficient is never larger than the fixed-point
equivalent of 1.0.
|
|
|
|
|
|
|
|
|
|
| |
This fixes the same overflow as in the RGB48/16-bit YUV scaling;
some filters can overflow both negatively and positively (e.g.
spline/lanczos), so we bias a signed integer so it's "half signed"
and "half unsigned", and can cover overflows in both directions
while maintaining full 31-bit depth.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
|
| |
We're shifting individual components (8-bit, unsigned) left by 24,
so making them unsigned should give the same results without the
overflow.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For certain types of filters where the intermediate sum of coefficients
can go above the fixed-point equivalent of 1.0 in the middle of a filter,
the sum of a 31-bit calculation can overflow in both directions and can
thus not be represented in a 32-bit signed or unsigned integer. To work
around this, we subtract 0x40000000 from a signed integer base, so that
we're halfway signed/unsigned, which makes it fit even if it overflows.
After the filter finishes, we add the scaled bias back after a shift.
We use the same trick for 16-bit bpc YUV output routines.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
| |
These semicolons cause invalid empty top-level declarations.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
|
| |
As old bits are shifted out of the accumulator, they cause signed
overflows when they reach the end. Making the variable unsigned fixes
this.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
| |
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
|
| |
This allows using more specific implementations for chroma/luma, e.g.
we can make assumptions on filterSize being constant, thus avoiding
that test at runtime.
|
| |
|
|
|
|
|
|
| |
This reverts commit ac0fb5934893be554a44d2a1eb7a3bc7bf39da4a. It
causes valgrind errors which I'll want to investigate before
resubmitting this.
|
| |
|
|
|
|
| |
Based on a somewhat similar idea in FFmpeg's swscale copy.
|
|
|
|
|
|
| |
We operated on 31-bits, but with e.g. lanczos scaling, values can
add up to beyond 0x80000000, thus leading to output of zeroes. Drop
one bit of precision fixes this.
|
|
|
|
|
| |
We accessed the alpha array even it wasn't used and didn't
exist, hence leading to a NULL pointer segfault.
|
|
|
|
|
| |
When using e.g. lanczos scaling, values can drop below 0, so they
should never be unsigned.
|
| |
|
|
|
|
|
|
| |
For 9/10bit, it means we don't have to upscale to 16bit before
actual scaling or pixel format conversion, and thus a performance
gain.
|
| |
|
|
|
|
|
|
|
| |
This fixes building with --enable-small, by using the correct
variable name.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
| |
This means that precision is retained when scaling between sample
formats with >8 bits per component (48bit RGB, 16bit grayscale,
9/10/16bit YUV).
|
|
|
|
|
|
|
|
| |
Remove unused variables "flags" and "dstFormat" in yuv2packed1,
merge source rows per plane for yuv2packed[12], and make every
source argument int16_t (some where invalidly set to uint16_t).
This prevents stack pollution and is part of the Great Evil Plan
to simplify swscale.
|
|
|
|
| |
This works through some non-obvious hacks in utils.c.
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale.
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale.
|
| |
|
|
|
|
|
| |
The comment should have been placed only in
yuv2rgb48_X_c_template, not yuv2rgb48_1_c_template.
|
|
|
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale. Note that
you'll see some code duplication between the output functions for
different RGB variants, and even between packed-YUV and RGB
variants. This is intentional because it improves readability.
|
|
|
|
|
|
|
| |
YUV planes were marked as uint16_t, but they contained signed data.
Fixes issue 1108 and 675.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
| |
Also add missing glue code for recently added YUV422P10 formats
to swscale.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale.
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale.
|
|
|
|
|
|
|
|
| |
Inline functions are easier to read, maintain, modify and test,
which justifies the slightly increased source size. This patch
also adds support for non-native endianness RGB15/16 and fixes
isSupportedOutput() to no longer claim that we support writing
non-native RGB565/555/444.
|
|
|
|
|
| |
This way the code in the file is less cluttered all-over-the-
place.
|
|
|
|
|
|
| |
Inline functions are slightly larger in source code, but
are easier to handle in source code editors. The binary code
generated is the same.
|
|
|
|
|
|
| |
Inline functions are slightly larger in source code, but
are easier to handle in source code editors. The binary code
generated is the same.
|
|
|
|
| |
This is part of the Great Evil Plan to simplify swscale.
|
|
|
|
| |
This generates better code on some non-x86 architectures.
|
|
|
|
| |
This reduces source code size without affecting the binary.
|
|
|
|
|
|
| |
Remove inline keyword from functions that are never inlined.
Use av_always_inline for functions that should be force-inlined
for performance reasons. Use av_cold for init functions.
|
|
|
|
|
| |
Use of this wrapper was removed in a previous patch, but I
forgot to actually remove the function itself.
|
| |
|