errors encountered when building using thirdparty/ libraries
FYI: gcc-14 sees the bitshift of a negative value as an error. SimpleModule.h:126:47: error: left operand of shift expression ‘(-1 << 31)’ is negative [-fpermissive] 126 | static const int kMinSignedValue = -1 << kScaleBits; | ~~~^~~~~~~~~~~~~ make[6]: *** [Makefile:361: ALAC.lo] Error 1 make[6]: Leaving directory '/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile/modules' make[5]: *** [Makefile:657: all-recursive] Error 1 make[5]: Leaving directory '/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile' This appears to have been fixed in upstream github master, although there was some differing of opinion between maintainer and patch submitter about the specific bit manipulation operations to fix it. build using (cingg internal libs) ./configure \ --prefix=/sharebin/cingg2511 \ --with-thirdparty \ --with-nv \ --with-gl \ --with-xv \ --with-alsa \ --without-cuda \ --enable-audiofile \ --with-jobs=1 \ now succeeds, but cingg version of ffmpeg/libavcodecs does not seem to implement nvenc correctly. ie there is little difference in encoding times between h264 and nvenc when using identical target bitrates. However, when using my Debian supplied or custom compiled ffmpeg command line transcode there is a 3:1 to 5:1 performance rate increase in nvenc. I think nvenc needs to be FAST so it can serve as the a default intermediate high-bitrate render format in projects. -Rob
пт, 5 дек. 2025 г., 05:38 Rob Prowel via Cin <[email protected]>:
FYI:
gcc-14 sees the bitshift of a negative value as an error.
SimpleModule.h:126:47: error: left operand of shift expression ‘(-1 << 31)’ is negative [-fpermissive] 126 | static const int kMinSignedValue = -1 << kScaleBits; | ~~~^~~~~~~~~~~~~ make[6]: *** [Makefile:361: ALAC.lo] Error 1 make[6]: Leaving directory
'/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile/modules' make[5]: *** [Makefile:657: all-recursive] Error 1 make[5]: Leaving directory
'/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile'
This appears to have been fixed in upstream github master, although there was some differing of opinion between maintainer and patch submitter about the specific bit manipulation operations to fix it.
Thanks for reporting, I'll look into that.
build using (cingg internal libs)
./configure \ --prefix=/sharebin/cingg2511 \ --with-thirdparty \ --with-nv \ --with-gl \ --with-xv \ --with-alsa \ --without-cuda \ --enable-audiofile \ --with-jobs=1 \
now succeeds, but cingg version of ffmpeg/libavcodecs does not seem to implement nvenc correctly. ie there is little difference in encoding times between h264 and nvenc when using identical target bitrates.
Check thirdparty/src/nv-codec-headers-12.2.72.0.tar.gz depend on installed Nvidia driver (and this in turn depend on installed GPU) you may need newer or older version of those headers ....
However, when using my Debian supplied or custom compiled ffmpeg command line transcode there is a 3:1 to 5:1 performance rate increase in nvenc.
I think nvenc needs to be FAST so it can serve as the a default intermediate high-bitrate render format in projects.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 12/4/25 9:53 PM, Andrew Randrianasulu wrote:
now succeeds, but cingg version of ffmpeg/libavcodecs does not seem to implement nvenc correctly. ie there is little difference in encoding times between h264 and nvenc when using identical target bitrates.
Check thirdparty/src/nv-codec-headers-12.2.72.0.tar.gz
depend on installed Nvidia driver (and this in turn depend on installed GPU) you may need newer or older version of those headers ....
There does not seem to be a versioned nv-codec-headers-12.2.72.0.tar.gz tarball in thirdparty. there is an ffnvcodec, but it shows no version/release info...files are date modded 11-2024. Looks like that tarball does nothing but supply header files. my GPU is mid-range and not old GTX1060 so mainstream GTS driver is what I use. NVIDIA UNIX x86_64 Kernel Module 550.163.01 Tue Apr 8 12:41:17 UTC 2025 related to seeing no performance difference between nvenc and h264: nvenc render option seems to ignore constant quality render in nvenc. Regardless of what quality level is selected, it produces compact, poor-quality, output. constant bitrate encoding does produce expected output though.
пт, 5 дек. 2025 г., 06:08 Rob Prowel via Cin <[email protected]>:
On 12/4/25 9:53 PM, Andrew Randrianasulu wrote:
now succeeds, but cingg version of ffmpeg/libavcodecs does not seem
to
implement nvenc correctly. ie there is little difference in encoding times between h264 and nvenc when using identical target bitrates.
Check thirdparty/src/nv-codec-headers-12.2.72.0.tar.gz
depend on installed Nvidia driver (and this in turn depend on installed GPU) you may need newer or older version of those headers ....
There does not seem to be a versioned nv-codec-headers-12.2.72.0.tar.gz tarball in thirdparty. there is an ffnvcodec, but it shows no version/release info...files are date modded 11-2024. Looks like that tarball does nothing but supply header files. my GPU is mid-range and not old GTX1060 so mainstream GTS driver is what I use.
ok ... ffnvcodec packaged from https://github.com/FFmpeg/nv-codec-headers/releases my GT710 needed legacy driver and thus older version of headers .....
NVIDIA UNIX x86_64 Kernel Module 550.163.01 Tue Apr 8 12:41:17 UTC 2025
related to seeing no performance difference between nvenc and h264: nvenc render option seems to ignore constant quality render in nvenc. Regardless of what quality level is selected, it produces compact, poor-quality, output. constant bitrate encoding does produce expected output though.
So, hopefully this problem solved? May be we should left note in profile itself saying some GPUs need constant bitrate option?
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
пт, 5 дек. 2025 г., 05:38 Rob Prowel via Cin <[email protected]>:
FYI:
gcc-14 sees the bitshift of a negative value as an error.
SimpleModule.h:126:47: error: left operand of shift expression ‘(-1 << 31)’ is negative [-fpermissive] 126 | static const int kMinSignedValue = -1 << kScaleBits; | ~~~^~~~~~~~~~~~~ make[6]: *** [Makefile:361: ALAC.lo] Error 1 make[6]: Leaving directory
'/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile/modules' make[5]: *** [Makefile:657: all-recursive] Error 1 make[5]: Leaving directory
'/6TB/storage/programming/cingg/cinelerra-5.1/thirdparty/audiofile-0.3.6/libaudiofile'
This appears to have been fixed in upstream github master, although there was some differing of opinion between maintainer and patch submitter about the specific bit manipulation operations to fix it.
You mean this diff? https://github.com/mpruett/audiofile/commit/b62c902dd258125cac86cd2df21fc898... yes, I downloaded it and cut out Changelog entry. will try on my main desktop today ... and if worked will send as patch against our sources.
build using (cingg internal libs)
./configure \ --prefix=/sharebin/cingg2511 \ --with-thirdparty \ --with-nv \ --with-gl \ --with-xv \ --with-alsa \ --without-cuda \ --enable-audiofile \ --with-jobs=1 \
now succeeds, but cingg version of ffmpeg/libavcodecs does not seem to implement nvenc correctly. ie there is little difference in encoding times between h264 and nvenc when using identical target bitrates.
However, when using my Debian supplied or custom compiled ffmpeg command line transcode there is a 3:1 to 5:1 performance rate increase in nvenc.
I think nvenc needs to be FAST so it can serve as the a default intermediate high-bitrate render format in projects.
-Rob
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 12/4/25 10:17 PM, Andrew Randrianasulu wrote:
You mean this diff?
https://github.com/mpruett/audiofile/commit/ b62c902dd258125cac86cd2df21fc898035a43d3.diff <https://github.com/ mpruett/audiofile/commit/b62c902dd258125cac86cd2df21fc898035a43d3.diff>
yes, I downloaded it and cut out Changelog entry.
will try on my main desktop today ... and if worked will send as patch against our sources.
Yep. That would be it. I hacked the Makefile to add -fpermissive as a work-around but yes, pulling the patch would make more sense. re - nv-codec-headers. Yes, there is an updated git repo on videolan.org and the minimum version has moved to 13.0. 1) So where are we on this? your git reference is not from videolan.org? What are you treating as the authoritative source, or should I wait until ALL considered changes appear In the cingg git repo? 2) Are you running into cases where you "cant" simply upgrade the tools because of a need to support legacy? My concern in patching these things in here to test them out is that I don't want to have to do a full make clean; make to test out changes: takes way too long. 3) Are there any make targets that intelligently build just the thirdparty libs that have changed? 4) Can I change parallel jobs make count after ./configure stage? I needs to be (one) during debugging, but (max-cpu) when trying to do a quick compile.
пт, 5 дек. 2025 г., 06:35 Rob Prowel via Cin <[email protected]>:
On 12/4/25 10:17 PM, Andrew Randrianasulu wrote:
You mean this diff?
https://github.com/mpruett/audiofile/commit/ b62c902dd258125cac86cd2df21fc898035a43d3.diff <https://github.com/ mpruett/audiofile/commit/b62c902dd258125cac86cd2df21fc898035a43d3.diff>
yes, I downloaded it and cut out Changelog entry.
will try on my main desktop today ... and if worked will send as patch against our sources.
Yep. That would be it. I hacked the Makefile to add -fpermissive as a work-around but yes, pulling the patch would make more sense.
re - nv-codec-headers. Yes, there is an updated git repo on videolan.org and the minimum version has moved to 13.0.
1) So where are we on this? your git reference is not from videolan.org? What are you treating as the authoritative source, or should I wait until ALL considered changes appear In the cingg git repo?
Versions and download locations should all be in: cinelerra/cinelerra-5.1/thirdparty/downloads.txt
2) Are you running into cases where you "cant" simply upgrade the tools because of a need to support legacy?
yes.
My concern in patching these things in here to test them out is that I don't want to have to do a full make clean; make to test out changes: takes way too long.
3) Are there any make targets that intelligently build just the thirdparty libs that have changed?
you can rm -rf thirdparty/lib_you_want_gone then rm thirdparty/build/lib_you_want_gone.* (there usually 3 of them, each appearing as unpacking, patching, compiling happens). After this restarting from level where you ran ./autogen.sh will use all configured cpus for re-unpacking, patching, compiling, linking specific subproject in thirdparty. if you step in cinelerra/ and do "make" without any -j there it will go for single make job as default. Not sure what will happen if you try to manually build thirdparty libs this way .... If you have enough storage you can try ccache, set it as your CC before compile so recompile will be faster. export CC="ccache gcc" I also have ~/.cache/ccache/ccache.conf with those lines: compression = true compression_level = 8 depend on cpu power and hdd space you can try something like this.
4) Can I change parallel jobs make count after ./configure stage? I needs to be (one) during debugging, but (max-cpu) when trying to do a quick compile.
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Just some commentary on Rob's email.
1) So where are we on this? your git reference is not from videolan.org? What are you treating as the authoritative source, or should I wait until ALL considered changes appear In the cingg git repo?
Videolan appears to be a mirror of the url as shown below in the downloads.txt file. Current version of nv codec headers is 12.2.72.0 and as Andrew referenced this is in cinelerra-5.1/thirdparty/downloads.txt as shown below.
https://github.com/FFmpeg/nv-codec-headers/releases/download/n12.2.72.0/nv-c... # 10.0.26.0 previous for several years and needed for older O/S like Slackware 15 kept in ffnvcodec-old.tar.gz
I use this downloads.txt file when looking for libraries that need updating and consider those the original authoritative source locations but some have changed over the years, such as dcraw and libwebp. From the 11/2024 release notes:
Nvidia encode headers updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https::// developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new There may be user impact since the previous required driver for Linux was 445.87.
re - nv-codec-headers. Yes, there is an updated git repo on
videolan.org and the minimum version has moved to 13.0.
Once we catch up again after ffmpeg version 8.0 was finally pushed, we can update the nv codec headers to the latest 13.0 version. should I wait until ALL considered changes appear In the cingg git repo?
I don't think we will ever be able to keep the thirdparty libraries updated to the latest. Generally I have found that it is better to wait to update a library after it has been out for a while in case an unforeseen problem is spotted in the new update. In the past for FFmpeg, we preferred to wait until the ".1" version, i.e. 8.1 instead of 8.0 but because new features go into the ".0" release, users tend to want that sooner and not wait for ".1". 2) Are you running into cases where you "cant" simply upgrade the tools
because of a need to support legacy?
No, not really. For example the nv headers as you can see in the above quote, we upgraded and left the older headers available for legacy purposes in the file ffnvcodec-old.tar.gz. Of course, the user would have to do their own build to revert to the older headers. In addition, you will see in thirdparty/src both libaom-v3.8.0 which is the default version and libaom-v3.4.0 to use alternatively for Ubuntu 16 (end of life was 2021) but the user has to make changes to use the older version when building (as I do when creating the older AppImage). BUT, there are at least 2 libraries that can not be upgraded - not as a result of legacy systems, but because they switched from using Make to Meson - which are Dav1d and LV2 plugins. Dav1d was converted from Meson to Make initially but we would need a volunteer to do that again. P.S. Thank you to Rob for reporting these issues as I do not think anyone else has gone out of their way to actually try to build without the thirdparty libraries and report back. Building Cinelerra with definitive thirdparty libraries, instead of whatever the user has or does not have on their system, has made it possible in the past to more easily diagnose problems in CinGG since locations remain the same. On Thu, Dec 4, 2025 at 8:35 PM Rob Prowel via Cin < [email protected]> wrote:
On 12/4/25 10:17 PM, Andrew Randrianasulu wrote:
You mean this diff?
https://github.com/mpruett/audiofile/commit/ b62c902dd258125cac86cd2df21fc898035a43d3.diff <https://github.com/ mpruett/audiofile/commit/b62c902dd258125cac86cd2df21fc898035a43d3.diff>
yes, I downloaded it and cut out Changelog entry.
will try on my main desktop today ... and if worked will send as patch against our sources.
Yep. That would be it. I hacked the Makefile to add -fpermissive as a work-around but yes, pulling the patch would make more sense.
re - nv-codec-headers. Yes, there is an updated git repo on videolan.org and the minimum version has moved to 13.0.
1) So where are we on this? your git reference is not from videolan.org? What are you treating as the authoritative source, or should I wait until ALL considered changes appear In the cingg git repo?
2) Are you running into cases where you "cant" simply upgrade the tools because of a need to support legacy?
My concern in patching these things in here to test them out is that I don't want to have to do a full make clean; make to test out changes: takes way too long.
3) Are there any make targets that intelligently build just the thirdparty libs that have changed?
4) Can I change parallel jobs make count after ./configure stage? I needs to be (one) during debugging, but (max-cpu) when trying to do a quick compile.
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
Hi Phyllis. The thread is becoming difficult to follow so top posting a short summary and will consider issue closed. I have abandonned the (system library) compile of cinelerra and my successful last build was using the internal thirdparty/ sources and jobs=1. I have way too many problems when trying to use Debian-13 system libs or when doing parallel build with jobs=12. In the end I cut back my feature subset, did non parallel build, and was able to get a working exe. I'm using this feature subset now and can build sucessfully. ./configure \ --prefix=/sharebin/cingg2511 \ --with-thirdparty \ --with-nv \ --with-gl \ --with-xv \ --with-alsa \ --without-cuda \ --with-jobs=1 Right now the only outstanding issue I have is that I cannot make the ffmpeg nvenc work with constant quality. If I set a target bitrate then it works fine but qc generates avery low bitrate frame image regardless of supplied params. I have a GTX1060 and am using nvidia 550.163 so, according to your comments below it should be compatible with thirdpary/ffnvcodec. -thanks On 12/6/25 3:34 PM, Phyllis Smith wrote:
Just some commentary on Rob's email.
1) So where are we on this? your git reference is not from videolan.org <http://videolan.org>? What are you treating as the authoritative source, or should I wait until ALL considered changes appear In the cingg git repo?
Videolan appears to be a mirror of the url as shown below in the downloads.txt file. Current version of nv codec headers is 12.2.72.0 and as Andrew referenced this is in cinelerra-5.1/thirdparty/ downloads.txt as shown below.
https://github.com/FFmpeg/nv-codec-headers/releases/download/ n12.2.72.0/nv-codec-headers-12.2.72.0.tar.gz <https://github.com/ FFmpeg/nv-codec-headers/releases/download/n12.2.72.0/nv-codec- headers-12.2.72.0.tar.gz> # 10.0.26.0 previous for several years and needed for older O/S like Slackware 15 kept in ffnvcodec-old.tar.gz
I use this downloads.txt file when looking for libraries that need updating and consider those the original authoritative source locations but some have changed over the years, such as dcraw and libwebp. From the 11/2024 release notes:
Nvidia encode headers updated from 10.0.26.0 to 12.2.72.0 which corresponds to Video Codec SDK version 12.0.16. The required driver version for Linux is 550.54.14 or newer. You can check to see if your Nvidia graphics board is supported at this website at the time of this release: https:://developer.nvidia.com/video-encode-and-decode-gpu-support- matrix-new <http://developer.nvidia.com/video-encode-and-decode-gpu- support-matrix-new> There may be user impact since the previous required driver for Linux was 445.87.
re - nv-codec-headers. Yes, there is an updated git repo on videolan.org <http://videolan.org> and the minimum version has moved to 13.0.
Once we catch up again after ffmpeg version 8.0 was finally pushed, we can update the nv codec headers to the latest 13.0 version.
should I wait until ALL considered changes appear In the cingg git repo?
I don't think we will ever be able to keep the thirdparty libraries updated to the latest. Generally I have found that it is better to wait to update a library after it has been out for a while in case an unforeseen problem is spotted in the new update. In the past for FFmpeg, we preferred to wait until the ".1" version, i.e. 8.1 instead of 8.0 but because new features go into the ".0" release, users tend to want that sooner and not wait for ".1".
2) Are you running into cases where you "cant" simply upgrade the tools because of a need to support legacy?
No, not really. For example the nv headers as you can see in the above quote, we upgraded and left the older headers available for legacy purposes in the file ffnvcodec-old.tar.gz. Of course, the user would have to do their own build to revert to the older headers. In addition, you will see in thirdparty/src both libaom-v3.8.0 which is the default version and libaom-v3.4.0 to use alternatively for Ubuntu 16 (end of life was 2021) but the user has to make changes to use the older version when building (as I do when creating the older AppImage).
BUT, there are at least 2 libraries that can not be upgraded - not as a result of legacy systems, but because they switched from using Make to Meson - which are Dav1d and LV2 plugins. Dav1d was converted from Meson to Make initially but we would need a volunteer to do that again.
P.S. Thank you to Rob for reporting these issues as I do not think anyone else has gone out of their way to actually try to build without the thirdparty libraries and report back. Building Cinelerra with definitive thirdparty libraries, instead of whatever the user has or does not have on their system, has made it possible in the past to more easily diagnose problems in CinGG since locations remain the same.
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Rob Prowel