<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<br>
<div class="moz-cite-prefix">Den 05.01.2025 18:38, skrev Andrew
Randrianasulu:<br>
</div>
<blockquote type="cite"
cite="mid:CA+rFky6xv+TV5DsGyX_EwiY_=VuUyk-VBBvLN+o4LZsd-NvGsQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">вс, 5 янв. 2025 г., 18:39
Terje J. Hanssen via Cin <<a
href="mailto:cin@lists.cinelerra-gg.org" target="_blank"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">cin@lists.cinelerra-gg.org</a>>:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> <br>
<br>
<br>
<div>Den 05.01.2025 13:09, skrev Terje J. Hanssen:<br>
</div>
<blockquote type="cite"> <br>
<div>Den 04.01.2025 02:04, skrev Terje J. Hanssen:<br>
</div>
<blockquote type="cite">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 <br>
<br>
1) Intel Arc Alchemist w/ A750 dGPU (2023) <br>
<br>
av1_qsv_8b420.mp4, qsv_10b420.mp4 <br>
hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4,
hevc_qsv_10b422.mp4 <br>
<br>
av1_vaapi_8b420.mp4, vaapi_10b420.mp4 <br>
hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4,
hevc_vaapi_10b422.mp4 <br>
<br>
<br>
2) Intel KabyLake w/ UHD 620 iGPU (2017) <br>
<br>
hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4 <br>
hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4 <br>
<br>
The last line here is of special interest <br>
hevc_vaapi_8b420.mp4, hevc_vaapi_10b420.mp4 <br>
<br>
because Cingg deb on UB24.04 on this machine didn't
render hevc_vaapi. <br>
It seems that OneVPL (libvpl) extends the codec
capability also for vaapi. <br>
This has to be verified by dual-testing once more..
<br>
</blockquote>
<br>
A second attempt with UB24.04.1 on KabayLake confirms
the latter:<br>
<br>
Limit:<br>
<br>
hevc_vaapi_8b420.mp4<br>
[hevc_vaapi @ 0x769ae015a100] No usable encoding
entrypoint found for profile VAProfileHEVCMain (17).<br>
<br>
----------------------<br>
<br>
Additional test on my oldest workstation in use:<br>
<br>
3) Intel SkyLake w/ HD 530 iGPU (2015)<br>
<br>
cin<br>
Cinelerra Infinity - built: Jan 4 2025 01:10:37 (Leap
15.6)<br>
<br>
hevc_qsv_8b420.mp4, hevc_qsv_10b420.mp4<br>
<font face="Courier New, Courier, monospace">hdv09_04_h264_vaapi_8b420<br>
</font><font face="Courier New, Courier, monospace">
hevc_vaapi_8b420.mp4<br>
<br>
Limit:<br>
<br>
hevc_vaapi_10b420.mp4<br>
video/hdv09_04_hevc_vaapi_10b420.mp4<br>
[hevc_vaapi @ 0x7fe830011300] No usable encoding
profile found.<br>
<br>
-------------<br>
<br>
Another question while being in the confusing
corner:<br>
</font>
<blockquote>cin<br>
Cinelerra Infinity - built: Jan 4 2025 01:10:37
(Leap 15.6)<br>
</blockquote>
When rendering qsv, the following is output, but not
when rendering vaapi - and why not the opposite as I
rather would have expected? <br>
<blockquote> libva info: VA-API version 1.20.0<br>
libva info: Trying to open
/usr/lib64/dri/iHD_drv_video.so<br>
libva info: Found init function __vaDriverInit_1_20<br>
libva info: va_openDriver() returns 0</blockquote>
<font face="Courier New, Courier, monospace"><br>
</font></blockquote>
<br>
<font face="Courier New, Courier, monospace">Cinelerra
just repeates this output from the ffmpeg qsv encoding
(ffmpeg vaapi doesn't output this).<br>
And the "libva info" output comes from "vainfo", which
is part of "libva-utils"<br>
<a href="https://github.com/intel/libva-utils"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/intel/libva-utils</a><br>
<br>
So the remaining question is: what is really the
interaction (if any) between libva/libvpl and
vaapi/qsv?<br>
</font></div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I think libvpl can load "legacy" vaapi driver,
too ...</div>
<div dir="auto"><br>
</div>
<div dir="auto">Hopefully there is some description about that
on their github page?</div>
<div dir="auto"><br>
</div>
<div dir="auto"><a
href="https://intel.github.io/libvpl/latest/programming_guide/VPL_prg_hw.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://intel.github.io/libvpl/latest/programming_guide/VPL_prg_hw.html</a></div>
<div dir="auto"><br>
</div>
<div dir="auto">this link talk about vaapi as underlying api on
Linux.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Hopefully, this "bonus" feature will work across
few future driver releases ;)</div>
</div>
</blockquote>
<br>
Yes, thanks for throwing more light on this. <br>
<br>
oneVPL is said to be more high level and to give better portability.
<br>
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.<br>
<a class="moz-txt-link-freetext" href="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/onevpl-hardware-support-details.html</a><br>
<a class="moz-txt-link-freetext" href="https://www.intel.com/content/www/us/en/docs/onevpl/upgrade-from-msdk/2023-1/summary.html">https://www.intel.com/content/www/us/en/docs/onevpl/upgrade-from-msdk/2023-1/summary.html</a><br>
<br>
<blockquote type="cite"
cite="mid:CA+rFky6xv+TV5DsGyX_EwiY_=VuUyk-VBBvLN+o4LZsd-NvGsQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">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 ...</div>
<div dir="auto"><br>
</div>
</div>
</blockquote>
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).<br>
<br>
In my experience the hardware/qsv support may be some higher vs
vaapi, and somewhat faster, and does fit well with the following
tables:<br>
<br>
<h2 class="section" id="HardwareSupport"><a class="anchor"
href="https://trac.ffmpeg.org/wiki/Hardware/QuickSync#HardwareSupport"
title="Link to this section"></a></h2>
<table class="wiki">
<tbody>
<tr>
<th> Platform Name </th>
<th> Graphics </th>
<th> Adds support for... </th>
</tr>
<tr>
<td style="text-align: center"> Skylake </td>
<td style="text-align: center"> gen9 </td>
<td> H.265 encode. </td>
</tr>
<tr>
<td style="text-align: center"> Kaby Lake </td>
<td style="text-align: center"> gen9.5 </td>
<td> VP9 profile 2 decode; VP9, H.265 Main10 encode. </td>
</tr>
<tr>
<td style="text-align: center"> Alder Lake </td>
<td style="text-align: center"> gen12 </td>
<td> - </td>
</tr>
<tr>
<td style="text-align: center"> DG2 </td>
<td style="text-align: center"> gen12 </td>
<td> AV1 encode. </td>
</tr>
</tbody>
</table>
<br>
Each new platform supports a superset of the capabilities of the
previous platform. <br>
<br>
<a class="moz-txt-link-freetext" href="https://trac.ffmpeg.org/wiki/Hardware/QuickSync#HardwareSupport">https://trac.ffmpeg.org/wiki/Hardware/QuickSync#HardwareSupport</a><br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding">https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding</a><br>
<br>
<br>
</body>
</html>