Andrey, since I do not know if Terje will be able to actually take advantage of his Intel hardware using the RPM you generate for Leap with the oneVPL added, I suggest just changing it for Leap first and then wait for Terje to test it before doing them all. Thank you very much, Phyllis
On Tue, Dec 31, 2024 at 1:25 PM Андрей Спицын via Cin < [email protected]> wrote: > >Would it be possible to easily add --with-onevpl to the configure > line in your build script for Leap 15.5 RPM package? > > No problem. The configure line should be changed only for Leap 15.5, or > packages for other systems should be build also with that option? > > Best regards, > Andrey > > вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin < > [email protected]>: > >> 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 >> 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 >> -- >> Cin mailing list >> [email protected] >> https://lists.cinelerra-gg.org/mailman/listinfo/cin >> > -- > Cin mailing list > [email protected] > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
