+ also to LIBRARY_PATH - this will is done also with -L in configure,
probably
Seems like that /usr/local/lib has never been in LD_LIBRARY_PATH and
somehow it didn't matter so far. But with fluidsynth build, we now get
in CI (== also prevents build):
```
ultragrid_acap_fluidsynth.so: libfluidsynth.so.3: cannot open shared object file: No such file or directory
````
In U22.04 (current Linux CI image), fluidsynth depends on sdl2, which
is undesirable. Actually we need to avoid sdl2 linking altogether.
Build from sources alongside with SDL. This makes sense since SDL_mixer
used to be build there and fluidsynth is replacing it.
+ prevent libsdl2-2.0-0 from (accidentally) installing
assume that FFmpeg is already patched with SVT-VP9 patch
As a side effect, the SVT-VP9 patch doesn't need to be patched (these
patches conflicted because VP9 applied after HEVC, which is now not
the case).
The patch no longer compiles with upstream FFmpeg (moreover the history
of 5000 commits is now too shallow.
Use a updated custom version now - the SVT-HEVC is archived, anyways so
the upstream won't be updated.
This reverts commit a30a8945e3.
This doesn't seem to be required anymore (at least xv30 and yuvx work
with Arc A770 and Raptor Lake-P GPU on i7-1355U).
As the patches need to be applied against specific version of FFmpeg
(pinned in db308b17 2023-02-03). Currently the version is from 23th Dec
2024, which is slightly old. That is a half of the year but we also
depend on the cartwheel version bump, which is a bit unfortunate, whereas
is now not cerain, if there is something needed.
Since the pulsation issue, it was not much usable, anyways and this
clean-ups the code a bit.
Also the behavior will be now more deterministic - it behaved differently
with patched FFmpeg (most likely GH Linux builds), othewrise differntly.
+ enable the header-inserter if user expliclty requesetd intra-refresh
refers to GH-114
Avoid pulsation with inra-refresh by repeating the missing SPS/PPS with
header inseter.
Unfortunately this is doesn't work well with HEVC because it seems that
the NVIDIA encoder keeps the reference almost forever in specific cases,
eg. `testcard:patt=text`. However, it _may_ work under some circumstances.
The flags queried also for 64-bit ARM but it is empty there.
This does basically the same as the commit f46a101c, that adds
_FILE_OFFSET_BITS=64 define to config.h. But the config.h may not be
always included now.
+ compat/misc: typo in comment + assert 64b off_t (off_t should be
actually 64b in _OFF64 env and >= 64b in _OFFBIG so assert at least 64)
IP*PKTINFO is defined by the Mingw-w64 headers but the structs
(eg. msghdr or cmsghdr) as defined in RFC 3542 seem to be called
differently (WSAMSG, WSACMSGHDR).
So the compat will be perhaps still required unless PCP adds support
for Win structure names. The other changes are just fixing Win-specific
headers (which may be fixed in PCP upstream eventually).
Also moved dummy Git identity setting to enfironment.sh (is now needed
also for MSW).
This reverts commit 91b56cddab.
The ppa:savoury1/ffmpeg4 repo is no longer used with ubuntu-22.04
runner but FFmpeg currently needs Vulkan v1.3.277 ibut the distro has
only 1.3.204.
ubuntu-latest is now U24.04, which uses .source files in deb822 format
instead the original .list in one-line-style format. ubuntu-latest is
used by Coverity runner.
advantages:
- it saves some build time (approx. 25 sec)
- it is compatible with Windows CI where the binary build is used as well
- reduces complexity by delegating the build to GPUJPEG CI
As it is now common also for different CUDA stuff and GPUJPEG binary CI
builds themselves (but used only for Win), build also for CC 3.5 (Kepler
cards), which will be still supported for very short amount of time
(but as there will be builds, those can be used in future also on such
a cards, even if the support will be dropped from UG further).
The libva in the savoury1 is very new (2.22), which is even newer than
in U24.04. This would prevent LD_PRELOAD of libva from the system.
This reverts commit 234821d31c.
U20.04 doesn't have libopenh264 yet, so use it from the
ppa:savoury1/ffmpeg4, which replaces ppa:savoury1/vlc3 - it contains
the same x265 version (3.6).
The new repo ppa:savoury1/ffmpeg4 contains more (updated) packages
than /vlc3, which can be actually the advantage (eg. no need to build
own Vulkan loader/headers).
