Remove inline keyword for functions that are only called through
their function pointers (and thus cannot be inlined); add av_cold
keyword to init function, and use av_always_inline instead of
inline for functions that must be inlined for performance reasons.
This prevents the following compiler warnings: "warning:
initialization from incompatible pointer type". Since the
variables are only ever used in inline assembly, their type
is actually irrelevant (so the part where it was wrong did
not invoke any buggy behaviour).
Interleave macros and code so that it's easier to find the
actual code that belongs to a function. Also reindent where
appropriate and remove dead code.
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.
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.
PPC and x86 code is split off from swscale_template.c. Lots of code is
still duplicated and should be removed later.
Again uniformize the init system to be more similar to the dsputil one.
Unset h*scale_fast in the x86 init in order to make the output
consistent with the previous status. Thanks to Josh for spotting it.
When built with gcc 4.6, the MMX rgb24 to yuv conversion gives
wrong output. The compiler produces this warning:
libswscale/swscale_template.c:1885:5: warning: use of memory input without lvalue in asm operand 4 is deprecated
Changing the memory operand to a register makes it work.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Don't change paramater passing, but instead use casts.
Shouldn't affect asm output on anything other than win64.
libswscale should work on win64 now.
The rest of ffmpeg still isn't win64 compatible due to the issue of xmm
clobbers, but swscale doesn't use any SSE.
Patch by Anton Mitrofanov <BugMaster AT narod DOT ru>.
Originally committed as revision 31751 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
x86_64 / Mac OS X gcc 4.0.1
x86_64 / Linux icc (all)
x86_64 / Linux gcc 4.0.4
x86_64 / OpenBSD gcc 3.3.5
x86_64 / Linux suncc 5.10
and there are some reports of crashes.
Originally committed as revision 31170 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
long was being incorrectly used as an x86-sized register, both for 32 and 64
bits, but this is not the case in win64.
Originally committed as revision 31153 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
This is of course done with permissions from the authors. The only GPL
component left are MMX optimizations for YUV to RGB conversion.
Originally committed as revision 30965 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
swscale_template.c: In function ‘swScale_C’:
swscale_template.c:2580: warning: unused variable ‘alpMmxFilter’
swscale_template.c: In function ‘sws_init_swScale_C’:
Originally committed as revision 30332 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Ronald S. Bultje
Anton Khirnov
Diego Biurrun
Janne Grunau
Josh Allmann
Luca Barbato
Mans Rullgard
Baptiste Coudurier
Anton Mitrofanov
Ramiro Polla
Michael Niedermayer
Stefano Sabatini
Zuxy Meng