Thank you so much for the new release! Always a great job, You all do. I did some rendering test on an old project of mine using "CinGG-20241231-alternative_shortcuts.AppImage"; only 10 secs by selection (highlight) in Timeline. Render setup: vp9_1280x270_24or24or50fps.webm - Info by terminal says: 300 frames 94.918 secs 3.161 fps; File Size 1.6MB An old Cin version, same setup,... - Info by terminal says: 300 frames 83.582 secs 3.589 fps; File Size 1.5MB I think, it is strange that rendering of an old version of CinGG is slightly faster than a new one. Is it, probably, due to the old Laptop and old Operating System that adapts better? IgorBeg Il 31/12/2024 21:14, Phyllis Smith via Cin ha scritto:
AppImages available for the December 2024 release at: https://cinelerra-gg.org/download/images/ + https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm... Packages available for the newer operating systems at: https://github.com/einhander/cin-gg-packages/releases/tag/20241229 See latest release notes below the *****.
Question for *Andrey*: Would it be possible to easily add --with-onevpl to the configure line in your build script for Leap 15.5 RPM package? It would require the added package of "oneVPL-devel" to be installed on that O/S (that is the package name for Fedora). If you use the same build script on all of your package builds, they would have to have "oneVPL-devel" installed also. I have tested the build on Fedora 40 after installing that package and had no problem. I have none of the new Intel hardware to test but Terje would like to be able to use these new Intel hardware/software features on his computer. It should not impact normal usage (hopefully).
********* GIT for Cinelerra-GG has the following changes from 11/01/2024-12/31/2024 ********* *SVT_AV1* has been upgraded to 2.3.0 from 2.2.1 with no known problems. *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. Minor addition to add non-working ffmpeg filters to plugin.opts; these are blacklisted items.
_Andrew-R contributions_ The build for *NetBSD* 10.0/amd64 is now working with 3 patches applied and checked in. New *Termux* (Android) encoding render formats have been added: h264_mediacodec.mp4, hevc_mediacodec.mp4, and mpeg2_hdv.mpeg. The 2 mediacodec formats will only work on Android (mediacodec is part of the Android low-level multimedia support infrastructure). A mod to mjpegtools disables compilation of y4mdenoise to prevent compiler errors in *clang*.
_Terje testing/building and Andrew-R diagnosing contributions_ 12 *new render formats* for qsv, which can be used only if you have that particular Intel hardware and software, have been added as developed/tested by Andrew and Terje. (QSV is Intel’s Quick Sync Video for its dedicated video encoding/decoding hardware core.) 12 *new or replaced vaapi hardware encoding *render formats are now available. Run the vainfo program to determine what formats your hardware/software recognizes. There are some patches to ffmpeg.C and ffmpeg.h to support the above. Additions for building with *oneVPL* (Intel’s oneAPI Video Processing Library) is now an option to be enabled if desired - not enabled by default - on the autogen line by adding “--with-onevpl”. Note in reference to the previous paragraph: There should be no impact to standard usage of CinGG but users need to be especially aware of the fact that using a render encoding format that requires specific hardware/software implementation will give an error. In addition, the standard AppImage releases will not provide the availability to use specific hardware features. This is the same as the inability to use vdpau/vaapi from those same appimages since they are created on a computer without the end users specific hardware. An *AppImage* has been graciously created for users who do have the Intel hardware that supports these newly tested/implemented features *of oneVPL, av1, qsv, and vaapi* for download at: https://cinelerra-gg.org/download/images/CinGG-20241120-x86_64-IntelHW.AppIm...