On Fri, Feb 6, 2026 at 5:25 AM Andrew Randrianasulu <[email protected]> wrote:
пт, 6 февр. 2026 г., 04:19 Andrew Randrianasulu <[email protected]>:
https://github.com/obsproject/obs-studio/pull/10047
May be setting this to some location where other parts of onevpl live on suse will help with appimage's use of onevpl?
I'll inspect appimage, at least some traces of qsv should be there .....
Well, vulkan symbols ARE there, but onevpl ones not ..
From my desktop cin executable
nm -D /usr/bin/cin | less
press "/" and search for vpl
MFXClose@LIBVPL_2.0
and bunch of others
for appimage's cin executable I see no such symbols
Interestingly, cin does not link dynamically to onevpl loader, so probably it should work if we troubleshoot why this build failed to include all symbols ..
Dear Phyllis, can you check if ffmpeg binary in thirdparty/ffmpeg-8.0 for this build actually list qsv in its -encoder output, if you still have this tree around?
ffbuild/config.log us also interesting, but I assume it not complained at configure/build/link times ?
Just rebuilt cingg as Slackware package with all four new enables ... Indeed error in terminal now at least mention qsv: [h264_qsv @ 0xdabf5840] Error creating a MFX session: -9. FFMPEG::open_encoder err: Unknown error occurred int FFMPEG::open_encoder(const char*, const char*): open failed h264_qsv:/dev/shm/scr5.mp4 Render::render_single: Session finished. One possible difference is that I self-compiled oneVPL with static libs, and Fedora may package it without?