[Cin] Testing Cingg RPM built with OneVPL, qsv and vaapi presets

[Terje J. Hanssen]

Den 05.01.2025 18:38, skrev Andrew Randrianasulu:
>
>
> вс, 5 янв. 2025 г., 18:39 Terje J. Hanssen via Cin 
> <cin at lists.cinelerra-gg.org>:
>
>
>
>
>     Den 05.01.2025 13:09, skrev Terje J. Hanssen:
>>
>>     Den 04.01.2025 02:04, skrev Terje J. Hanssen:
>>>     Installed Andrey's recent
>>>     cinelerra-5.1-20250104.suse15.x86_64.rpm package on Leap 15.6 on
>>>     two different Intel based hw, and tested qsv and vaapi presets
>>>     without issues
>>>
>>>     1) Intel Arc Alchemist w/ A750 dGPU (2023)
>>>
>>>     av1_qsv_8b420.mp4, qsv_10b420.mp4
>>>     hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4, hevc_qsv_10b422.mp4
>>>
>>>     av1_vaapi_8b420.mp4, vaapi_10b420.mp4
>>>     hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4, hevc_vaapi_10b422.mp4
>>>
>>>
>>>     2) Intel KabyLake w/ UHD 620 iGPU (2017)
>>>
>>>     hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4
>>>     hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4
>>>
>>>     The last line here is of special interest
>>>     hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4
>>>
>>>     because Cingg deb on UB24.04 on this machine didn't render
>>>     hevc_vaapi.
>>>     It seems that OneVPL (libvpl) extends the codec capability also
>>>     for vaapi.
>>>     This has to be verified by dual-testing once more..
>>
>>     A second attempt with UB24.04.1 on KabayLake confirms the latter:
>>
>>     Limit:
>>
>>     hevc_vaapi_8b420.mp4
>>     [hevc_vaapi @ 0x769ae015a100] No usable encoding entrypoint found
>>     for profile VAProfileHEVCMain (17).
>>
>>     ----------------------
>>
>>     Additional test on my oldest workstation in use:
>>
>>     3) Intel SkyLake  w/ HD 530 iGPU (2015)
>>
>>     cin
>>     Cinelerra Infinity - built: Jan  4 2025 01:10:37 (Leap 15.6)
>>
>>     hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4
>>     hdv09_04_h264_vaapi_8b420
>>     hevc_vaapi_8b420.mp4
>>
>>     Limit:
>>
>>     hevc_vaapi_10b420.mp4
>>     video/hdv09_04_hevc_vaapi_10b420.mp4
>>     [hevc_vaapi @ 0x7fe830011300] No usable encoding profile found.
>>
>>     -------------
>>
>>     Another question while being in the confusing corner:
>>
>>         cin
>>         Cinelerra Infinity - built: Jan  4 2025 01:10:37 (Leap 15.6)
>>
>>     When rendering qsv, the following is output, but not when
>>     rendering vaapi - and why not the opposite as I rather would have
>>     expected?
>>
>>         libva info: VA-API version 1.20.0
>>         libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
>>         libva info: Found init function __vaDriverInit_1_20
>>         libva info: va_openDriver() returns 0
>>
>>
>
>     Cinelerra just repeates this output from the ffmpeg qsv encoding
>     (ffmpeg vaapi doesn't output this).
>     And the "libva info" output comes from "vainfo", which is part of
>     "libva-utils"
>     https://github.com/intel/libva-utils
>
>     So the remaining question is: what is really the interaction (if
>     any) between libva/libvpl and vaapi/qsv?
>
>
> I think libvpl can load "legacy" vaapi driver, too ...
>
> Hopefully there is some description about that on their github page?
>
> https://intel.github.io/libvpl/latest/programming_guide/VPL_prg_hw.html
>
> this link talk about vaapi as underlying api on Linux.
>
> Hopefully, this "bonus" feature will work across few future driver 
> releases ;)

Yes, thanks for throwing more light on this.

oneVPL is said to be more high level and to give better portability.
The oneVPL dispatcher can work with the Intel Media SDK GPU runtime to 
support legacy GPUs and the Intel VPL GPU implementation for newer GPUs.
https://www.intel.com/content/www/us/en/docs/onevpl/upgrade-from-msdk/2023-1/onevpl-hardware-support-details.html
https://www.intel.com/content/www/us/en/docs/onevpl/upgrade-from-msdk/2023-1/summary.html

> May be order of use/initialization matters? So qsv hevc used first  
> unbriks vaapi hevc in some way? Not sure if this question worth its 
> time in experiments ...
>
I have yet to find a hardware and codec encoding support table for 
Vaapi, but as seen above the Vaapi support with cingg w/o oneVPL on UB 
is more limited than cingg w/oneVPL on suse (hevc/H.265), both on 
KabyLake (2), and also vs the older SkyLake (3).

In my experience the hardware/qsv support may be some higher vs vaapi, 
and somewhat faster, and does fit well with the following tables:


    <https://trac.ffmpeg.org/wiki/Hardware/QuickSync#HardwareSupport>

Platform Name 	Graphics 	Adds support for...
Skylake 	gen9 	H.265 encode.
Kaby Lake 	gen9.5 	VP9 profile 2 decode; VP9, H.265 Main10 encode.
Alder Lake 	gen12 	-
DG2 	gen12 	AV1 encode.


Each new platform supports a superset of the capabilities of the 
previous platform.

https://trac.ffmpeg.org/wiki/Hardware/QuickSync#HardwareSupport
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20250105/e769cfcc/attachment.htm>