A bunch of follow-up questions
This is a bunch of follow-up questions I feel both users and occasionally builders want easy clarified without to much research or experiments. I neither say these cannot be partly answered in nor derived from the manual documentation. Additional questions may appear ;) Q1 What capabilites/features does the pre-build Cingg AppImage and/vs the package build (ex. RPM) have? especially with regards to ffmeg, multimedia codecs, encoders etc. Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs? Q3 Does the AppImage use the thirdparty ffmpeg and the RPM the local system ffmpeg? or are both static builds with third party ffmpeg Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added? Q6 What are the configure scripts for the AppImage vs RPM? Q7 What extra capabilites/features may be achieved and justified with own custom build? what config elements? Q8 How often is it needed or suggested to download (or update if possible) the source repo via git clone?
All very good questions. I think a new section in the manual would be a good idea to cover these. AppImages make it possible for anyone to test out Cinelerra quickly without having to build it themselves. But with all of the gains from the graphics cards these days, serious users are best served by building in their own environment, although Vulcan is "supposed" to make that unnecessary. Andrey's releases are actually the most useful for the majority of people for ease of installation and do not have the restrictions that AppImages do. On Sat, Mar 14, 2026 at 2:13 PM Terje J. Hanssen via Cin < [email protected]> wrote:
This is a bunch of follow-up questions I feel both users and occasionally builders want easy clarified without to much research or experiments. I neither say these cannot be partly answered in nor derived from the manual documentation. Additional questions may appear ;)
Q1 What capabilites/features does the pre-build Cingg AppImage and/vs the package build (ex. RPM) have? especially with regards to ffmeg, multimedia codecs, encoders etc.
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Q3 Does the AppImage use the thirdparty ffmpeg and the RPM the local system ffmpeg? or are both static builds with third party ffmpeg
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
Q6 What are the configure scripts for the AppImage vs RPM?
Q7 What extra capabilites/features may be achieved and justified with own custom build? what config elements?
Q8 How often is it needed or suggested to download (or update if possible) the source repo via git clone?
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
I'll try to answer some. сб, 14 мар. 2026 г., 23:13 Terje J. Hanssen via Cin < [email protected]>:
This is a bunch of follow-up questions I feel both users and occasionally builders want easy clarified without to much research or experiments. I neither say these cannot be partly answered in nor derived from the manual documentation. Additional questions may appear ;)
Q1 What capabilites/features does the pre-build Cingg AppImage and/vs the package build (ex. RPM) have? especially with regards to ffmeg, multimedia codecs, encoders etc.
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive. RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
Q3 Does the AppImage use the thirdparty ffmpeg and the RPM the local system ffmpeg? or are both static builds with third party ffmpeg
I think both uses statically-linked thirdparty ffmpeg. (our default due to patching)
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
it is not packaged/installed.
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
At this moment it seems that I try to maintain it. I mostly added giant array of pixelformats to yuv4mpeg so cin can show that in GUI. Other patches carrying from earlier versions, dealing with seeking, mpegts muxing for BluRay disks, some gopro-specific cases for hw acceleration and may be something else
Q6 What are the configure scripts for the AppImage vs RPM?
Q7 What extra capabilites/features may be achieved and justified with own custom build? what config elements?
I for example link with system's libdav1d instead of built-in older version. For both cinelerra-gg and ffmpeg you can ran ./configure --help and see various supported switches. A lot of them, and for ffmpeg they vary per release.
Q8 How often is it needed or suggested to download (or update if possible) the source repo via git clone?
I use either web interface or "git pull -r / git log" to see if anything new arrived into repo. Or just look for emails from Phyllis to list describing newly-added changes ;) I think we still aim at "end of the month" release, so I guess you can update monthly, but obviously testing new patches may happen earlier.
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
@ Phyllis @ Andrew Thank you both for replying and clarifying. To save space in email I use "hard snip" as follows
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive.
Does it mean that "system's dynamic libs" embedded in the AppImage pick them up from the build-machine?
RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
it is not packaged/installed.
Ok, in my current, bundled build I used custom ./configure --with-single-user --with-booby --enable-libsvtav1 --with-onevpl --with-vulkan --with-libplacebo --with-libzimg Then verified with the associated ffmpeg /home3/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0 # ./ffmpeg -hide_banner -hwaccels Hardware acceleration methods: vdpau cuda vaapi qsv vulkan 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.
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
At this moment it seems that I try to maintain it. I mostly added giant array of pixelformats to yuv4mpeg so cin can show that in GUI. Other patches carrying from earlier versions, dealing with seeking, mpegts muxing for BluRay disks, some gopro-specific cases for hw acceleration and may be something else
So no secrets here :) Beside for fun, I have played a bit with Google-ai to see what answers are generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work: CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us cinelerra.spec vs build script https://tinyurl.com/35k6493w what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7 see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn should make clean be used after make errors https://tinyurl.com/2z9j4nzf
вс, 15 мар. 2026 г., 20:02 Terje J. Hanssen <[email protected]>:
@ Phyllis @ Andrew
Thank you both for replying and clarifying. To save space in email I use "hard snip" as follows
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive.
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.
RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
it is not packaged/installed.
Ok, in my current, bundled build I used custom ./configure --with-single-user --with-booby --enable-libsvtav1 --with-onevpl --with-vulkan --with-libplacebo --with-libzimg
Then verified with the associated ffmpeg /home3/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0 # ./ffmpeg -hide_banner -hwaccels
Hardware acceleration methods: vdpau cuda vaapi qsv vulkan
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. 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.
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
At this moment it seems that I try to maintain it. I mostly added giant array of pixelformats to yuv4mpeg so cin can show that in GUI. Other patches carrying from earlier versions, dealing with seeking, mpegts muxing for BluRay disks, some gopro-specific cases for hw acceleration and may be something else
So no secrets here :)
Beside for fun, I have played a bit with Google-ai to see what answers are generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
On 15/03/2026 18:58, Andrew Randrianasulu wrote:
вс, 15 мар. 2026 г., 20:02 Terje J. Hanssen <[email protected]>:
@ Phyllis @ Andrew
...snip
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.
I think the bundled ffmpeg is targeted well and suited for Cingg. Beside it is possible to test system or custom ffmpeg via unbundled builds ;)
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.
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/ openSUSE has their standard system ffmpeg (OSS) and the newest and experimental ffmpeg from Multimedia:libs and :apps.
The answer for Q2. The deb package: $ ldd /usr/bin/cin linux-vdso.so.1 (0x00007f1be24fd000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1be24aa000) libFLAC.so.14 => /usr/lib/x86_64-linux-gnu/libFLAC.so.14 (0x00007f1be2442000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1bdb769000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f1bdb6d4000) libwebp.so.7 => /usr/lib/x86_64-linux-gnu/libwebp.so.7 (0x00007f1bdb646000) libtiff.so.6 => /usr/lib/x86_64-linux-gnu/libtiff.so.6 (0x00007f1bdb5b0000) libvpx.so.9 => /usr/lib/x86_64-linux-gnu/libvpx.so.9 (0x00007f1bdb200000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x00007f1bdac00000) liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0 (0x00007f1be2424000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1bdb0b7000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1be240d000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1be2408000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f1be2400000) libbz2.so.1.0 => /usr/lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1bdb59c000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1bdb067000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1bdab28000) liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1bdb036000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1bdaaed000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f1bdb57c000) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f1be23f8000) libva.so.2 => /usr/lib/x86_64-linux-gnu/libva.so.2 (0x00007f1bdaab5000) libva-x11.so.2 => /usr/lib/x86_64-linux-gnu/libva-x11.so.2 (0x00007f1be23f0000) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007f1bdb575000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1bdaa2f000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1bda9b4000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007f1bdb02f000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1bda999000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1bda871000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f1bdb026000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f1bda81c000) libusb-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1bda7fb000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1bda7ec000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bda400000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f1bda6f6000) libmvec.so.1 => /usr/lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f1bda307000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1bda6c9000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bda111000) /lib64/ld-linux-x86-64.so.2 (0x00007f1be24ff000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1bda699000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f1bda066000) libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f1bda006000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f1bd9fb6000) libsharpyuv.so.0 => /usr/lib/x86_64-linux-gnu/libsharpyuv.so.0 (0x00007f1bda690000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1bd9eec000) libLerc.so.4 => /usr/lib/x86_64-linux-gnu/libLerc.so.4 (0x00007f1bd9e55000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1bda67f000) libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f1bd9e3d000) libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f1bd9e23000) libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f1bda676000) libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f1bd9e18000) libzix-0.so.0 => /usr/lib/x86_64-linux-gnu/libzix-0.so.0 (0x00007f1bd9e09000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1bd9dde000) libexpat.so.1 => /usr/lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1bd9db1000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1bd9da2000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1bd9d8b000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f1bd9d84000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f1bd9d7d000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1bd9cc4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1bd9c90000) libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007f1bd9c65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1bd9c56000) libpulsecommon-17.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/ libpulsecommon-17.0.so (0x00007f1bd9bcd000) libdbus-1.so.3 => /usr/lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1bd9b76000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1bd9b30000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1bd9b29000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1bd9b21000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1bd9afe000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1bd99e5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f1bd99de000) Rpms should be the same. Best regards, Andrey вс, 15 мар. 2026 г. в 20:02, Terje J. Hanssen via Cin < [email protected]>:
@ Phyllis @ Andrew
Thank you both for replying and clarifying. To save space in email I use "hard snip" as follows
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive.
Does it mean that "system's dynamic libs" embedded in the AppImage pick them up from the build-machine?
RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
it is not packaged/installed.
Ok, in my current, bundled build I used custom ./configure --with-single-user --with-booby --enable-libsvtav1 --with-onevpl --with-vulkan --with-libplacebo --with-libzimg
Then verified with the associated ffmpeg /home3/cinelerra/cinelerra-5.1/thirdparty/ffmpeg-8.0 # ./ffmpeg -hide_banner -hwaccels
Hardware acceleration methods: vdpau cuda vaapi qsv vulkan
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.
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
At this moment it seems that I try to maintain it. I mostly added giant array of pixelformats to yuv4mpeg so cin can show that in GUI. Other patches carrying from earlier versions, dealing with seeking, mpegts muxing for BluRay disks, some gopro-specific cases for hw acceleration and may be something else
So no secrets here :)
Beside for fun, I have played a bit with Google-ai to see what answers are generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 16/03/2026 08:59, Андрей Спицын via Cin wrote:
The answer for Q2. The deb package:
$ ldd /usr/bin/cin linux-vdso.so.1 (0x00007f1be24fd000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1be24aa000) libFLAC.so.14 => /usr/lib/x86_64-linux-gnu/libFLAC.so.14 (0x00007f1be2442000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1bdb769000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f1bdb6d4000) libwebp.so.7 => /usr/lib/x86_64-linux-gnu/libwebp.so.7 (0x00007f1bdb646000) libtiff.so.6 => /usr/lib/x86_64-linux-gnu/libtiff.so.6 (0x00007f1bdb5b0000) libvpx.so.9 => /usr/lib/x86_64-linux-gnu/libvpx.so.9 (0x00007f1bdb200000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x00007f1bdac00000) liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0 (0x00007f1be2424000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1bdb0b7000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1be240d000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1be2408000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f1be2400000) libbz2.so.1.0 => /usr/lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1bdb59c000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1bdb067000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1bdab28000) liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1bdb036000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1bdaaed000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f1bdb57c000) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f1be23f8000) libva.so.2 => /usr/lib/x86_64-linux-gnu/libva.so.2 (0x00007f1bdaab5000) libva-x11.so.2 => /usr/lib/x86_64-linux-gnu/libva-x11.so.2 (0x00007f1be23f0000) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007f1bdb575000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1bdaa2f000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1bda9b4000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007f1bdb02f000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1bda999000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1bda871000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f1bdb026000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f1bda81c000) libusb-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1bda7fb000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1bda7ec000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bda400000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f1bda6f6000) libmvec.so.1 => /usr/lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f1bda307000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1bda6c9000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bda111000) /lib64/ld-linux-x86-64.so.2 (0x00007f1be24ff000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1bda699000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f1bda066000) libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f1bda006000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f1bd9fb6000) libsharpyuv.so.0 => /usr/lib/x86_64-linux-gnu/libsharpyuv.so.0 (0x00007f1bda690000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1bd9eec000) libLerc.so.4 => /usr/lib/x86_64-linux-gnu/libLerc.so.4 (0x00007f1bd9e55000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1bda67f000) libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f1bd9e3d000) libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f1bd9e23000) libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f1bda676000) libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f1bd9e18000) libzix-0.so.0 => /usr/lib/x86_64-linux-gnu/libzix-0.so.0 (0x00007f1bd9e09000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1bd9dde000) libexpat.so.1 => /usr/lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1bd9db1000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1bd9da2000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1bd9d8b000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f1bd9d84000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f1bd9d7d000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1bd9cc4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1bd9c90000) libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007f1bd9c65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1bd9c56000) libpulsecommon-17.0.so <http://libpulsecommon-17.0.so> => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-17.0.so <http://libpulsecommon-17.0.so> (0x00007f1bd9bcd000) libdbus-1.so.3 => /usr/lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1bd9b76000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1bd9b30000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1bd9b29000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1bd9b21000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1bd9afe000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1bd99e5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f1bd99de000)
Rpms should be the same.
Best regards, Andrey
Yeah, the binary depends on 70 dynamically linked, shared libs at runtime The short answer is also verified with file /usr/bin/cin /usr/bin/cin: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43b96252af4e2e6ca3a65c5212757b1373bb7578, for GNU/Linux 4.3.0, stripped But does it still have any "mixed linking" with static linked components or lbraries, I don't know. readelf -d /usr/bin/cin | grep NEEDED displays only 57 Shared libraries requested by the dynamic linker Query package name: rpm -qf /usr/bin/cin cinelerra-5.1-20260301.x86_64 rpm -qR cinelerra-5.1-20260301.x86_64 list 141 requirements in total, whereof 139 libs rpm -ql cinelerra-5.1-20260301.x86_64 list 500 files installed by the package What would be fine is to get and maintained the required package lists in the blds/bld_prepare.sh script, as this may may be a confusing and time-consuming part to solve during build time. At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
вс, 15 мар. 2026 г. в 20:02, Terje J. Hanssen via Cin <[email protected]>:
@ Phyllis @ Andrew
Thank you both for replying and clarifying. To save space in email I use "hard snip" as follows
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive.
Does it mean that "system's dynamic libs" embedded in the AppImage pick them up from the build-machine?
RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
пн, 16 мар. 2026 г., 18:17 Terje J. Hanssen via Cin < [email protected]>:
On 16/03/2026 08:59, Андрей Спицын via Cin wrote:
The answer for Q2. The deb package:
$ ldd /usr/bin/cin linux-vdso.so.1 (0x00007f1be24fd000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1be24aa000) libFLAC.so.14 => /usr/lib/x86_64-linux-gnu/libFLAC.so.14 (0x00007f1be2442000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1bdb769000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f1bdb6d4000) libwebp.so.7 => /usr/lib/x86_64-linux-gnu/libwebp.so.7 (0x00007f1bdb646000) libtiff.so.6 => /usr/lib/x86_64-linux-gnu/libtiff.so.6 (0x00007f1bdb5b0000) libvpx.so.9 => /usr/lib/x86_64-linux-gnu/libvpx.so.9 (0x00007f1bdb200000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x00007f1bdac00000) liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0 (0x00007f1be2424000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1bdb0b7000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1be240d000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1be2408000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f1be2400000) libbz2.so.1.0 => /usr/lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1bdb59c000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1bdb067000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1bdab28000) liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1bdb036000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1bdaaed000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f1bdb57c000) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f1be23f8000) libva.so.2 => /usr/lib/x86_64-linux-gnu/libva.so.2 (0x00007f1bdaab5000) libva-x11.so.2 => /usr/lib/x86_64-linux-gnu/libva-x11.so.2 (0x00007f1be23f0000) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007f1bdb575000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1bdaa2f000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1bda9b4000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007f1bdb02f000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1bda999000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1bda871000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f1bdb026000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f1bda81c000) libusb-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1bda7fb000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1bda7ec000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bda400000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f1bda6f6000) libmvec.so.1 => /usr/lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f1bda307000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1bda6c9000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bda111000) /lib64/ld-linux-x86-64.so.2 (0x00007f1be24ff000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1bda699000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f1bda066000) libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f1bda006000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f1bd9fb6000) libsharpyuv.so.0 => /usr/lib/x86_64-linux-gnu/libsharpyuv.so.0 (0x00007f1bda690000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1bd9eec000) libLerc.so.4 => /usr/lib/x86_64-linux-gnu/libLerc.so.4 (0x00007f1bd9e55000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1bda67f000) libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f1bd9e3d000) libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f1bd9e23000) libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f1bda676000) libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f1bd9e18000) libzix-0.so.0 => /usr/lib/x86_64-linux-gnu/libzix-0.so.0 (0x00007f1bd9e09000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1bd9dde000) libexpat.so.1 => /usr/lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1bd9db1000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1bd9da2000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1bd9d8b000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f1bd9d84000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f1bd9d7d000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1bd9cc4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1bd9c90000) libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007f1bd9c65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1bd9c56000) libpulsecommon-17.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/ libpulsecommon-17.0.so (0x00007f1bd9bcd000) libdbus-1.so.3 => /usr/lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1bd9b76000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1bd9b30000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1bd9b29000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1bd9b21000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1bd9afe000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1bd99e5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f1bd99de000)
Rpms should be the same.
Best regards, Andrey
Yeah, the binary depends on 70 dynamically linked, shared libs at runtime
The short answer is also verified with
file /usr/bin/cin /usr/bin/cin: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43b96252af4e2e6ca3a65c5212757b1373bb7578, for GNU/Linux 4.3.0, stripped
But does it still have any "mixed linking" with static linked components or lbraries, I don't know.
readelf -d /usr/bin/cin | grep NEEDED displays only 57 Shared libraries requested by the dynamic linker
Query package name:
rpm -qf /usr/bin/cin cinelerra-5.1-20260301.x86_64
rpm -qR cinelerra-5.1-20260301.x86_64 list 141 requirements in total, whereof 139 libs
rpm -ql cinelerra-5.1-20260301.x86_64 list 500 files installed by the package
What would be fine is to get and maintained the required package lists in the blds/bld_prepare.sh script, as this may may be a confusing and time-consuming part to solve during build time.
You can install suse versions in qemu, I guess? Then if blds/bld_prepare.sh does not work in one os or another you always can modify script and send it to list - I'll diff it again against our version and send diff back to list. Or you can make a diff with git yourself and send it to list. Installing linux distro in kvm-accelerated qemu is not very time consuming, but it eats into disk space, and I am a bit short on that.
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
I do not think our script depend on *version* of packages, just on their *names*. But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
вс, 15 мар. 2026 г. в 20:02, Terje J. Hanssen via Cin < [email protected]>:
@ Phyllis @ Andrew
Thank you both for replying and clarifying. To save space in email I use "hard snip" as follows
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Appimage uses mix of statically-added thirdparty libs embedded in "cin" binary and system's dynamic libs put into self-extracting squashfs archive.
Does it mean that "system's dynamic libs" embedded in the AppImage pick them up from the build-machine?
RPM depends on those dynamic libs from system to be present and compatible between build system and system rpm ran on.
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 16/03/2026 16:27, Andrew Randrianasulu wrote:
пн, 16 мар. 2026 г., 18:17 Terje J. Hanssen via Cin <[email protected]>:
On 16/03/2026 08:59, Андрей Спицын via Cin wrote:
The answer for Q2. The deb package:
$ ldd /usr/bin/cin linux-vdso.so.1 (0x00007f1be24fd000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1be24aa000) libFLAC.so.14 => /usr/lib/x86_64-linux-gnu/libFLAC.so.14 (0x00007f1be2442000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1bdb769000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f1bdb6d4000) libwebp.so.7 => /usr/lib/x86_64-linux-gnu/libwebp.so.7 (0x00007f1bdb646000) libtiff.so.6 => /usr/lib/x86_64-linux-gnu/libtiff.so.6 (0x00007f1bdb5b0000) libvpx.so.9 => /usr/lib/x86_64-linux-gnu/libvpx.so.9 (0x00007f1bdb200000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x00007f1bdac00000) liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0 (0x00007f1be2424000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1bdb0b7000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1be240d000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1be2408000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f1be2400000) libbz2.so.1.0 => /usr/lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1bdb59c000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1bdb067000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1bdab28000) liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1bdb036000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1bdaaed000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f1bdb57c000) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f1be23f8000) libva.so.2 => /usr/lib/x86_64-linux-gnu/libva.so.2 (0x00007f1bdaab5000) libva-x11.so.2 => /usr/lib/x86_64-linux-gnu/libva-x11.so.2 (0x00007f1be23f0000) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007f1bdb575000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1bdaa2f000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1bda9b4000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007f1bdb02f000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1bda999000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1bda871000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f1bdb026000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f1bda81c000) libusb-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1bda7fb000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1bda7ec000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bda400000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f1bda6f6000) libmvec.so.1 => /usr/lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f1bda307000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1bda6c9000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bda111000) /lib64/ld-linux-x86-64.so.2 (0x00007f1be24ff000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1bda699000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f1bda066000) libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f1bda006000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f1bd9fb6000) libsharpyuv.so.0 => /usr/lib/x86_64-linux-gnu/libsharpyuv.so.0 (0x00007f1bda690000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1bd9eec000) libLerc.so.4 => /usr/lib/x86_64-linux-gnu/libLerc.so.4 (0x00007f1bd9e55000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1bda67f000) libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f1bd9e3d000) libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f1bd9e23000) libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f1bda676000) libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f1bd9e18000) libzix-0.so.0 => /usr/lib/x86_64-linux-gnu/libzix-0.so.0 (0x00007f1bd9e09000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1bd9dde000) libexpat.so.1 => /usr/lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1bd9db1000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1bd9da2000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1bd9d8b000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f1bd9d84000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f1bd9d7d000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1bd9cc4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1bd9c90000) libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007f1bd9c65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1bd9c56000) libpulsecommon-17.0.so <http://libpulsecommon-17.0.so> => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-17.0.so <http://libpulsecommon-17.0.so> (0x00007f1bd9bcd000) libdbus-1.so.3 => /usr/lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1bd9b76000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1bd9b30000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1bd9b29000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1bd9b21000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1bd9afe000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1bd99e5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f1bd99de000)
Rpms should be the same.
Best regards, Andrey
Yeah, the binary depends on 70 dynamically linked, shared libs at runtime
The short answer is also verified with
file /usr/bin/cin /usr/bin/cin: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43b96252af4e2e6ca3a65c5212757b1373bb7578, for GNU/Linux 4.3.0, stripped
But does it still have any "mixed linking" with static linked components or lbraries, I don't know.
readelf -d /usr/bin/cin | grep NEEDED displays only 57 Shared libraries requested by the dynamic linker
Query package name:
rpm -qf /usr/bin/cin cinelerra-5.1-20260301.x86_64
rpm -qR cinelerra-5.1-20260301.x86_64 list 141 requirements in total, whereof 139 libs
rpm -ql cinelerra-5.1-20260301.x86_64 list 500 files installed by the package
What would be fine is to get and maintained the required package lists in the blds/bld_prepare.sh script, as this may may be a confusing and time-consuming part to solve during build time.
You can install suse versions in qemu, I guess?
Then if blds/bld_prepare.sh does not work in one os or another you always can modify script and send it to list - I'll diff it again against our version and send diff back to list. Or you can make a diff with git yourself and send it to list.
Installing linux distro in kvm-accelerated qemu is not very time consuming, but it eats into disk space, and I am a bit short on that.
I am also short on disk space, and plan to invest in a larger backup disk as my Seagate 8TB Expansion Desktop USB3 drive is reportedly close to 100% full. Next step up is 22-24TB for video and other backups. They are not cheap, but I have found them very reliable so far.
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
I do not think our script depend on *version* of packages, just on their *names*.
But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
The unbundled Cingg I build a month ago had the following config line CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx /home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED (like also readelf) list 69 needed shared libs, attached here I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)
On 16/03/2026 20:42, Terje J. Hanssen wrote:
On 16/03/2026 16:27, Andrew Randrianasulu wrote:
I do not think our script depend on *version* of packages, just on their *names*.
But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
The unbundled Cingg I build a month ago had the following config line
CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
/home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED (like also readelf) list 69 needed shared libs, attached here
I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)
пн, 16 мар. 2026 г., 22:42 Terje J. Hanssen <[email protected]>:
On 16/03/2026 16:27, Andrew Randrianasulu wrote:
пн, 16 мар. 2026 г., 18:17 Terje J. Hanssen via Cin < [email protected]>:
On 16/03/2026 08:59, Андрей Спицын via Cin wrote:
The answer for Q2. The deb package:
$ ldd /usr/bin/cin linux-vdso.so.1 (0x00007f1be24fd000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f1be24aa000) libFLAC.so.14 => /usr/lib/x86_64-linux-gnu/libFLAC.so.14 (0x00007f1be2442000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1bdb769000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f1bdb6d4000) libwebp.so.7 => /usr/lib/x86_64-linux-gnu/libwebp.so.7 (0x00007f1bdb646000) libtiff.so.6 => /usr/lib/x86_64-linux-gnu/libtiff.so.6 (0x00007f1bdb5b0000) libvpx.so.9 => /usr/lib/x86_64-linux-gnu/libvpx.so.9 (0x00007f1bdb200000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x00007f1bdac00000) liblilv-0.so.0 => /usr/lib/x86_64-linux-gnu/liblilv-0.so.0 (0x00007f1be2424000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1bdb0b7000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1be240d000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f1be2408000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f1be2400000) libbz2.so.1.0 => /usr/lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1bdb59c000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1bdb067000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1bdab28000) liblzma.so.5 => /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1bdb036000) libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1bdaaed000) libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007f1bdb57c000) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f1be23f8000) libva.so.2 => /usr/lib/x86_64-linux-gnu/libva.so.2 (0x00007f1bdaab5000) libva-x11.so.2 => /usr/lib/x86_64-linux-gnu/libva-x11.so.2 (0x00007f1be23f0000) libva-drm.so.2 => /usr/lib/x86_64-linux-gnu/libva-drm.so.2 (0x00007f1bdb575000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1bdaa2f000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f1bda9b4000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x00007f1bdb02f000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1bda999000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f1bda871000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f1bdb026000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f1bda81c000) libusb-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f1bda7fb000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f1bda7ec000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1bda400000) libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f1bda6f6000) libmvec.so.1 => /usr/lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f1bda307000) libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1bda6c9000) libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f1bda111000) /lib64/ld-linux-x86-64.so.2 (0x00007f1be24ff000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f1bda699000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f1bda066000) libmpg123.so.0 => /usr/lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f1bda006000) libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f1bd9fb6000) libsharpyuv.so.0 => /usr/lib/x86_64-linux-gnu/libsharpyuv.so.0 (0x00007f1bda690000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1bd9eec000) libLerc.so.4 => /usr/lib/x86_64-linux-gnu/libLerc.so.4 (0x00007f1bd9e55000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1bda67f000) libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f1bd9e3d000) libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f1bd9e23000) libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f1bda676000) libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f1bd9e18000) libzix-0.so.0 => /usr/lib/x86_64-linux-gnu/libzix-0.so.0 (0x00007f1bd9e09000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1bd9dde000) libexpat.so.1 => /usr/lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1bd9db1000) libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1bd9da2000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f1bd9d8b000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f1bd9d84000) libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f1bd9d7d000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1bd9cc4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1bd9c90000) libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007f1bd9c65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1bd9c56000) libpulsecommon-17.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/ libpulsecommon-17.0.so (0x00007f1bd9bcd000) libdbus-1.so.3 => /usr/lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f1bd9b76000) libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f1bd9b30000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1bd9b29000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1bd9b21000) libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1bd9afe000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f1bd99e5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f1bd99de000)
Rpms should be the same.
Best regards, Andrey
Yeah, the binary depends on 70 dynamically linked, shared libs at runtime
The short answer is also verified with
file /usr/bin/cin /usr/bin/cin: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43b96252af4e2e6ca3a65c5212757b1373bb7578, for GNU/Linux 4.3.0, stripped
But does it still have any "mixed linking" with static linked components or lbraries, I don't know.
readelf -d /usr/bin/cin | grep NEEDED displays only 57 Shared libraries requested by the dynamic linker
Query package name:
rpm -qf /usr/bin/cin cinelerra-5.1-20260301.x86_64
rpm -qR cinelerra-5.1-20260301.x86_64 list 141 requirements in total, whereof 139 libs
rpm -ql cinelerra-5.1-20260301.x86_64 list 500 files installed by the package
What would be fine is to get and maintained the required package lists in the blds/bld_prepare.sh script, as this may may be a confusing and time-consuming part to solve during build time.
You can install suse versions in qemu, I guess?
Then if blds/bld_prepare.sh does not work in one os or another you always can modify script and send it to list - I'll diff it again against our version and send diff back to list. Or you can make a diff with git yourself and send it to list.
Installing linux distro in kvm-accelerated qemu is not very time consuming, but it eats into disk space, and I am a bit short on that.
I am also short on disk space, and plan to invest in a larger backup disk as my Seagate 8TB Expansion Desktop USB3 drive is reportedly close to 100% full. Next step up is 22-24TB for video and other backups. They are not cheap, but I have found them very reliable so far.
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
I do not think our script depend on *version* of packages, just on their *names*.
But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
The unbundled Cingg I build a month ago had the following config line
CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
/home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED (like also readelf) list 69 needed shared libs, attached here
I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)
may be because ldd lists also dependencies of those shared libs ?
On 16/03/2026 20:48, Andrew Randrianasulu wrote:
пн, 16 мар. 2026 г., 22:42 Terje J. Hanssen <[email protected]>:
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
I do not think our script depend on *version* of packages, just on their *names*.
But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
The unbundled Cingg I build a month ago had the following config line
CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
/home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED (like also readelf) list 69 needed shared libs, attached here
After some editing work of the objdump needed lib list from my Cingg unbundled build, I have generated a package list included summary info on Slowroll using the package manager as follows and excluded the 32bit versions with grep: zypper se --provides <libs_dep_list> | grep -v 32bit Attach the list here. As seen I have most all of them (not all variants) that worked for my unbundled build. Extract the package names to make a package install list for build_prepare.sh
I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)
may be because ldd lists also dependencies of those shared libs ?
вт, 17 мар. 2026 г., 01:48 Terje J. Hanssen <[email protected]>:
On 16/03/2026 20:48, Andrew Randrianasulu wrote:
пн, 16 мар. 2026 г., 22:42 Terje J. Hanssen <[email protected]>:
At least package versions will vary between i.e the suse15 lts version and the rolling tumbleweed version. The dependices will also vary I guess between full static bundled build and a full dynamic unbundled build, with and without thirdparty ffmpeg, and enabled libs, i.e all hwaccel methods.
I do not think our script depend on *version* of packages, just on their *names*.
But sure, be free to fork bld_prepare.sh as bld_prepare_dyn.sh and add packages you missed while doing unbundled build.
The unbundled Cingg I build a month ago had the following config line
CFLAGS=-I/usr/include/ffmpeg ./configure --with-single-user --disable-static-build --without-thirdparty --without-libdpx
/home3/cinelerra_unbundled/cinelerra-5.1/bin # objdump -p ./cin | grep NEEDED (like also readelf) list 69 needed shared libs, attached here
After some editing work of the objdump needed lib list from my Cingg unbundled build, I have generated a package list included summary info on Slowroll using the package manager as follows and excluded the 32bit versions with grep:
zypper se --provides <libs_dep_list> | grep -v 32bit
Attach the list here. As seen I have most all of them (not all variants) that worked for my unbundled build. Extract the package names to make a package install list for build_prepare.sh
After some stackoverflow'ing and reading help I come with this line cat Slowroll_package_list_for_cinelerra_unbundled_build | grep lib | tail -n 74 | cut -c 6-25 | tr -d [:blank:] | sed s/$/-devel/ it gives you this list ffmpeg-8-mini-libs-devel glibc-devel liba52-0-devel libasound2-devel libavc1394-0-devel libavcodec62-devel libavfilter11-devel libavformat62-devel libavutil60-devel libbz2-1-devel libdv4-devel libfftw3-3-devel libFLAC14-devel libfontconfig1-devel libfreetype6-devel libgcc_s1-devel libgcc_s1-gcc7-devel libgcc_s1-gcc13-devel libgcc_s1-gcc14-devel libgif7-devel libGLU1-devel libglvnd-devel libiec61883-0-devel libIex-3_4-33-devel libIlmThread-3_4-33-devel libImath-3_2-30-devel libjbig2-devel libjpeg8-devel liblilv-0-0-devel liblzma5-devel libmjpegutils-2_2-0-devel libmp3lame0-devel libnuma1-devel libogg0-devel libOpenEXR-3_4-33-devel libOpenEXRCore-3_4-3-devel libOpenEXRUtil-3_4-3-devel libopus0-devel libpng16-16-devel libpulse0-devel libraw1394-11-devel libserd-0-0-devel libsndfile1-devel libsord-0-0-devel libsratom-0-0-devel libstdc++6-devel libstdc++6-gcc7-devel libstdc++6-gcc13-devel libstdc++6-gcc14-devel libsuil-0-0-devel libswresample6-devel libswscale9-devel libtheora1-devel libtheoradec2-devel libtheoraenc2-devel libtiff6-devel libtwolame0-devel libusb-1_0-0-devel libuuid1-devel libva-drm2-devel libva-x11-2-devel libva2-devel libvdpau1-devel libvorbis0-devel libvorbisenc2-devel libvorbisfile3-devel libX11-6-devel libXext6-devel libXfixes3-devel libXft2-devel libXinerama1-devel libXv1-devel libz-ng-compat1-devel libz1-devel If zypper reacts positively to some of those lines I guess we can stuff it into script ....
I wonder why using ldd on the same binary list 250 shared libs (attach the latter in a separate mail next)
may be because ldd lists also dependencies of those shared libs ?
On 17/03/2026 01:04, Andrew Randrianasulu wrote:
вт, 17 мар. 2026 г., 01:48 Terje J. Hanssen <[email protected]>:
...snip
After some editing work of the objdump needed lib list from my Cingg unbundled build, I have generated a package list included summary info on Slowroll using the package manager as follows and excluded the 32bit versions with grep:
zypper se --provides <libs_dep_list> | grep -v 32bit
Attach the list here. As seen I have most all of them (not all variants) that worked for my unbundled build. Extract the package names to make a package install list for build_prepare.sh
After some stackoverflow'ing and reading help I come with this line
cat Slowroll_package_list_for_cinelerra_unbundled_build | grep lib | tail -n 74 | cut -c 6-25 | tr -d [:blank:] | sed s/$/-devel/
it gives you this list
ffmpeg-8-mini-libs-devel glibc-devel liba52-0-devel .....snip
libXv1-devel libz-ng-compat1-devel libz1-devel
If zypper reacts positively to some of those lines I guess we can stuff it into script ....
Sorry, I see I didn't get included -devel packages. Unhappily they doesn't always use the same packagename#-devel so zypper in reacted with several Package 'ffmpeg-8-mini-libs-devel' not found. Package 'libFLAC14-devel' not found. I find it easier to attach a new list with all my installed -devel packages on Slowroll. It is better there maybe is some more than needed. Slowroll_installed_devel_packages I will be on travel the rest of this week, visiting and celebrating my mother's 97th birthday.
Terje, I checked out a few of your Google-ai urls. Quite interesting. Thanks for passing them along. (Also thanks for doing the "snips" because I do not always get the longer emails released from being held when over the limit in a timely manner and, after all the snipped parts are already in the thread.) Beside for fun, I have played a bit with Google-ai to see what answers are
generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
пн, 16 мар. 2026 г., 19:35 Phyllis Smith <[email protected]>:
Terje, I checked out a few of your Google-ai urls.
Well, I still dislike so-called "AI" because it WILL confidently "make stuff up", and with complex topics it hard to differentiate between useful directions vs misleading directions. https://en.wikipedia.org/wiki/Transformer_(deep_learning) *technically* it surely interesting history, but socially ... this is Trainwreck, and those trillion-dollar companies will happily trade your health (at very minimum) for their own financial gain It also uses resources (from water to electricity to memory chips) but solving this on consumer side is nearly impossible because "99%" just eat whatever fake innovation Big Tech pushed on them. I suspect this lack of self-control/caution does MUCH more damage than "just" consumerism, but because there is no "will pill" I'll stop here. Quite interesting. Thanks for passing them along. (Also thanks for doing
the "snips" because I do not always get the longer emails released from being held when over the limit in a timely manner and, after all the snipped parts are already in the thread.)
Beside for fun, I have played a bit with Google-ai to see what answers are
generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
On 16/03/2026 18:07, Andrew Randrianasulu wrote:
пн, 16 мар. 2026 г., 19:35 Phyllis Smith <[email protected]>:
Terje, I checked out a few of your Google-ai urls.
Well, I still dislike so-called "AI" because it WILL confidently "make stuff up", and with complex topics it hard to differentiate between useful directions vs misleading directions.
Well, I don't disagree, and think: use AI critical and wisely, cross check and cross search :) I think this way AI can be a useful help to fill a purpose. For example I'm impressed what it can help on human memory ;) And with limited knowledge on special subject, i.e by correspondence with experts that don't have and cannot have time to detail everything for everybody, AI search beside can help a lot on the understanding. Another example: kids in the first scool classes have the last years used smartphones and pads uncritical for learning. This year after discussions between parents, teachers and politicans, the devices are collected and new books are introduced for childrens well-being and learning.
https://en.wikipedia.org/wiki/Transformer_(deep_learning)
*technically* it surely interesting history, but socially ... this is Trainwreck, and those trillion-dollar companies will happily trade your health (at very minimum) for their own financial gain
It also uses resources (from water to electricity to memory chips) but solving this on consumer side is nearly impossible because "99%" just eat whatever fake innovation Big Tech pushed on them. I suspect this lack of self-control/caution does MUCH more damage than "just" consumerism, but because there is no "will pill" I'll stop here.
I agree, it's wrong that giga factories for AI, that creates few jobs, get priority in line with or in front over other jobs, while deceiving local politicians with green energy and wind mills that destroy the nature 🙂
Quite interesting. Thanks for passing them along. (Also thanks for doing the "snips" because I do not always get the longer emails released from being held when over the limit in a timely manner and, after all the snipped parts are already in the thread.)
Beside for fun, I have played a bit with Google-ai to see what answers are generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
Well, I still dislike so-called "AI" because it WILL confidently "make stuff up", and with complex topics it hard to differentiate between useful directions vs misleading directions.
I consider AI to be a good tool for routine tasks. As for areas where the AI user is not a specialist, the results should be treated with extreme caution and verified by other means. However, the development of AI tools is currently very rapid; free models are far superior to those from just a year ago, and paid models noticeably surpass free ones. But they should still be used with the same caution. For example, AI currently handles Bash scripts and configuration files for various applications very poorly, while making fewer mistakes in Python and Rust apps. Best regards, Andrey пн, 16 мар. 2026 г. в 20:07, Andrew Randrianasulu via Cin < [email protected]>:
пн, 16 мар. 2026 г., 19:35 Phyllis Smith <[email protected]>:
Terje, I checked out a few of your Google-ai urls.
Well, I still dislike so-called "AI" because it WILL confidently "make stuff up", and with complex topics it hard to differentiate between useful directions vs misleading directions.
https://en.wikipedia.org/wiki/Transformer_(deep_learning)
*technically* it surely interesting history, but socially ... this is Trainwreck, and those trillion-dollar companies will happily trade your health (at very minimum) for their own financial gain
It also uses resources (from water to electricity to memory chips) but solving this on consumer side is nearly impossible because "99%" just eat whatever fake innovation Big Tech pushed on them. I suspect this lack of self-control/caution does MUCH more damage than "just" consumerism, but because there is no "will pill" I'll stop here.
Quite interesting. Thanks for passing them along. (Also thanks for doing
the "snips" because I do not always get the longer emails released from being held when over the limit in a timely manner and, after all the snipped parts are already in the thread.)
Beside for fun, I have played a bit with Google-ai to see what answers
are generated to questions in the same genre - for what they are worth or not. Hopefully my shortened urls to save space here will work:
CINELERRA-GG GIT rpm.bld https://tinyurl.com/2ebt43us
cinelerra.spec vs build script https://tinyurl.com/35k6493w
what is included and not in Suse Tumbleweed - cinelerra-5.1-_.susetw.x86_64.rpm https://shorturl.at/EraKS
how to configure cinelerra-gg with unbundled ffmpeg https://tinyurl.com/4sawurxe
cinelerra configure --enable-ffmpeg https://shorturl.at/Moi7F
what is cinelerra-gg thirdparty https://tinyurl.com/3p2xbpx7
see what cinelerra-gg appimage is configured with https://tinyurl.com/3m8xtrvm
is cinelerra-gg rpm static or dynamic linked https://tinyurl.com/4w7nxw7j
how to find dynamic linked libs on linux https://tinyurl.com/ywwkfuyn
should make clean be used after make errors https://tinyurl.com/2z9j4nzf
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
See attached file that I checked into the Manual GIT section which includes the answers as came from the mailing list. Plus commentary added by me here too. Q1 - same capabilities with caveat 10 items listed in html file. Q5 - in file, I stated that mods/maintenance of ffmpeg by quasi-developers and quasi-moderators (hope this does not offend anyone). Q6 - explained in html file. Q8 - it is the most helpful to rebuild every time there is a GIT source checkin so that any changes that create a problem are find quickly -- for example, Andrea's use of Arch finds early problems because the O/S is always updated. and ahead of just about everyone else. P.S. If you find mistakes or have suggestions in the attached Manual html, please let me know. On Sat, Mar 14, 2026 at 2:13 PM Terje J. Hanssen via Cin < [email protected]> wrote:
This is a bunch of follow-up questions I feel both users and occasionally builders want easy clarified without to much research or experiments. I neither say these cannot be partly answered in nor derived from the manual documentation. Additional questions may appear ;)
Q1 What capabilites/features does the pre-build Cingg AppImage and/vs the package build (ex. RPM) have? especially with regards to ffmeg, multimedia codecs, encoders etc.
Q2 Is the AppImage static linked and RPM dynamic linked or combined dynamic/staticvwith regards to libs?
Q3 Does the AppImage use the thirdparty ffmpeg and the RPM the local system ffmpeg? or are both static builds with third party ffmpeg
Q4 Where is possibly the ffmpeg binary for the extracted AppImage and installed RPM? for own build ffmpeg binary is found in cinelerra-5.1/thirdparty/ffmpeg-8.0/ffmpeg
Q5 Who make and maintain the thirdparty ffmpeg and what extra codecs are added?
Q6 What are the configure scripts for the AppImage vs RPM?
Q7 What extra capabilites/features may be achieved and justified with own custom build? what config elements?
Q8 How often is it needed or suggested to download (or update if possible) the source repo via git clone?
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
participants (4)
-
Andrew Randrianasulu -
Phyllis Smith -
Terje J. Hanssen -
Андрей Спицын