Crash when launching Preferences

[DylanC]

Describe the bug: Openshot crashed when I tried to launch the Preferences.

Steps to reproduce the behavior:

1. Launch AppImage via terminal window.
2. Click on Preferences
3. See error in the terminal

Expected behavior: No crash when launching Preferences.

System Details:

• OpenShot Version v.2.5.0 Pre-Release
• Operating System / Distro: PopOS/Ubuntu 19.10

Exception / Stacktrace:

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 @ 0x21b35c0] Failed to initialise VAAPI connection: -1 (unknown libva error).

Screenshots: (Optional)

[ferdnyc]

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]

(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.

[DylanC]

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

[ferdnyc]

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]

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...)

[DylanC]

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)

[ferdnyc]

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.

[DylanC]

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)

[ferdnyc]

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]

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]

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]

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]

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.)

[DylanC]

@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.

[jonoomph]

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.

[SuslikV]

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.

[DylanC]

@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! 👍

[SuslikV]

...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]

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.

[ferdnyc]

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.

1. 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.)

2. 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]

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.

[DylanC]

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

[ferdnyc]

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]

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]

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.)

[SuslikV]

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

[ferdnyc]

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:

1. OpenShot no longer crashes when you attempt to open the Preferences dialog
2. OpenShot otherwise functions normally
3. There is NO hardware-accelerated video decoding available when running from the AppImage
4. 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

[DylanC]

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

[efredjo]

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.