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

[Phyllis Smith]

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 <
cin at lists.cinelerra-gg.org> 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 <
> 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
>>   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
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
> --
> 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/20241231/b6b52888/attachment-0001.htm>