[Cin] Release for 12/2024 + question for Andrey

[Igor BEGHETTO]

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.AppImage
> 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.AppImage