Does it mean that "system's dynamic libs" embedded in the AppImage pick them up from the build-machine?
yes.
For things like opengl main lib/drivers, or vaapi/vulkan/onevpl runtime/drivers - we only can hope they compatible enough between "build" and "run" machines/os.
Flatpack supposed to be more isolated/self-contained, but it weights more, and does have its own set of challenges. Never tried to make it.
.....snip
This ffmpeg has 25 enabled features plus a lot of thirdparties
/home3/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0 # ./ffmpeg -version
which counts 25 enables
In comparision my system ffmpeg from Packman, on Slowroll has 67 enabled feature, no extra "thirdparties" while ditto multimedia codecs is easy installed with "opi codecs" (OBS Package Installer).
An extra libopenh264 (Cisco's implementation) is installed on openSUSE, enabled in ffmpeg and used by Firefox.
You can try to add all those -dev packages and use custom evn. variables like
export FFMPEG_EXTRA_CFG="--disable-debug --target-os=android --enable-mediacodec --enable-jni --enable-opencl --disable-doc --disable-ffprobe --enable-libdav1d"export EXTRA_LIBS="-ldav1d -lOpenCL -landroid -landroid-posix-semaphore -lmediandk"
example from termux.bld
but ... do you *really* need everything distribution's ffmpeg enables? Feel free to play this puzzle game of course, if you wish.
Packman, also a community thirdparty repo that require vendor change, builds a lot of applications and tools, so I think their ffmpeg is targeted more generic to support media players, video editors, streaming and media servers http://packman.links2linux.org/
May be there is simpler way to grab all -dev packages by for example trying to rebuild ffmpeg's srpm - but I never tried this route.
Some enables make no sense for us, because they deal with hardware input/output modules we do not support via ffmpeg, like fireware, alsa, etc. Same for network stuff like gnutls and somesuch.