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 .....
пт, 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 ?
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?
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 ?
Looking at ffbuild/config.log "qsv" is all over the place as in: av1_qsv_decoder, h264_qsv_decoder, hevc_qsv_decoder, mpeg2/vc1/av1/mjpeg/vp8/vp9/vvc AND av1_qsv_encoder, h264_encoder,etc. AS WELL as deinterlace_qsv_filter ...hstack_qsv_filter, etc., qsv_decode_example.
root@fedora:/mnt0/cinelerra-5.1/thirdparty/ffmpeg-8.0# *./ffmpeg -encoders | grep qsv* V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9) Question for Andrew - is there another executable that is necessary to add to the "linuxdeploy" line to create the AppImage -- I do not think so. I have commentary that states that "we need to include all executables so linuxdeploy picks all dependencies". Also, I ran the linuxdeploy on an earlier Fedora version that did not have either vulcan or onevpl installed -- again, I do not think that matters.
пт, 6 февр. 2026 г., 20:56 Phyllis Smith <[email protected]>:
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 ?
Looking at ffbuild/config.log "qsv" is all over the place as in: av1_qsv_decoder, h264_qsv_decoder, hevc_qsv_decoder, mpeg2/vc1/av1/mjpeg/vp8/vp9/vvc AND av1_qsv_encoder, h264_encoder,etc. AS WELL as deinterlace_qsv_filter ...hstack_qsv_filter, etc., qsv_decode_example.
root@fedora:/mnt0/cinelerra-5.1/thirdparty/ffmpeg-8.0# *./ffmpeg -encoders | grep qsv* V..... av1_qsv AV1 (Intel Quick Sync Video acceleration) (codec av1) V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) V..... mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) V..... vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9)
Question for Andrew - is there another executable that is necessary to add to the "linuxdeploy" line to create the AppImage -- I do not think so. I have commentary that states that "we need to include all executables so linuxdeploy picks all dependencies".
I think I saw some LADSPA filters missing their fftw3f libs on T2 linux and this appimage? But there are many of them, I'll try to capture full list today. Also, I ran the linuxdeploy on an earlier Fedora version that did not have
either vulcan or onevpl installed -- again, I do not think that matters.
As long as it was run in separate dir ... probably no. If you unpack appimage - can you see qsv symbols in cin binary with "nm -D" ?
If you unpack appimage - can you see qsv symbols in cin binary with "nm -D" ?
Ok, the qsv symbols are in the cinelerra-5.1/bin/cin actual file which I moved to another older O/S to do the linuxdeploy because I did not have linuxdeploy working on the newer O/S and thought it would work anyway:
[root@keystone tmp]# nm -D AppDir/usr/bin/cin | grep qsv 0000000004d55420 R ff_av1_qsv_decoder 0000000005d86140 D ff_av1_qsv_encoder 0000000004d55ae0 R ff_h264_qsv_decoder ... (a bunch more)
So linuxdeploy worked on that binary but it looks like I ran linuxdeploy on the wrong bin file that I moved over. Now that I redid things, I see I finally have the correct bin file with VPL, qsv, and vulcan symbols in it but I get the error:
... Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir -- Deploying dependencies for ELF file AppDir/usr/bin/mplexlo ERROR: *Could not find dependency: libvpl.so.2 *
I made a mess of things so I will have to get linuxdeploy working on the newer O/S that has the right stuff installed. Sorry for the mixup -- but in my defense I do have an eye appointment this afternoon for my ongoing eye problem!!!
On Fri, Feb 6, 2026 at 10:47 PM Phyllis Smith <[email protected]> wrote:
If you unpack appimage - can you see qsv symbols in cin binary with "nm -D" ?
Ok, the qsv symbols are in the cinelerra-5.1/bin/cin actual file which I moved to another older O/S to do the linuxdeploy because I did not have linuxdeploy working on the newer O/S and thought it would work anyway:
[root@keystone tmp]# nm -D AppDir/usr/bin/cin | grep qsv 0000000004d55420 R ff_av1_qsv_decoder 0000000005d86140 D ff_av1_qsv_encoder 0000000004d55ae0 R ff_h264_qsv_decoder ... (a bunch more)
So linuxdeploy worked on that binary but it looks like I ran linuxdeploy on the wrong bin file that I moved over. Now that I redid things, I see I finally have the correct bin file with VPL, qsv, and vulcan symbols in it but I get the error:
... Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir -- Deploying dependencies for ELF file AppDir/usr/bin/mplexlo ERROR: Could not find dependency: libvpl.so.2
I made a mess of things so I will have to get linuxdeploy working on the newer O/S that has the right stuff installed. Sorry for the mixup -- but in my defense I do have an eye appointment this afternoon for my ongoing eye problem!!!
Sorry! You can DROP all this screen stuff now and stay away from computers **as long as needed** - I'll rebuild my own testimages for Terje & anyone who interested in the meantime ...
I downloaded a new linuxdeploy on the new O/S but it fails so I will have to find a solution for this new error: ... Calling strip on library AppDir/usr/bin/zmpeg3ifochk Calling strip on library AppDir/usr/bin/zmpeg3show Calling strip on library AppDir/usr/bin/zmpeg3toc Calling strip on library AppDir/usr/lib/libFLAC.so.12 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libFLAC.so.12: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libFLAC.so.12' Calling strip on library AppDir/usr/lib/libXau.so.6 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6' On Fri, Feb 6, 2026 at 12:46 PM Phyllis Smith <[email protected]> wrote:
If you unpack appimage - can you see qsv symbols in cin binary with "nm
-D" ?
Ok, the qsv symbols are in the cinelerra-5.1/bin/cin actual file which I moved to another older O/S to do the linuxdeploy because I did not have linuxdeploy working on the newer O/S and thought it would work anyway:
[root@keystone tmp]# nm -D AppDir/usr/bin/cin | grep qsv 0000000004d55420 R ff_av1_qsv_decoder 0000000005d86140 D ff_av1_qsv_encoder 0000000004d55ae0 R ff_h264_qsv_decoder ... (a bunch more)
So linuxdeploy worked on that binary but it looks like I ran linuxdeploy on the wrong bin file that I moved over. Now that I redid things, I see I finally have the correct bin file with VPL, qsv, and vulcan symbols in it but I get the error:
... Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir -- Deploying dependencies for ELF file AppDir/usr/bin/mplexlo ERROR: *Could not find dependency: libvpl.so.2 *
I made a mess of things so I will have to get linuxdeploy working on the newer O/S that has the right stuff installed. Sorry for the mixup -- but in my defense I do have an eye appointment this afternoon for my ongoing eye problem!!!
пт, 6 февр. 2026 г., 23:10 Phyllis Smith <[email protected]>:
I downloaded a new linuxdeploy on the new O/S but it fails so I will have to find a solution for this new error:
...
Calling strip on library AppDir/usr/bin/zmpeg3ifochk Calling strip on library AppDir/usr/bin/zmpeg3show Calling strip on library AppDir/usr/bin/zmpeg3toc Calling strip on library AppDir/usr/lib/libFLAC.so.12 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libFLAC.so.12: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libFLAC.so.12'
Calling strip on library AppDir/usr/lib/libXau.so.6 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6'
https://github.com/linuxdeploy/linuxdeploy/issues/272 may be use NO_STRIP=true ? after all system libs usually already stripped. or try newest linuxdeploy ....
On Fri, Feb 6, 2026 at 12:46 PM Phyllis Smith <[email protected]> wrote:
If you unpack appimage - can you see qsv symbols in cin binary with "nm
-D" ?
Ok, the qsv symbols are in the cinelerra-5.1/bin/cin actual file which I moved to another older O/S to do the linuxdeploy because I did not have linuxdeploy working on the newer O/S and thought it would work anyway:
[root@keystone tmp]# nm -D AppDir/usr/bin/cin | grep qsv 0000000004d55420 R ff_av1_qsv_decoder 0000000005d86140 D ff_av1_qsv_encoder 0000000004d55ae0 R ff_h264_qsv_decoder ... (a bunch more)
So linuxdeploy worked on that binary but it looks like I ran linuxdeploy on the wrong bin file that I moved over. Now that I redid things, I see I finally have the correct bin file with VPL, qsv, and vulcan symbols in it but I get the error:
... Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/ Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/ Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/ Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/ Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir -- Deploying dependencies for ELF file AppDir/usr/bin/mplexlo ERROR: *Could not find dependency: libvpl.so.2 *
I made a mess of things so I will have to get linuxdeploy working on the newer O/S that has the right stuff installed. Sorry for the mixup -- but in my defense I do have an eye appointment this afternoon for my ongoing eye problem!!!
Calling strip on library AppDir/usr/lib/libXau.so.6
ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6'
https://github.com/linuxdeploy/linuxdeploy/issues/272
may be use
NO_STRIP=true ?
Yes, that fix works as far as I can tell. I already had the latest Nov. 7, 2026 linuxdeploy release. Now I am building again with the Vulkan_wip patch in and the ffv1_vulkan.mov render format in so I can find out if this AppImage will work for Terje. If so, then can add to the general releases in the future too.
On Sat, Feb 7, 2026 at 8:20 PM Phyllis Smith <[email protected]> wrote:
Calling strip on library AppDir/usr/lib/libXau.so.6 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6'
https://github.com/linuxdeploy/linuxdeploy/issues/272
may be use
NO_STRIP=true ?
Yes, that fix works as far as I can tell. I already had the latest Nov. 7, 2026 linuxdeploy release. Now I am building again with the Vulkan_wip patch
Note, while I get Vulkan initialization with it I still can't get actual encoded file It also only works this far if you set Hw accel wrench in Preferences to Vulkan in and the ffv1_vulkan.mov render format in so I can find out if this AppImage will work for Terje. If so, then can add to the general releases in the future too.
On Sat, Feb 7, 2026 at 8:35 PM Andrew Randrianasulu <[email protected]> wrote:
On Sat, Feb 7, 2026 at 8:20 PM Phyllis Smith <[email protected]> wrote:
Calling strip on library AppDir/usr/lib/libXau.so.6 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6'
https://github.com/linuxdeploy/linuxdeploy/issues/272
may be use
NO_STRIP=true ?
Yes, that fix works as far as I can tell. I already had the latest Nov. 7, 2026 linuxdeploy release. Now I am building again with the Vulkan_wip patch
Note, while I get Vulkan initialization with it I still can't get actual encoded file
It also only works this far if you set Hw accel wrench in Preferences to Vulkan
SORRY new wip, i forgot to set initial format ...
in and the ffv1_vulkan.mov render format in so I can find out if this AppImage will work for Terje. If so, then can add to the general releases in the future too.
On Sat, Feb 7, 2026 at 9:09 PM Andrew Randrianasulu <[email protected]> wrote:
On Sat, Feb 7, 2026 at 8:35 PM Andrew Randrianasulu <[email protected]> wrote:
On Sat, Feb 7, 2026 at 8:20 PM Phyllis Smith <[email protected]> wrote:
Calling strip on library AppDir/usr/lib/libXau.so.6 ERROR: Strip call failed: /tmp/.mount_linuxdJHHeHp/usr/bin/strip: AppDir/usr/lib/libXau.so.6: unknown type [0x13] section `.relr.dyn' /tmp/.mount_linuxdJHHeHp/usr/bin/strip: Unable to recognise the format of the input file `AppDir/usr/lib/libXau.so.6'
https://github.com/linuxdeploy/linuxdeploy/issues/272
may be use
NO_STRIP=true ?
Yes, that fix works as far as I can tell. I already had the latest Nov. 7, 2026 linuxdeploy release. Now I am building again with the Vulkan_wip patch
Note, while I get Vulkan initialization with it I still can't get actual encoded file
It also only works this far if you set Hw accel wrench in Preferences to Vulkan
SORRY
new wip, i forgot to set initial format ...
and now I think I set it correctly! as I said - VERY WIP
in and the ffv1_vulkan.mov render format in so I can find out if this AppImage will work for Terje. If so, then can add to the general releases in the future too.
On Sat, Feb 7, 2026 at 9:45 PM Phyllis Smith <[email protected]> wrote:
No problem -- keep them coming! It would be good to have vulkan working.
Yeah. THIS ONE hopefully autodetects vulkan codecs (4 of them hardcoded) so you can set hw (decode) acceleration to any value Still, some old hw encoding profiles relying on autodetected pixel format = vaapi now need explicit update to something like nv12 or what was default for them.
SORRY
new wip, i forgot to set initial format ...
and now I think I set it correctly!
as I said - VERY WIP
THIS ONE hopefully autodetects vulkan codecs (4 of them hardcoded) so you can set hw (decode) acceleration to any value
Still, some old hw encoding profiles relying on autodetected pixel format = vaapi now need explicit update to something like nv12 or what was default for them.
Just verifying that this patch - 0001-Experimental-vulkan-encode.patch - is the only vulkan patch to be applied. That is, previous vullkan-wip.diff is not applied? Correct?
пн, 9 февр. 2026 г., 02:05 Phyllis Smith <[email protected]>:
THIS ONE hopefully autodetects vulkan codecs (4 of them hardcoded) so
you can set hw (decode) acceleration to any value
Still, some old hw encoding profiles relying on autodetected pixel format = vaapi now need explicit update to something like nv12 or what was default for them.
Just verifying that this patch - 0001-Experimental-vulkan-encode.patch - is the only vulkan patch to be applied. That is, previous vullkan-wip.diff is not applied? Correct?
yes
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith