openshot-qt 🚀 - Crash when launching Preferences

Hmmmm. That's not good.

What video drivers does your system _actually_ use — like, what type of GPU do you have? Can you post the output of vainfo on your system?

ferdnyc on 9 Feb 2020

(For comparison, here's the output on my system:)

$ vainfo
libva info: VA-API version 1.6.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_5
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.6 (libva 2.6.0.pre1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

The fact that libva is looking for what appears to be an outdated init function:

libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32

...makes me think we're bundling an older libva in the AppImage. ...Yup, there it is:

$ ls /tmp/.mount_tUqvYU/usr/bin/libva*                           
/tmp/.mount_tUqvYU/usr/bin/libva-drm.so.1
/tmp/.mount_tUqvYU/usr/bin/libva.so.1
/tmp/.mount_tUqvYU/usr/bin/libva-x11.so.1

which is required by the libavcodec.so.57 bundled in the AppImage. Meanwhile, my system (probably like yours) includes newer libva releases:

$ ls /usr/lib64/libva[.-]*
/usr/lib64/libva-drm.so          /usr/lib64/libva.so.2.600.0
/usr/lib64/libva-drm.so.2        /usr/lib64/libva-wayland.so
/usr/lib64/libva-drm.so.2.600.0  /usr/lib64/libva-wayland.so.2
/usr/lib64/libva-glx.so          /usr/lib64/libva-wayland.so.2.600.0
/usr/lib64/libva-glx.so.2        /usr/lib64/libva-x11.so
/usr/lib64/libva-glx.so.2.600.0  /usr/lib64/libva-x11.so.2
/usr/lib64/libva.so              /usr/lib64/libva-x11.so.2.600.0
/usr/lib64/libva.so.2

Which the bundled libavcodec.so.57 can't use. Grumpf. This is... tricky.

ferdnyc on 9 Feb 2020

What video drivers does your system actually use — like, what type of GPU do you have? Can you post the output of vainfo on your system?

I guess my system uses the built in Intel drivers. I have an Intel Iris Pro 5200.

libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Mobile - 2.3.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD

DylanC on 9 Feb 2020

Interestingly, though, the AppImage _doesn't_ crash on my system. It doesn't successfully load any of the hardware acceleration drivers, which I wish surprised me... but it doesn't crash, either.

Console output when opening Preferences:

ui_util:INFO Initializing UI for dlgPreferences
Hardware decoding device number: 0
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
[AVHWDeviceContext @ 0x2ba1700] Failed to initialise VAAPI connection: -1 (unknown libva error).
Hardware decoding device number: 0
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
[AVHWDeviceContext @ 0x2c92960] Failed to initialise VAAPI connection: -1 (unknown libva error).
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 1-0
Hardware decoding device number: 1
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x2c83400] Failed to initialise VAAPI connection: -1 (unknown libva error).
Hardware decoding device number: 1
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x2c88260] Failed to initialise VAAPI connection: -1 (unknown libva error).
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 1-1
Hardware decoding device number: 0
Hardware decoding device number: 0
[AVHWFramesContext @ 0x31c75e0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c38c80] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c38c80] decode_slice_header error
[h264 @ 0x2c38c80] no frame!
[AVHWFramesContext @ 0x31c7880] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c4a7a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c4a7a0] decode_slice_header error
[h264 @ 0x2c4a7a0] no frame!
[AVHWFramesContext @ 0x31c7880] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c7a600] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c7a600] decode_slice_header error
[h264 @ 0x2c7a600] no frame!
[AVHWFramesContext @ 0x31cc6e0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2d4b5e0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2d4b5e0] decode_slice_header error
[h264 @ 0x2d4b5e0] no frame!
[AVHWFramesContext @ 0x31c7d60] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c38c80] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c38c80] decode_slice_header error
[h264 @ 0x2c38c80] no frame!
[AVHWFramesContext @ 0x31cc6e0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c4a7a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c4a7a0] decode_slice_header error
[h264 @ 0x2c4a7a0] no frame!
[AVHWFramesContext @ 0x31c7d40] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c7a600] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c7a600] decode_slice_header error
[h264 @ 0x2c7a600] no frame!
[AVHWFramesContext @ 0x31cc6e0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2d4b5e0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2d4b5e0] decode_slice_header error
[h264 @ 0x2d4b5e0] no frame!
[AVHWFramesContext @ 0x2ed6b00] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c38c80] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c38c80] decode_slice_header error
[h264 @ 0x2c38c80] no frame!
[AVHWFramesContext @ 0x322a960] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2c4a7a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2c4a7a0] decode_slice_header error
[h264 @ 0x2c4a7a0] no frame!
 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 2-0
Hardware decoding device number: 1
Hardware decoding device number: 1
[AVHWFramesContext @ 0x30c2ca0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2ff59a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2ff59a0] decode_slice_header error
[h264 @ 0x2ff59a0] no frame!
[AVHWFramesContext @ 0x30c2f00] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x3004fa0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x3004fa0] decode_slice_header error
[h264 @ 0x3004fa0] no frame!
[AVHWFramesContext @ 0x30c2f60] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x3185340] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x3185340] decode_slice_header error
[h264 @ 0x3185340] no frame!
[AVHWFramesContext @ 0x30c8ba0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x31a16a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x31a16a0] decode_slice_header error
[h264 @ 0x31a16a0] no frame!
[AVHWFramesContext @ 0x30c2ae0] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2ff59a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2ff59a0] decode_slice_header error
[h264 @ 0x2ff59a0] no frame!
[AVHWFramesContext @ 0x30c3060] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x3004fa0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x3004fa0] decode_slice_header error
[h264 @ 0x3004fa0] no frame!
[AVHWFramesContext @ 0x30c3060] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x3185340] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x3185340] decode_slice_header error
[h264 @ 0x3185340] no frame!
[AVHWFramesContext @ 0x30c3060] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x31a16a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x31a16a0] decode_slice_header error
[h264 @ 0x31a16a0] no frame!
[AVHWFramesContext @ 0x30c3060] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x2ff59a0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x2ff59a0] decode_slice_header error
[h264 @ 0x2ff59a0] no frame!
[AVHWFramesContext @ 0x30c2320] The hardware pixel format 'vdpau' is not supported by the device type 'CUDA'
[h264 @ 0x3004fa0] Device supplied for VAAPI decoding must be a VAAPI device (not 1).
[h264 @ 0x3004fa0] decode_slice_header error
[h264 @ 0x3004fa0] no frame!
 preferences:WARNING CheckPixel failed testing hardware decoding in preferences (i.e. wrong color found): 2-1
Hardware decoding device number: 0
[AVHWDeviceContext @ 0x2f66fc0] Cannot open the X11 display /dev/dri/renderD128.
Hardware decoding device number: 0
[AVHWDeviceContext @ 0x26fae80] Cannot open the X11 display /dev/dri/renderD128.
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 6-0
Hardware decoding device number: 1
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[AVHWDeviceContext @ 0x2bc80e0] VDPAU device creation on X11 display :1 failed.
Hardware decoding device number: 1
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
[AVHWDeviceContext @ 0x2fcc1c0] VDPAU device creation on X11 display :1 failed.
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 6-1
Hardware decoding device number: 0
Hardware decoding device number: 0
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 7-0
Hardware decoding device number: 1
Hardware decoding device number: 1
 preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 7-1

ferdnyc on 9 Feb 2020

Hate to say it, but I think we need to see the rest of that traceback, in your screenshot — the stuff above the window border. Think you could reproduce it and grab the whole thing? Or even better, the complete console output of the AppImage run? (Sorry...)

ferdnyc on 9 Feb 2020

Its fine. I'm doing some software dev. Just a simple context switch. :smiley:

./OpenShot-v2.5.0-x86_64.AppImage
Loaded modules from current directory: /tmp/.mount_RsJI8F/usr/bin
app:INFO ------------------------------------------------
app:INFO Sun Feb 9 19:52:51 2020
app:INFO Starting new session
app:INFO ------------------------------------------------
app:INFO OpenShot (version 2.5.0)
app:INFO ------------------------------------------------
app:INFO openshot-qt version: 2.5.0
app:INFO libopenshot version: 0.2.4
app:INFO platform: Linux-5.3.0-7625-generic-x86_64-with-Ubuntu-19.10-eoan
app:INFO processor: x86_64
app:INFO machine: x86_64
app:INFO python version: 3.4.3
app:INFO qt5 version: 5.2.1
app:INFO pyqt5 version: 5.2.1
language:INFO Qt Detected Languages: ['en-US', 'en']
language:INFO LANG Environment Variable: en_US.UTF-8
language:INFO LOCALE Environment Variable:
language:INFO OpenShot Preference Language: Default
project_data:INFO Setting default profile to HD 720p 30 fps
app:INFO Setting font to /tmp/.mount_RsJI8F/usr/bin/images/fonts/Ubuntu-R.ttf
logger_libopenshot:INFO Connecting to libopenshot with debug port: 5556
app:INFO Setting custom dark theme
QMainWindow::addDockWidget: invalid 'area' argument
ui_util:INFO Initializing UI for MainWindow
connectionpool:INFO Starting new HTTP connection (1): www.openshot.org
files_model:INFO updating files model.
transition_model:INFO updating transitions model.
effects_model:INFO updating effects model.
properties_model:INFO updating clip properties model.
transition_model:INFO updating transitions model.
files_model:INFO updating files model.
main_window:INFO InitCacheSettings
main_window:INFO cache-mode: CacheMemory
main_window:INFO cache-limit-mb: 250
main_window:INFO Creating CacheMemory object with 262144000 byte limit
preview_thread:INFO QThread Start Method Invoked
preview_thread:INFO initPlayer
main_window:ERROR Unhandled crash detected... will attempt to recover backup project: /home/dylan/.openshot_qt/backup.osp
main_window:INFO updateStatusChanged
main_window:INFO updateStatusChanged
app:INFO Process command-line arguments: ['/tmp/.mount_RsJI8F/usr/bin/openshot-qt']
main_window:INFO recover_backup
project_data:INFO Setting default profile to HD 720p 30 fps
preview_thread:INFO refreshFrame
preview_thread:INFO self.player.Position(): 1
video_widget:INFO Load: Set video widget display aspect ratio to: 1.7777777910232544
video_widget:INFO Set video widget pixel aspect ratio to: 1.0
main_window:INFO updateStatusChanged
preview_thread:INFO onModeChanged
properties_model:INFO Update item:
properties_model:INFO updating clip properties model.
preview_thread:INFO refreshFrame
preview_thread:INFO self.player.Position(): 1
timeline:INFO Adjusting max size of preview image: PyQt5.QtCore.QSize(724, 407)
preview_thread:INFO refreshFrame
preview_thread:INFO self.player.Position(): 1
timeline_webview:INFO Qt Found!
timeline_webview:INFO $scope.Qt = true;
timeline_webview:INFO SetThumbAddress: http://127.0.0.1:34705/thumbnails/
timeline_webview:INFO SortItems
timeline_webview:INFO UpdateLayerIndex
timeline_webview:INFO UpdateLayerIndex
ui_util:INFO Initializing UI for dlgPreferences
Hardware decoding device number: 0
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x32f8740] Failed to initialise VAAPI connection: -1 (unknown libva error).
Hardware decoding device number: 0
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x302efa0] Failed to initialise VAAPI connection: -1 (unknown libva error).
preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 1-0
Hardware decoding device number: 1
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x231d260] Failed to initialise VAAPI connection: -1 (unknown libva error).
Hardware decoding device number: 1
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x22fdca0] Failed to initialise VAAPI connection: -1 (unknown libva error).
preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 1-1
Hardware decoding device number: 0
Cannot load libcuda.so.1
[AVHWDeviceContext @ 0x302be60] Could not dynamically load CUDA
Hardware decoding device number: 0
Cannot load libcuda.so.1
[AVHWDeviceContext @ 0x3070d60] Could not dynamically load CUDA
preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 2-0
Hardware decoding device number: 1
Cannot load libcuda.so.1
[AVHWDeviceContext @ 0x30b3f00] Could not dynamically load CUDA
Hardware decoding device number: 1
Cannot load libcuda.so.1
[AVHWDeviceContext @ 0x3316ee0] Could not dynamically load CUDA
preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 2-1
Hardware decoding device number: 0
[AVHWDeviceContext @ 0x3026640] Cannot open the X11 display /dev/dri/renderD128.
Hardware decoding device number: 0
[AVHWDeviceContext @ 0x2c58fa0] Cannot open the X11 display /dev/dri/renderD128.
preferences:WARNING Exception trying to test hardware decoding in preferences (this is expected): 6-0
Hardware decoding device number: 1
libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
Hardware decoding device number: 1
libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
Caught signal 11 (SIGSEGV)
---- Unhandled Exception: Stack Trace ----
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x22053) [0x7fe55628f053]
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x23eaa) [0x7fe556290eaa]
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x24399) [0x7fe556291399]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( + 0x2a294) [0x7fe630df1294]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( av_buffer_pool_get + 0xa2 ) [0x7fe630ddcae2]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( + 0x2a085) [0x7fe630df1085]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( av_hwframe_get_buffer + 0x102 ) [0x7fe630decbb2]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( avcodec_default_get_buffer2 + 0x37 ) [0x7fe62ab37007]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x1ebd8b) [0x7fe62ab37d8b]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x572fef) [0x7fe62aebefef]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x3036ab) [0x7fe62ac4f6ab]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x30437b) [0x7fe62ac5037b]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x308a76) [0x7fe62ac54a76]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x30cba7) [0x7fe62ac58ba7]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( + 0x571f19) [0x7fe62aebdf19]
/lib/x86_64-linux-gnu/libpthread.so.0 ( + 0x9669) [0x7fe63bc44669]
/lib/x86_64-linux-gnu/libc.so.6 ( clone + 0x43 ) [0x7fe63bb6c323]
---- End of Stack Trace ----
Caught signal 11 (SIGSEGV)
---- Unhandled Exception: Stack Trace ----
Segmentation fault (core dumped)

DylanC on 9 Feb 2020

Hmmm. Interesting. I have libvdpau-va-gl installed on my system as well... but it's probably not being loaded, since my system uses the Nvidia backend, not the OpenGL/VAAPI backend.

While you have the AppImage mounted and open, what's the output of this command?

$ ldd /tmp/.mount*/usr/bin/libavutil.so.55
    linux-vdso.so.1 (0x00007ffcf7871000)
    libX11.so.6 => /lib64/libX11.so.6 (0x00007f0b2c93a000)
    libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f0b2c926000)
    libvdpau.so.1 => /lib64/libvdpau.so.1 (0x00007f0b2c920000)
    libva.so.1 => not found
    libva-x11.so.1 => not found
    libva-drm.so.1 => not found
    libm.so.6 => /lib64/libm.so.6 (0x00007f0b2c7d8000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f0b2c7d1000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0b2c7af000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f0b2c5e6000)
    libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f0b2c5bb000)
    libXext.so.6 => /lib64/libXext.so.6 (0x00007f0b2c5a6000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f0b2cd6e000)
    libXau.so.6 => /lib64/libXau.so.6 (0x00007f0b2c59e000)

I have a feeling your system may be using the bundled libvdpau.so.1, instead.

ferdnyc on 9 Feb 2020

You might be right!

ldd /tmp/.mount*/usr/bin/libavutil.so.55
linux-vdso.so.1 (0x00007ffd7bbcb000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f64e5f59000)
libdrm.so.2 => /lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f64e5f45000)
libvdpau.so.1 => /lib/x86_64-linux-gnu/libvdpau.so.1 (0x00007f64e5f3f000)
libva.so.1 => not found
libva-x11.so.1 => not found
libva-drm.so.1 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f64e5dee000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f64e5de8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f64e5dc5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f64e5bd4000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f64e5bab000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f64e5b96000)
/lib64/ld-linux-x86-64.so.2 (0x00007f64e633d000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f64e5b8e000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f64e5b86000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f64e5b6c000)

DylanC on 9 Feb 2020

Yeah, OK, same. Makes sense as actually _my_ system is also using the bundled libvdpau.so.1, in the AppImage:

$ sudo lsof -p 288959|grep vdpau
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.OpenShot-v2.5.0-dev1-optimized_effects-x86_64.AppImage file
 system /tmp/.mount_tUqvYU
      Output information may be incomplete.
openshot- 288959 ferd  mem       REG               0,62                109 
/tmp/.mount_tUqvYU/usr/bin/libvdpau.so.1 (stat: Permission denied)

...And it doesn't know to look in /usr/lib64/vdpau/ for libvdpau_nvidia.so.1, which is why it can't load it.

It probably does know to look in /usr/lib/x86_64-linux-gnu/dri/ and /usr/lib/x86_64-linux-gnu/vdpau/ on _your_ system, though, as it's built with Debian-style paths. Which may explain the crashing, whereas on my system it simply fails to find the hardware drivers.

I am really not sure how we're going to make hardware acceleration work in the AppImages, though. They can't _bundle_ all of the hardware drivers (and I doubt it would work even if they did), and the ones available on the system are too varied to be compatible in all instances.

ferdnyc on 9 Feb 2020

The only thing I can think that might work is if we have two AppImage builds: One would be linked with libva.so.1 (using the FFmpeg 3.4 build they're currently built with), for older systems. The other would probably be an FFmpeg 4 build linked with libva.so.2, for newer systems.

That seems to be one of the key factors, in terms of compatibility. And neither would bundle the libva libraries, because it seems like we need to be using the system libs in order to have even a ghost of a chance of loading the correct hardware drivers. (Which means we might then also need a THIRD AppImage, _without_ hardware acceleration support at all and not linked with any version of libva, for systems that don't have it available. Ugh.)

ferdnyc on 9 Feb 2020

Yup, exactly as I suspected. The bundled libvdpau only knows how to look in Debian paths, for the VDPAU drivers:

$ strings /usr/lib64/libvdpau.so.1|grep usr
/usr/lib64/vdpau
/usr/lib64/vdpau/libvdpau_trace.so.1
$ strings /tmp/.mount*/usr/bin/libvdpau.so.1|grep usr
/usr/lib/vdpau/
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1
/usr/lib/x86_64-linux-gnu/vdpau/

We could try to unbundle libvdpau, so that the AppImage will use the system copy... and either it will succeed in loading the drivers on my system (maybe even both our systems), or it'll also start crashing.

ferdnyc on 10 Feb 2020

Hmm. Quoting from libopenshot's doc/HW-ACCEL.md:

Libva / VA-API (Video Acceleration API)

The correct version of libva is needed (libva in Ubuntu 16.04 or libva2
in Ubuntu 18.04) for the AppImage to work with hardware acceleration.
An AppImage that works on both systems (supporting libva and libva2),
might be possible when no libva is included in the AppImage.

vaapi is working for intel and AMD

vaapi is working for decode only for nouveau

nVidia driver is working for export only

...it appears that this is a known issue with the AppImages. It's just unfortunate that it was never addressed, beyond being documented. (Also, to the point there about being able to build an AppImage that works on both systems, that's likely impossible as libavutil is _linked with_ libva (as shown in previous comments) — so whatever version it's linked with is the version that needs to be available.)

Fortunately, Ubuntu 16.04 is reaching EOL in around 2.5 months, after which point it'd be perfectly reasonable to build AppImages linked with libva.so.2 instead of libva.so.1, avoiding this problem entirely.

like libvdpau.so.1, we should not include libva in the AppImage bundle, and for the same reason: The path to its hardware drivers is both system-dependent, and encoded in the library itself. On Fedora:

$ strings /usr/lib64/libva.so.2|grep usr
/usr/lib64/dri
$ strings /tmp/.mount*/usr/bin/libva.so.1|grep usr             
/usr/lib/x86_64-linux-gnu/dri

Bundling libva or libvdpau ensures that the AppImage will only _ever_ support hardware accel on Debian-based distros.

ferdnyc on 10 Feb 2020

Fortunately, Ubuntu 16.04 is reaching EOL in around 2.5 months, after which point it'd be perfectly reasonable to build AppImages linked with libva.so.2 instead of libva.so.1, avoiding this problem entirely.

(Note: As far as I'm concerned, that's a perfectly reasonable thing to do NOW, instead of breaking all newer systems just to keep 2016-era Ubuntu limping along. But, once it's EOL there's really no excuse for not updating.)

ferdnyc on 10 Feb 2020

@ferdnyc - I suppose all I would be looking for in the case of launching the Preferences is a graceful failure. (handle the exception)

To the average user they won't know the background about hardware acceleration. All they know is they downloaded OpenShot. Clicked Preferences and it crashed/closed without any visible error.

DylanC on 10 Feb 2020

I wonder how easy it would be to handle this crash, and at least prevent the seg fault... Is it crashing inside the FFMpeg implementation of libva? I'm open to suggestions.

jonoomph on 11 Feb 2020

It can be Intel's bug. https://github.com/OpenShot/openshot-qt/issues/3221
I mean, that this is quite possible that this is driver bug.

The simplest solution, as for me, is to have "safe" startup that do not performs the check for HW encoders/decoders and add new button in _Preferences_ that will do this on request. Also, OpenShot needs to fall back to "safe" settings if any attempt to use such decoders/encoders fails, like: load setting, save SW setting, apply previously loaded setting, save HW or SW setting depending on result of the apply. Thus, user will be aware that application crashed when some HW acceleration support was tested. And the program will start next time safe.

SuslikV on 13 Feb 2020

@jonoomph

Is it crashing inside the FFMpeg implementation of libva?

I'm not sure is the honest answer. I have a busy new job and no time to investigate unfortunately. Just thought it would be good to report it here.

Also it was mentioned on OmgUbuntu by a user:

I tried this in both Windows and Linux. In Windows it crashed when I tried to set preferences

@SuslikV

The simplest solution, as for me, is to have "safe" startup that do not performs the check for HW encoders/decoders and add new button in Preferences that will do this on request. Also, OpenShot needs to fall back to "safe" settings if any attempt to use such decoders/encoders fails, like: load setting, save SW setting, apply previously loaded setting, save HW or SW setting depending on result of the apply. Thus, user will be aware that application crashed when some HW acceleration support was tested. And the program will start next time safe.

Good idea! 👍

DylanC on 13 Feb 2020

...Also it was mentioned on OmgUbuntu by a user

Interesting how many cards he had in his system and what card was assigned to the OpenShot.exe.

SuslikV on 13 Feb 2020

I have linked the thread above and I can say that at least in one case the user uses old Intel's driver (W10) and there was change: https://software.intel.com/en-us/forums/media/topic/800921 that directly affects the HW acceleration of Intel's GPUs. This may be important info.

SuslikV on 18 Feb 2020

I was writing an email to @jonoomph about this one, but I see that it's been spotted.

I wonder how easy it would be to handle this crash, and at least prevent the seg fault... Is it crashing inside the FFMpeg implementation of libva? I'm open to suggestions.

Well, it's interesting. There are two things going on there, based on the traceback @DylanC posted.

The bundled libva.so.1 is failing to load _any_ of the hardware drivers from /usr/lib/x86_64-linux-gnu/dri, because they all implement the libva.so.2 API, and are therefore missing a symbol that the bundled libva expects to find.:
```
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32
libva info: va_openDriver() returns -1
[AVHWDeviceContext @ 0x231d260] Failed to initialise VAAPI connection: -1
(unknown libva error).
```
...But that's not actually causing the _crash_. (It's just a reason why, even if OpenShot wasn't crashing, hardware accel would never work in the AppImage on @DylanC 's system.)

The crash actually comes about when the bundled libavutil attempts to load the va-api VDPAU driver from the system /usr/lib/x86_64-linux-gnu/vdpau/ path:

Caught signal 11 (SIGSEGV)
---- Unhandled Exception: Stack Trace ----
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x22053) [0x7fe55628f053]
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x23eaa) [0x7fe556290eaa]
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_va_gl.so.1 ( + 0x24399) [0x7fe556291399]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( + 0x2a294) [0x7fe630df1294]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( av_buffer_pool_get + 0xa2 ) [0x7fe630ddcae2]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( + 0x2a085) [0x7fe630df1085]
/tmp/.mount_RsJI8F/usr/bin/libavutil.so.55 ( av_hwframe_get_buffer + 0x102 ) [0x7fe630decbb2]
/tmp/.mount_RsJI8F/usr/bin/libavcodec.so.57 ( avcodec_default_get_buffer2 + 0x37 ) [0x7fe62ab37007]

That's very likely because @DylanC 's libvdpau_va_gl.so.1, like mine, is linked with libva.so.2 which will be loaded from the system path:

$ ldd /usr/lib64/vdpau/libvdpau_va_gl.so.1 |grep libva
    libva-x11.so.2 => /lib64/libva-x11.so.2 (0x00007f7119ce8000)
    libva.so.2 => /lib64/libva.so.2 (0x00007f7119cc1000)

Incompatible APIs start flying around and boom.

The one thing I'm not clear on is whether libvdpau.so.1 is involved here. You'd _think_ so, but it doesn't show up in the backtrace. However, I kind of think it _has to_ be involved, because libavutil doesn't know the path to the driver directory — only libvdpau does.

$ for lib in libavutil.so.55 libvdpau.so.1; do echo; echo "===$lib"; (strings $lib | grep usr); done

===libavutil.so.55
--prefix=/usr --extra-version='1~14.04.york0' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libmodplug --enable-libopus --enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared

===libvdpau.so.1
/usr/lib/vdpau/
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1
/usr/lib/x86_64-linux-gnu/vdpau/

So the open question is whether it would therefore improve things if we unbundled libvdpau.so.1. It'll be the same SONAME version on every system where it's present, so it doesn't have the same API break as libva.so.[12], but it does have the same path-discovery issue. However, the path issue isn't what's causing the crashes — clearly, libavutil is finding the driver... which is then crashing when it gets loaded.

So my gut says that, no, unbundling libvdpau.so.1 wouldn't help. If anything, it would probably make OpenShot start crashing on systems like mine, where libvdpau_va_gl.so.1 is located in /usr/lib64/vdpau/, but will be linked to libva.so.2 same as any newer system. I think the inability to find that library is the only thing saving non-Debian-based systems from similar crashes, when running the AppImage.

ferdnyc on 10 Mar 2020

_Right now_, my honest feeling is that it's probably safest to eliminate all hardware accel support from the AppImage, and ship a bundled ffmpeg that's linked with _neither_ libva nor libvdpau, so that it won't even try to load the hardware drivers. Because as things stand right now, the only systems where the AppImage might even _possibly_ support hardware accel are the oldest Debian-based distros — the ones where /usr/lib/x86_64-linux-gnu/dri/ and /usr/lib/x86_64-linux-gnu/vdpau/ both exist, and contain drivers compatible with the bundled libs. And I don't see any path to _unbundling_ them, that works on all of the systems we want the AppImage to run on.

So if we're including _potential_ support for hardware accel that could only work on those systems, but it's causing the AppImage to _crash_ on other, newer systems, that feels like a really bad tradeoff.

However, I know that at least Avidemux ships as an AppImage build, so they must've solved or at least _encountered_ this themselves. I'm going to wander off to their repos/forums now, and see if mean or any of the other developers have any insights.

ferdnyc on 10 Mar 2020

Excellent detective work @ferdnyc! Looking forward to reading up on your findings.

DylanC on 10 Mar 2020

Ah. Posted just a few weeks ago, by one of the Avidemux developers regarding their own AppImage builds:

For a fully featured Avidemux, especially on computers with Intel graphics, please build from source instead of relying on appImage as provided Avidemux appImages don't support hw accel via libva.

Guess that answers that. They took the route I advocate above. sad trombone

...Oh-ho! Now, _this_ is interesting. Poking around inside their latest AppImage, it seems that they _do_ bundle VDPAU support, which is working on my Fedora system. _Iiiiiinteresting._

Now, keep in mind, VDPAU doesn't really do much for us, because it's a decode-only API — it has no hardware-encoding features whatsoever. And since our playback is mostly generated on-the-fy and can't be accelerated, having VDPAU enabled buys us next-to-nothing.

For useful hardware acceleration on Nvidia GPUs, you'd want to be have the option to _encode_ with Nvenc, and as expected I'm not seeing any sign of that here in the AppImage build. (Nvenc encoding is available for both x264 and HEVC, along with libva decoding on both Nvidia and Intel GPUs, when avidemux is running from my installed native Fedora package. Just as Nvenc encoding is available in OpenShot, when it's installed natively.)

Still, color me curious about their techniques. (Fair warning: Pull the ripcord now, if yet another post rooting around the internals of Linux shared-library loading doesn't sound like the sort of thing you'd be interested in.)

Bundled drivers!?

Interestingly, they appear to bundle not only libvdpau.so.1, but _also_ the nvidia_drv_video.so hardware driver. Oh, and there's an Intel i965_drv_video.so as well:

$ ls -l /tmp/.mount_*/usr/lib/libv*
-rw-r--r--. 1 root ferd  89k Aug 14  2019 /tmp/.mount_PeR4ln/usr/lib/libva.so.1
-rw-r--r--. 1 root ferd  24k Aug 14  2019 /tmp/.mount_PeR4ln/usr/lib/libva-x11.so.1
-rw-r--r--. 1 root ferd  15k Aug 14  2019 /tmp/.mount_PeR4ln/usr/lib/libvdpau.so.1

$ ls -l /tmp/.mount_*/usr/lib/*drv*
-rw-r--r--. 1 root ferd 1.6M Aug 14  2019 /tmp/.mount_PeR4ln/usr/lib/i965_drv_video.so
-rw-r--r--. 1 root ferd  98k Aug 14  2019 /tmp/.mount_PeR4ln/usr/lib/nvidia_drv_video.so

Bundled (but unused) libva.so.1

Curiously, the Intel driver library appears to be the _only_ one linked with libva.so.1, which perhaps explains why Intel hwaccel doesn't work in the AppImage:

$ LD_LIBRARY_PATH="." && for file in *.so*; do (echo "===$file;"; ldd ${file} |grep -i libva); done 

===i965_drv_video.so;
    libva.so.1 => ./libva.so.1 (0x00007f7ac4f69000)
===libADM6avcodec.so.58;
===libADM6avformat.so.58;
===libADM6avutil.so.56;
===libADM6postproc.so.55;
===libADM6swscale.so.5;
===libADM_audioParser6.so;
===libADM_core6.so;
===libADM_coreAudio6.so;
===libADM_coreAudioDevice6.so;
===libADM_coreAudioEncoder6.so;
===libADM_coreAudioFilterAPI6.so;
===libADM_coreDemuxer6.so;
===libADM_coreDemuxerMpeg6.so;
===libADM_coreImage6.so;
===libADM_coreImageLoader6.so;
===libADM_coreJobs.so;
===libADM_coreMuxer6.so;
===libADM_coreScript.so;
===libADM_coreSocket6.so;
===libADM_coreSqlLight3.so;
===libADM_coreSubtitles6.so;
===libADM_coreUI6.so;
===libADM_coreUtils6.so;
===libADM_coreVDPAU6.so;
===libADM_coreVideoCodec6.so;
===libADM_coreVideoEncoder6.so;
===libADM_coreVideoFilter6.so;
===libADM_openGLQT56.so;
===libADM_render6_QT5.so;
===libADM_UIQT56.so;
===libaften.so.0;
===libexpat.so.1;
===libfaac.so.0;
===libfaad.so.2;
===libfdk-aac.so.0;
===libffi.so.6;
===libglib-2.0.so.0;
===libgobject-2.0.so.0;
===libgthread-2.0.so.0;
===libjson-c.so.2;
===libjson.so.0;
===libmp3lame.so.0;
===libogg.so.0;
===libopus.so.0;
===libpcre.so.3;
===libpng12.so.0;
===libpulsecommon-5.0.so;
===libpulse-simple.so.0;
===libpulse.so.0;
===libsqlite3.so.0;
===libudev.so.1;
===libva.so.1;
===libva-x11.so.1;
    libva.so.1 => ./libva.so.1 (0x00007f84d70fc000)
===libvdpau.so.1;
===libvorbisenc.so.2;
===libvorbis.so.0;
===libx264.so.152;
===libx265.so.146;
===libXv.so.1;
===nvidia_drv_video.so;

Bundled (but also native) libvdpau.so.1

When running, the process ends up loading libvdpau.so.1 _both_ from the bundled directory, and my native host path, which is odd. But ultimately the driver gets loaded from the host system path, and that bundled nvidia_drv_video.so seems to be unnecessary. (It's probably there to avoid crashes on systems where it isn't available natively.)

$ lsof -p `pidof avidemux3_portable` 2>/dev/null|sed -e 's/ferd.\{20\}//g'|grep -i libv
avidemux3 1569526           0,71   731304       95 /tmp/.mount_PeR4ln/usr/lib/libvorbisenc.so.2
avidemux3 1569526           0,71   183040       85 /tmp/.mount_PeR4ln/usr/lib/libvorbis.so.0
avidemux3 1569526          253,0   677136  1420988 /usr/lib64/vdpau/libvdpau_nvidia.so.440.64
avidemux3 1569526          253,0    21152  1353094 /usr/lib64/libvdpau.so.1.0.0
avidemux3 1569526           0,71    14600       38 /tmp/.mount_PeR4ln/usr/lib/libvdpau.so.1

VDPAU driver discovery

Not sure exactly how it's finding /usr/lib64/vdpau/libvdpau_nvidia.so*, or even /usr/lib64/libvdpau.so.1.0.0 for that matter. It looks like they patched the paths stored in the bundled libraries to make them non-distro-specific, that's a technique I've seen used in other AppImage builds.

$ strings ./libvdpau.so.1|grep -i vdpau
libvdpau.so.1
/etc/vdpau_wrapper.cfg
VDPAU_DRIVER
VDPAU_DRIVER_PATH
%s/libvdpau_%s.so.1
VDPAU_TRACE
libvdpau_%s.so
${ORIGIN}/vdpau
././/lib/vdpau
Failed to open VDPAU backend %s
./././././././././././lib/vdpau/libvdpau_trace.so.1
Failed to open VDPAU trace library %s
./././././././././././lib/vdpau

$ strings /usr/lib64/libvdpau.so.1.0.0|grep -i vdpau
libvdpau.so.1
/etc/vdpau_wrapper.cfg
VDPAU_DRIVER
VDPAU_DRIVER_PATH
%s/libvdpau_%s.so.1
/usr/lib64/vdpau
libvdpau_%s.so
VDPAU_TRACE
Failed to open VDPAU backend %s
/usr/lib64/vdpau/libvdpau_trace.so.1
Failed to open VDPAU trace library %s
libvdpau.so.1.0.0-1.3-1.fc31.x86_64.debug

You can see where the path to the trace library was made relative, without changing its length:

# It presumably started out as
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1
# But was replaced to
./././././././././././lib/vdpau/libvdpau_trace.so.1
# which you can actually do with sed. ...As long as you're careful to have the same number of
# characters on both sides of the replacement, so you don't throw your addresses off and
# corrupt the library:

sed -i -e 's|/usr/lib/x86_64-linux-gnu/vdpau|./././././././././././lib/vdpau|' libvdpau.so.1

# Same thing for the driver path, which presumably started out in /usr/lib/...:
sed -i -e 's|/usr/lib/vdpau|././/lib/vdpau|' libvdpau.so.1

Those are valid paths, since the app is running from the usr/ directory inside the AppImage... but the weird thing is, they don't _exist_:

$ ls -l /proc/`pidof avidemux3_portable`/cwd                                               
lrwxrwxrwx. 1 ferd ferd 0 Mar 10 10:03 /proc/1569526/cwd -> /tmp/.mount_PeR4ln/usr

$ ls -1d /tmp/.mount_PeR4ln/usr/lib/*(/)
/tmp/.mount_PeR4ln/usr/lib/ADM_plugins6/
/tmp/.mount_PeR4ln/usr/lib/pulseaudio/
/tmp/.mount_PeR4ln/usr/lib/qt5/

So, not sure what to make of that. Maybe they represent some abortive previous attempt to bundle the vdpau drivers into the AppImage.

(Which would never work, as the VDPAU drivers have to exactly match the firmware revision running on the GPU. Try to load any libvdpau_nvidia.so version _other_ than 440.64 on my currently-running system, and if you're _lucky_ it'll merely crash the application. Good chance it could take down the entire display server, and possibly knock the card off the PCIe bus completely. They're tetchy that way.)

libva.so redux

...Since nothing is linked with libva (except the useless-to-me-if-not-in-general Intel driver), nothing seems to be loading any version of it on my system.

Missing hardware encoding options

...Ah, OK. The differences in the bundled plugin list, compared to my native install, explain the missing hardware encoding modes:

$ ls -1 /tmp/.mount_XWR5E4/usr/lib/ADM_plugins6/videoEncoders > /tmp/a
$ ls -1 /lib64/ADM_plugins6/videoEncoders > /tmp/b
$ diff -W70 -y /tmp/{a,b}
libADM_ve_ffDv.so           libADM_ve_ffDv.so
libADM_ve_ffFlv1.so         libADM_ve_ffFlv1.so
libADM_ve_ffMpeg2.so            libADM_ve_ffMpeg2.so
libADM_ve_ffMpeg4.so            libADM_ve_ffMpeg4.so
                  > libADM_ve_ffNvencHEVC.so
                  > libADM_ve_ffNvenc.so
                  > libADM_ve_ffVaEncH264.so
                  > libADM_ve_ffVaEncHEVC.so
libADM_ve_huff.so           libADM_ve_huff.so
libADM_ve_jpeg.so           libADM_ve_jpeg.so
                  > libADM_ve_libva.so
libADM_ve_null.so           libADM_ve_null.so
libADM_ve_x264_other.so         libADM_ve_x264_other.so
libADM_ve_x265_other.so         libADM_ve_x265_other.so
libADM_ve_xvid4.so          libADM_ve_xvid4.so
libADM_ve_yv12.so           libADM_ve_yv12.so
qt5                 qt5

To make a long story _endless_...

So, after all that, the results are pretty much as I feared: Though they found a way to make decoding-only VDPAU acceleration support work, in their AppImage builds, that's the extent of the limited support available — and it's of no use to us. Every other library that would attempt to access the hardware drivers on the system has been disabled or removed entirely. Which I'm even more concerned will ultimately prove to be the only realistic option for us, as well.

ferdnyc on 10 Mar 2020

👀1

The simplest solution, as for me, is to have "safe" startup that do not performs the check for HW encoders/decoders and add new button in _Preferences_ that will do this on request. Also, OpenShot needs to fall back to "safe" settings if any attempt to use such decoders/encoders fails, like: load setting, save SW setting, apply previously loaded setting, save HW or SW setting depending on result of the apply. Thus, user will be aware that application crashed when some HW acceleration support was tested. And the program will start next time safe.

Yeah, I'm pretty of on board with that as well. The auto-detection is a nice idea, _if_ we could confidently say that it's rock-solid and doesn't cause users any problems. But we're a long, long way from that, and realistically it's not a state we can plan on reaching in any sort of predictable timeframe.

Plus... even when it _doesn't_ cause any crash/stability issues, the auto-detection every. time. Preferences is opened is intrusive. Once OpenShot has compiled a profile of the system's video hardware capabilities, there's no reason for it to do any further detection. Not for the remainder of the current session, at least. Sure, at launch something might have changed from the last time it scanned, but there's no OS I know of where you can install or update video hardware drivers without restarting at least the desktop session, so there's little reason to expect any changes on that front _while_ OpenShot is running.

(OK, I suppose that's not technically accurate. As long as the _drivers_ themselves were previously installed, I suppose it's theoretically possible to add something like a VA-API or VDPAU library to a running system, which might then present new hardware interfaces that were previously unavailable. But I'm _more_ than comfortable with an "OpenShot won't notice new hardware APIs until the next time you launch it" situation... much more so than with it obsessively re-probing hardware capabilities just in case something _might_ happen to change.)

Or even simply because it doesn't preserve the results of the _previous_ probe, forcing it to compile the same information over and over again every time it's needed. Which I think is actually much more of a factor in how it currently works.

...Whew, kind of went off on a tangent there. Anyway, yes: OpenShot should be very, _very_ conservative about taking any action that may lead to an application crash, and certainly shouldn't be taking those actions automatically and without the user's knowledge. Preferably such things would be done only at the user's request, or at _least_ only after first notifying them and asking their permission to proceed.

ferdnyc on 11 Mar 2020

Preferably such things would be done only at the user's request, or at _least_ only after first notifying them and asking their permission to proceed.

(And if we go down that road, there of course needs to be a "Shut up and don't bug me about this again." option to make it _stop_ asking for permission.)

ferdnyc on 11 Mar 2020

What to add that every Windows crash (I have linked few above) is because of old Intel's drivers installed (pre DCH era). For some hardware/software combinations new drivers not available or update not possible (old system). By changing or completely disabling powerful video adapter (only Intel's is left or it becomes first device) users may solve the crash.

Edit: The simplest solution was to skip the Intel's check in OpenShot itself: https://github.com/OpenShot/openshot-qt/issues/3276#issuecomment-595052453

SuslikV on 11 Mar 2020

👍1

All,

Linked below, hot off the Gitlab Linux builder presses, is an AppImage built from my PR branch for #3321, which I've proposed to address the issue of hardware-acceleration support in the AppImage builds (by completely disabling it). I've verified that it contains libva.so.1 and libvdpau.so.1 libraries with their hardcoded driver paths modified to no longer access /usr/lib/x86_64-linux-gnu/{dri,vdpau} (respectively), and that the change has no effect on my Fedora 31 system (where the drivers are located in /usr/lib64/{dri,vdpau}, so it was never able to access them in the first place).

If @DylanC and any users on systems affected by this issue (which is expected to be just about every Debian-based system that uses /usr/lib/x86_64-linux-gnu/ paths for 64-bit shared libraries) could download and test it, and report back whether it successfully resolves the issue, that'd be a big help.

For the purposes of this issue, "resolved" is defined as:

OpenShot no longer crashes when you attempt to open the Preferences dialog
OpenShot otherwise functions normally
There is NO hardware-accelerated video decoding available when running from the AppImage
Hardware-accelerated encoding is limited to whatever accelerated encoders show up in the "Target:" list of the Export dialog (e.g. "MP4 (h.264 nv)", "MP4 (h.264 va)", "MP4 (h.264 qsv)", etc.) — some or all of which may not be functional, some or all of which may even crash OpenShot if selected, but none of which prevent export from being successfully completed when one of the _non_-accelerated encoders (tagged with a "CPU" icon) is selected instead.

https://drive.google.com/file/d/1ePubFGNxHKdKwEAf2a7JEGJFKCgnQALg/view?usp=sharing

ferdnyc on 28 Mar 2020

👍1

@ferdnyc - This is working on my system. PopOS (Based on Ubuntu 19.10)

DylanC on 28 Mar 2020

🎉1

I have the same problem on a Sky Lake i5-6500 (Intel 530 graphics, no discrete). Preference Dialog cause crash, and there's no HW acceleration available when exporting. But when testing using Windows 10 on the very same machine it all works fine, both opening the Preferences Dialog as well as exporting with HW encoding.

efredjo on 23 Jul 2020

Openshot-qt: Crash when launching Preferences

All 29 comments

Libva / VA-API (Video Acceleration API)

Bundled drivers!?

Bundled (but unused) libva.so.1

Bundled (but also native) libvdpau.so.1

VDPAU driver discovery

libva.so redux

Missing hardware encoding options

To make a long story _endless_...

Related issues