Added accidentaly by the commit 73572e77 (2024-03-05). Effective only
if --with-cuda option used but without any implications - just `/FOUN:
not found` printed, but processed normally.
Matrix (1) doesn't seem to be generic enough in case of UYVY.
THe aim is, among others, last resort fix of the BT.601 problem when
got from QSV compression and no YCbCr->RGB conversion took place.
macOS 15 drops support for the API we used for the screen capture in
favor of ScreenCaptureKit, the error is:
```
src/video_capture/screen_osx.c:109:28: error: 'CGDisplayCreateImage'
is unavailable: obsoleted in macOS 15.0 - Please use ScreenCaptureKit
instead.
109 | CGImageRef image = CGDisplayCreateImage(s->display);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGDirectDisplay.h:383:33:
note: 'CGDisplayCreateImage' has been explicitly marked unavailable here
383 | CG_EXTERN CGImageRef __nullable
CGDisplayCreateImage(CGDirectDisplayID displayID)
```
pkg.m4 macro from pkgconf since 2.3.0 aborts by default if PKG_CONFIG
is not found, which check implicitly for pkg-config. Thus set
ACTION-IF-NOT-FOUND to allow fallback check for pkgconf.
Disable CUDA-accelerated FFmpeg conversions with CUDA 8 and earlier. At
least in Linux, it requires gcc-5, which is now hardly compatible. (The
actual compatibility was not tested thoroughly because CUDA 8 is
unsupported.)
see also the commit 4581c7f4
- added RFC 2435 JPEG decoder
- added JPEG interchange format writer (JFIF in particular)
Decode RFC encoded JPEG (abbreviated) and create a JFIF, which can be then
passed to further processing (decode in the end).
The testing JPEG stream played with bluenviron/mediamtx as defined in the
beginning of video_capture/rtsp.c can be now sucessfully played.
see the commit 085b6e60 (today)
autoconf generally dislikes spaces inside paths, which is true for CUDA
in MSW (path to CUDA libs is something like `-L"/c/Program Files/NVIDIA
GPU Computing Toolkit/CUDA/v11.8/lib"`), so do not use it for tests but
add it just when linking.
Prepend compiler default lib path (usually something like
`-LC:/tools/msys64/clang64/bin/../lib`) to avoid erors like:
Linking bin/uv.exe...
ld.lld: error: duplicate symbol: atexit
>>> defined at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:336
>>> C:/msys64/clang64/lib/crt2.o
>>> defined at msvcrt.lib(utility.obj)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:241: bin/uv.exe] Error 1
(reproducible with `./configure --disable-all --enable-cuda`; the
problem is superseded if libavcodec is present, which already does it)
The problem was caused by the fact that MSVC library path is added to
add libmsvcprt.a and libOLDNAMES.a needed by MS C++ STL library that is
needed for CUDA (see the commit b6a45bd5 from 2024-03-27) to support C++
code in CUDA sources (currently lavc cuda convs). As we compile with
Mingw-w64 toolkit, the MinGW lib wrappers need to be used. The error
w/o MS STL library is:
Linking bin/uv.exe...
ld.lld: error: could not open 'libmsvcprt.a': No such file or directory
ld.lld: error: could not open 'libOLDNAMES.a': No such file or directory
c++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:241: bin/uv.exe] Error 1
Add CUDA_LIB to LIBS unconditionally as it is already done for other
platforms except Win.
In Windows, the CUDA wrapper was built outside UltraGrid (as a DLL) but this
is no longer true since the commit a4c22c93f (2024-03-05) so if there is no
CUDA features but still CUDA enabled (as with `--disable-all --enable-cuda`),
the libs were not added for the cuda_wrapper.
if `--disable-all` is used, the variable `req_files` remains empty (if none
enabled explicitly), resuting in error:
```
./configure: line 17483: test: =: unary operator expected
```
Non-fatal - the configure script is not run with `set -e`, so technically
this should not have caused problems except the error message.
Although CUDA_PATH is advertised by help, it is actually immediately overriden
with the content of CUDA_DIRECTORY env var even if unset/empty.
From now, only override it only when CUDA_DIRECTORY is set and not empty (compat).
Try hard-coded path /usr/include/libajantv2 (as in libajantv2 AUR package)
for the headers.
Also try /usr/local/include/libajantv2 before that (default installation
prefix).
Note that the actual headers' are not checked for now, just the directory
presence.
The options cannot be repeated for configure, like
`--enable-object=a --enable-object=b` to enable both a and b
(`--enable-object=a,b` is needed). This may be sometimes impractical,
when the command-line args are appended incrementally.
As a workaround, at least `--enable-output=all` is added. As it is not
a solution, it still (with `--disable-all`) removes most unneeded code
(with dependencies), while compiling all the non-essential objs without
deps.
Replaced all other autoconf-defined platform macros (HAVE_LINUX and
HAVE_MACOSX, WIN32 already done) with those ones defined by compiler.
Not yet remove the definitions from autoconf, in case someone will use
the old macros anyways. Remove in future.
Support for CUDA on macOS is just legacy and the stuff won't compile
(C++ interferes with lavc headers with the old compiler - tested with
CUDA 10.2 on macOS 10.13, which should be the last compatible).
there are still errors like:
```
ld.lld: error: undefined symbol: __std_terminate
>>> referenced by libcpmt.lib(cout.obj):($stateUnwindMap$?_Init@ios_base@std@@IEAAXXZ)
>>> referenced by libcpmt.lib(cout.obj):($stateUnwindMap$??_Gios_base@std@@UEAAPEAXI@Z)
>>> referenced by libcpmt.lib(cout.obj):($stateUnwindMap$??1?$basic_ios@DU?$char_traits@D@std@@@std@@UEAA@XZ)
>>> referenced 12 more times
ld.lld: error: undefined symbol: __CxxFrameHandler4
>>> referenced by libcpmt.lib(cout.obj):($unwind$??0_Locinfo@std@@QEAA@PEBD@Z)
>>> referenced by libcpmt.lib(cout.obj):($unwind$??1_Locinfo@std@@QEAA@XZ)
>>> referenced by libcpmt.lib(cout.obj):($unwind$??0locale@std@@QEAA@XZ)
>>> referenced 140 more times
```
with some code
- needed when not in standard paths for cuda lavc conversions
- do not include in Windows, since it just contains -I/clang64/include,
which interfers with MSVC headers and prevent compilation
