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

[Terje J. Hanssen]

Den 31.12.2024 23:31, skrev Andrew Randrianasulu via Cin:
>
>
> вт, 31 дек. 2024 г., 23:15 Phyllis Smith via Cin 
> <cin at lists.cinelerra-gg.org>:
>
>     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.
>
>
> I think you can use appimage's libva IF your operating system closely 
> match one used for creating appimage. Testing without hardware 
> obviously will not work ....
>
>
> Thanks a lot, have nice turn of year!

Happy new year everybody !
Well, starting the new year with continued shoveling snow from polar low 
pressure here at this season 🙁

First, to correct a minor typo that stemmed from me, but it hardly 
doesn't matter: Leap "15.5" should be "15.6".
As I have Leap and Tumbleweed/Slowroll installed in dual-boot setups on 
my three, older and relative new Intel platforms;
SkyLake (2015), KabyLake (2016/17) and Arc Alchemist (2022/23), I can 
test the RPM and qsv and vaapi presets on all.

Additional, I hope we also manage to get the newest Vulkan (Vaapi 
successor) video encoding feature incorporated next 😉
Currently I have posted the ffmpeg-Vulkan issue, which the Intel 
community team has promised to investigate further
https://community.intel.com/t5/Graphics/ffmpeg-h264-vulkan-and-hevc-vulkan-Encode-failed-on-A750-Linux/m-p/1650199#M136526


>
>     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
>     Cin at lists.cinelerra-gg.org
>     https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20250101/03f00689/attachment.htm>