[Cin] another set of test profiles

[Terje J. Hanssen]

Den 18.10.2024 02:08, skrev Andrew Randrianasulu:
>
>
> чт, 17 окт. 2024 г., 15:06 Terje J. Hanssen <terjejhanssen at gmail.com>:
>
>
>
>
>     Den 17.10.2024 13:51, skrev Andrew Randrianasulu:
>>
>>
>>     чт, 17 окт. 2024 г., 13:40 Terje J. Hanssen
>>     <terjejhanssen at gmail.com>:
>>
>>
>>
>>
>>         Den 14.10.2024 00:38, skrev Andrew Randrianasulu:
>>>
>>>
>>>         пн, 14 окт. 2024 г., 01:36 Phyllis Smith
>>>         <phylsmith2017 at gmail.com>:
>>>
>>>             Andrew, so it seems prudent to check into GIT, the
>>>             av1_vaapi.mp4 render format (after successfully tested
>>>             of course); but what about the QSV encoders?
>>>
>>>
>>>
>>>         wait for Terje's testing OR try to build oneVPL-cpu (it sort
>>>         of circles back to different branch of ffmpeg, so ffmpeg
>>>         will think it uses qsv but it in fact will use another
>>>         ffmpeg .... well, in theory! it does not work for me on 32-bit!)
>>>
>>>
>>
>>         I wonder if Hw accellerated encoding support via Vaapi and
>>         QSV is to be embedded in future Cingg Appimage and/or
>>         packages if possible?
>>         What about a list of supported dGPUs/iGPUs?
>>
>>
>>     Problem is - QSV/vaapi  basically search for driver component and
>>     this one might be in different location on different distros, and
>>     interface between two also not set in stone.
>>
>>     For appimage you can just unpack them and remove libva.so so on
>>     startup cingg will link to system's libva.
>>
>>     QSV as we learned is another layer with their own runtime path
>>     for yet another set of driver components. So, while building
>>     libvpl itself is relatively easily making sure it finds its
>>     drivers is not easy (at least for me).
>>
>>     speaking about GPU list I think it will be fairly short,
>>     you,Phyllis and Andrea probably only ones who use it and report
>>     back. Stephan noticed some troubles and reverted back to
>>     software. I can test nvdec/nvenc on livecd but this is not my
>>     everyday setup (Nvidia proprietary drivers enforce 64-bit system).
>>
>>     But well, feel free to post short summary of that works on your
>>     GPUs in cingg as another thread, hopefully others will chime in!
>
>     If we get available a packaged Cingg test build (rpm/Leap for me),
>     it would be more useful to do this test. Then I have available
>     three gen. Intel, legacy Skylake/Kabylake iGPUs and current
>     DG2/Arc GPU. I also have/had a Nvidia GPU on Skylake, but it looks
>     like it past away.
>
>
> I think you can build rpm yourself, but for this we need to update 
> spec file, so it will point at new source and add openvpl as requirements.
>
> In meantime  you can just make your own appimage from just build 
> cingg-with-system-ffmpeg, so it hopefully will not be lost after few 
> system updates.
>

Andrey replied to me in a previous thread:
Hardware acceleration methods Sat, 14 Sep 2024 08:55:11 +0300
https://lists.cinelerra-gg.org/pipermail/cin/2024-September/008621.html
> >Is there something that prevent typical QSV to be prebuilt in the CinGG/FFmpeg rpm?
>
> The ffmpeg not installed on my suse build host. If you how to enable 
> QSV, I'll change the build script.
>

Is this a "path" we can continue with here?





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