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

Andrew Randrianasulu randrianasulu at gmail.com
Sun Jan 5 18:38:05 CET 2025


вс, 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
;)

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



>
>
>
>
>
> --
> 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/20250105/7c77e897/attachment-0001.htm>


More information about the Cin mailing list