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-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 > 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] >
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
