Only compile if CONFIG_ENCODERS is enabled, i.e. if at least one
encoder is to be compiled. This prevents it from being includes in
a decoder-only build.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Not all gcc configurations have an implementation of all the atomic
operations, and some gcc configurations have some atomic builtins
implemented but not all.
Thus check for the most essential function, whose presence should
indicate that all others are present as well, since it can be used
to implement all the other ones.
Signed-off-by: Martin Storsjö <martin@martin.st>
Not all gcc configurations have an implementation of all the atomic
operations, and some gcc configurations have some atomic builtins
implemented but not all.
Thus check for the most essential function, whose presence should
indicate that all others are present as well, since it can be used
to implement all the other ones.
Signed-off-by: Martin Storsjö <martin@martin.st>
These could be used for reference counting, or for keeping track of
decoding progress in references in multithreaded decoders.
Support is provided by gcc/msvc/suncc intrinsics, with a fallback using
pthread mutexes.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This makes the decoder independent of mpegvideo.
This copy of the draw_horiz_band code is simplified compared to
the "generic" mpegvideo one which still has a number of special
cases for different codecs.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes a possible mis-detection of iconv on OS X.
OS X with macports often has two version of libiconv.2.dylib
installed, one with symbols like "_iconv_open" and one with
"_libiconv_open", so test for iconv with all flags to make
sure the detection uses the same library as the actual
compilation / linking.
Tested-by: Paul Sturbaum
It seems to break a lot on MacOS because of a mixup between multiple
iconv libraries. The issue is that the configure check link with no
particular library path (so it uses /usr/lib/libiconv.dylib where all
the symbols are defined). OTOH, the final build might link with extra
library paths, such as the ports lib directory (typically you get
-L/opt/local/lib because of an extra library such as SDL). Whatever this
option position (before or after -liconv), it will try to link with
/opt/local/lib/libiconv.dylib, and the issue is that this version has
the same symbols as the ones in /usr/lib/libiconv.dylib except that they
all start with 'lib' (libiconv_open, libiconv_close, ...). I don't plan
to try to workaround this mess, so any better solution is welcome.
If you want it back (yeah i want it back too)
then you just need to volunteer to maintain the code in configure
thats related to hwaccel autodetection.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>