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.