Instead, only set the function pointers if bitexact flag is
not set during initialization. Since a change in flags triggers
a re-init anyway, this doesn't situations where flag values
change during runtime.
The functions are identical to their MMX counterparts. Thus,
pretending that swscale is highly optimized for AMD3DNOW
extensions is a poorly executed practical joke at best.
Also remove code that overwrites the C versions of functions in
sws_init_swScale_altivec(), so that it uses the C functions of files
if no altivec-optimized version exists.
Adding _POSIX_C_SOURCE to CPPFLAGS globally produces all sorts of problems
since it causes certain system functions to be hidden on some (BSD) systems.
The solution is to only add the flag on systems that really require it, i.e.
glibc-based ones.
This change makes BSD systems compile out-of-the-box without the need for
adding specific flags manually. It also allows dropping a number of flags
set manually on a file-per-file basis, but were only present to work around
breakage introduced by the presence of _POSIX_C_SOURCE.
Also add _XOPEN_SOURCE to CPPFLAGS for glibc systems. We use XSI extensions
in several places already, so it is preferable to define it globally instead
of littering source files with individual #defines only needed for glibc.
It seems sws-PPC did hardcode 2048 at various places instead of using VOFW.
This also means that all past VOFW benchmarks on PPC are meaningless
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix handling of input if not in native endianness, and add support for
9/10-bit output. This allows us to force endianness of YUV420P 9/10bit
in the H264/10bit fate tests, which should fix them on big-endian
systems.
This fixes some overflow in bright areas and ensures that the maximum brightness level is
mapped to the maximum without cliping and without showing dither patterens in flat max
brightness areas.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In the loop:
for (i=0; i<dstH; i++) {
int chrI= i*c->chrDstH / dstH;
when i*c->chrDstH > INT_MAX this leads to an integer overflow, which
results in a negative value for chrI and in out-of-buffer reads. The
overflow is avoided by forcing int64_t arithmetic by casting i to
int64_t.
Fix crash, and trac issue #72.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Michael Niedermayer
Ronald S. Bultje
Kieran Kunhya
Clément Bœsch
Peter Belkner
Diego Biurrun
ami_stuff
Anton Khirnov
Oskar Arvidsson
Baptiste Coudurier
Reimar Döffinger
Peter Ross
tateu
Stefano Sabatini
Manfred Tremmel
unknown author