Use uintptr_t instead of plain int. Without this change, the
comparisons will come out wrong for pointers in certain ranges.
Fixes random failures on ppc64. Also fixes some compiler warnings.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Replaces a very hackish hack to fix the same issue (call instruction
overwriting stack variables).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
gcc 4.6 no longer decrements esp to account for local variables.
Thus using call will end up overwriting some local variable.
So add an extra one it can safely clobber.
This is a huge hack because it's basically pure chance it works,
no idea how this is supposed to be done.
Fixes trac ticket #397.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
SSE-optimized hScale() scales up to 4 pixels at once, so we need to
allocate up to 3 padding pixels to prevent overreads. This fixes
valgrind errors in various swscale-tests on fate.
Speed: from 3.9x to 9.6x speed improvement over C, and some small
(up to 15%) speed improvements over existing MMX code (particularly
for bigger filters).
Author of the fix is ronald, the enabling & commit message are mine.
This fixes
commit 4e3e333a79
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Tue Jul 5 12:49:11 2011 -0700
swscale: error dithering for 16/9/10-bit to 8-bit.
Based on a somewhat similar idea in FFmpeg's swscale copy.
The Fix was originally commited in: (and i missed it due to the commit message)
commit 5c391a161a
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Fri Jul 8 14:39:04 2011 -0700
swscale: rename uv_off/uv_off2 to uv_off_px/byte.
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.
It just does that part in scalar form, I doubt using a vector store
over 2 array would speed it up particularly.
The function should be written to not use a scratch buffer.
The logged information is possibly false, and it tends to be outdated
after each change since the logging code needs to be manually updated.
Simplify and prevent confusing wrong debug messages.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Also remove the unnecessary isSupportedIn/Out macros.
Make the code more compact/readable, and simplify the access to
lsws-specific pixel format information.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When converting RGB format to RGB format with the same bits per sample,
unscaled path performs conversion on the whole buffer at once. For
non-multiple-of-16 BGR24 to RGB24 conversion it means that padding at the
end of line will be converted too. Since it may be of arbitrary length
(e.g. 8 bytes), operating on the whole buffer produces obviously wrong
results.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
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.