CI: Create AppImage #1565

probonopd · 2018-12-02T20:51:43Z

This PR, when merged, will compile this application on Travis CI upon each git push, and upload an AppImage.

Providing an AppImage would have, among others, these advantages:

Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
One app = one file = super simple for users: just download one AppImage file, make it executable, and run
No unpacking or installation necessary
No root needed
No system libraries changed
Works out of the box, no installation of runtimes needed
Optional desktop integration with appimaged
Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
Can optionally GPG2-sign your AppImages (inside the file)
Works on Live ISOs
Can use the same AppImages when dual-booting multiple distributions
Can be listed in the AppImageHub central directory of available AppImages
Can double as a self-extracting compressed archive with the --appimage-extract parameter
No repositories needed. Suitable/optimized for air-gapped (offline) machines

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

probonopd · 2018-12-02T20:53:07Z

The resulting AppImage does not run properly yet, e.g., on Clear Linux OS:

user@host ~/Downloads $ ./OBS-git.ea50599-x86_64.AppImage 
Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: /usr/share/obs/obs-studio/locale/en-US.ini
error: Failed to load locale
info: == Profiler Results =============================
info: run_program_init: 3172.4 ms
info:  ┗OBSApp::AppInit: 2019.77 ms
info:    ┗OBSApp::InitLocale: 2016.82 ms
info: =================================================
info: == Profiler Time Between Calls ==================
info: =================================================
info: Number of memory leaks: 1

It seems like it is trying to load its resources from share/obs/obs-studio/locale/en-US.ini relative to the user's current working directory, rather than from a location relative to the main executable itself. This is something that needs most likely to be fixed in the application's source code, and I am asking for help from one of the OBS Studio developers to do it.

You could use QString QCoreApplication::applicationFilePath() instead and construct a relative path.

kkartaltepe · 2018-12-02T20:56:13Z

While always interesting, there have been numerous issues from the people who already attempted and distributed other containerized formats, with less issues then this current PR has.

These containerized formats are designed to limit permissions of the containerized application. However due to the nature of OBS it often needs high privileged access, thus running into all the walls that containers are designed to put up.

probonopd · 2018-12-02T20:56:50Z

Which is why AppImage is a great match, as (unlike other solutions) it does not run in a sandbox or otherwise restrict the application. Inside an AppImage you can do what you want, as an AppImage is just a self-mounting filesystem image (think .app in a .dmg on the Mac).

kkartaltepe · 2018-12-02T20:58:03Z

No root needed

Suggests it is running in a pid namespace. Which does restrict access.

probonopd · 2018-12-02T20:59:11Z

Well, it means that unlike deb or rpm, which need root rights to get the application installed, the AppImage format does not need this (since there is no installation step). It does not mean that you can't run an AppImage with root rights, if you so desire/need.

ElectronicWar · 2018-12-02T21:00:02Z

OBS issues are tracked on Mantis: https://obsproject.com/mantis/
Developers can be reached directly on the OBS discord, found at https://discord.gg/obsproject

kkartaltepe · 2018-12-02T21:00:19Z

I see, can you also explain the qt repository you are adding? And the rest of the workarounds in the new script?

probonopd · 2018-12-02T21:08:33Z

can you also explain the qt repository you are adding?

The Qt that comes with Ubuntu 14.04 has a bug in that it tries to load the platform plugins from the wrong location (relative to the user's current working directory, rather than from a location relative to the Qt being used). This has been resolved in more recent versions of Qt. The beineri ppa is a very reliable source for recent Qt versions compiled on older Ubuntu releases, and has been around for years.

And the rest of the workarounds in the new script?

Let me go through it:

# Make sure the Qt from the beineri repository (see above) is used
export LD_LIBRARY_PATH=/opt/qt59/lib/x86_64-linux-gnu:/opt/qt59/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/opt/qt59/lib/pkgconfig:$PKG_CONFIG_PATH
export PATH=/opt/qt59/bin:$PATH

# Build the application
cd ./build
make -j$(nproc)

# Install the application into a directory called "appdir" which is going to become an AppDir
# http://rox.sourceforge.net/desktop/AppDirs.html
make DESTDIR=appdir -j$(nproc) install ; find appdir/

# Make sure the contents of the AppDir do not depend on anything outside of the AppDir
# that cannot be resolved
find appdir -executable -type f -exec ldd {} \; | grep " => /usr" | cut -d " " -f 2-3 | sort | uniq

# Get linuxdeployqt, a tool which will finalize the AppDir and convert it to AppImage
wget -c -nv "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage"

# Since linuxdeployqt is an AppImage itself, we need to make it executable
chmod a+x linuxdeployqt-continuous-x86_64.AppImage

# Make sure nothing is interfering with the correct operation of linuxdeployqt
unset QTDIR; unset QT_PLUGIN_PATH ; unset LD_LIBRARY_PATH

export VERSION=$(git rev-parse --short HEAD) # linuxdeployqt uses this for naming the file

# Use linuxdeployqt to bundle ("deploy") dependencies into the AppDir
./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -bundle-non-qt-libs

# We need to patch the RPATH of one library using patchelf, and since patchelf is contained inside
# linuxdeployqt-continuous-x86_64.AppImage, we extract that to be able to use it from there
./linuxdeployqt-continuous-x86_64.AppImage --appimage-extract ; export PATH=./squashfs-root/usr/bin:$PATH # Get patchelf

# Patch the RPATH of one library using patchelf (for the other libraries, linuxdeployqt does this automatically)
patchelf --set-rpath '$ORIGIN' appdir/usr/lib/libobs-opengl.so.0 # This is loaded by obs with dlopen(), so linuxdeployqt can't know about it

# Finally, convert the AppDir into a self-mounting AppImage
./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -appimage

# Upload the AppImage
# TODO: The next line should be replaced by a native upload mechanism defined in .travis.yml,
# e.g., using https://github.com/probonopd/uploadtool
curl --upload-file OBS*.AppImage https://transfer.sh/OBS-git.$(git rev-parse --short HEAD)-x86_64.AppImage

probonopd · 2018-12-02T21:44:25Z

On Discord, https://github.com/obsproject/obs-studio/wiki/Install-Instructions#linux-portable-mode-all-distros was pointed out. To be investigated.

But note that it says

Change to bin/64bit or bin/32bit and then simply run: ./obs

Which implies that it, too, will load stuff relative from the current working directory (cwd).

probonopd · 2018-12-02T21:59:20Z

If I extract the AppImage, cd to usr/ inside the AppDir, then I do not get this error.

But another one:

user@host ~/Downloads $ ./OBS-git.ea50599-x86_64.AppImage --appimage-extract

user@host ~/Downloads $ cd squashfs-root/usr/

user@host ~/Downloads/squashfs-root/usr $ ../AppRun 

Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: share/obs/obs-studio/locale.ini
Attempted path: share/obs/obs-studio/themes/Dark.qss
info: CPU Name: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz
info: CPU Speed: 1971.744MHz
info: Physical Cores: 2, Logical Cores: 4
info: Physical Memory: 3816MB Total, 666MB Free
info: Kernel Version: Linux 4.19.5-665.native
info: Distribution: "Clear Linux OS" 26600
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.20.3
info: Portable mode: false
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_destroyed()
QMetaObject::connectSlotsByName: No matching signal for on_program_customContextMenuRequested(QPoint)
info: OBS ea50599 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
	samples per sec: 44100
	speakers:        2
info: ---------------------------------
info: Initializing OpenGL...
info: Loading up OpenGL on adapter Intel Open Source Technology Center Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
info: OpenGL loaded successfully, version 4.5 (Core Profile) Mesa 19.0.0-devel, shading language 4.50
info: ---------------------------------
info: video settings reset:
	base resolution:   1920x1080
	output resolution: 1280x720
	downscale filter:  Bicubic
	fps:               30/1
	format:            NV12
	YUV mode:          601/Partial
info: Audio monitoring device:
	name: Default
	id: default
info: ---------------------------------
info: ---------------------------------
info:   Loaded Modules:
info: ---------------------------------
info: ==== Startup complete ===============================================
error: Encoder ID 'obs_x264' not found
error: Failed to get properties for encoder '' (ffmpeg_aac)
error: Could not enumerate any AAC encoder bitrates
error: Failed to create aac streaming encoder (simple output)
info: Freeing OBS context data
(...)

probonopd · 2018-12-02T22:06:18Z

As was pointed out on Discord, info: Loaded Modules: should not be empty. It is not loading its modules.

And indeed it is looking in "strange" places:

user@host ~/Downloads/squashfs-root/usr $ strace -f ../AppRun 2>&1 | grep obs-plugins
[pid 14895] openat(AT_FDCWD, "../../obs-plugins/64bit", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY <unfinished ...>
[pid 14895] openat(AT_FDCWD, "/usr//lib/obs-plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY <unfinished ...>

As was pointed out on Discord, the relative path is meant for -DUNIX_STRUCTURE=0

probonopd · 2018-12-02T22:17:40Z

So, I guess that using -DUNIX_STRUCTURE=0 and doing a chdir() before executing the obs binary will get it working.

But is it the cleanest way to go?

probonopd · 2018-12-02T22:22:13Z

As a workaround,

user@host ~/Downloads/squashfs-root/usr $  sed -i -e 's|../../obs-plugins/64bit|././././lib/obs-plugins|g' ./lib/libobs.so.0

user@host ~/Downloads/squashfs-root/usr $  ../AppRun 
Attempted path: share/obs/obs-studio/locale/en-US.ini
Attempted path: share/obs/obs-studio/locale.ini
Attempted path: share/obs/obs-studio/themes/Dark.qss
info: CPU Name: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz
info: CPU Speed: 1972.376MHz
info: Physical Cores: 2, Logical Cores: 4
info: Physical Memory: 3816MB Total, 274MB Free
info: Kernel Version: Linux 4.19.5-665.native
info: Distribution: "Clear Linux OS" 26600
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.20.3
info: Portable mode: false
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_advAudioProps_destroyed()
QMetaObject::connectSlotsByName: No matching signal for on_program_customContextMenuRequested(QPoint)
info: OBS ea50599 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
	samples per sec: 44100
	speakers:        2
info: ---------------------------------
info: Initializing OpenGL...
info: Loading up OpenGL on adapter Intel Open Source Technology Center Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
info: OpenGL loaded successfully, version 4.5 (Core Profile) Mesa 19.0.0-devel, shading language 4.50
info: ---------------------------------
info: video settings reset:
	base resolution:   1920x1080
	output resolution: 1280x720
	downscale filter:  Bicubic
	fps:               30/1
	format:            NV12
	YUV mode:          601/Partial
info: Audio monitoring device:
	name: Default
	id: default
info: ---------------------------------
error: os_dlopen(././././lib/obs-plugins/frontend-tools.so->././././lib/obs-plugins/frontend-tools.so): libobs-scripting.so: cannot open shared object file: No such file or directory

warning: Module '././././lib/obs-plugins/frontend-tools.so' not loaded
libDeckLinkAPI.so: cannot open shared object file: No such file or directory
info: No blackmagic support
error: os_dlopen(././././lib/obs-plugins/linux-jack.so->././././lib/obs-plugins/linux-jack.so): libjack.so.0: cannot open shared object file: No such file or directory

warning: Module '././././lib/obs-plugins/linux-jack.so' not loaded
error: os_dlopen(././././lib/obs-plugins/obs-ffmpeg.so->././././lib/obs-plugins/obs-ffmpeg.so): libavdevice.so.57: cannot open shared object file: No such file or directory

warning: Module '././././lib/obs-plugins/obs-ffmpeg.so' not loaded
error: os_dlopen(././././lib/obs-plugins/obs-libfdk.so->././././lib/obs-plugins/obs-libfdk.so): libfdk-aac.so.0: cannot open shared object file: No such file or directory

warning: Module '././././lib/obs-plugins/obs-libfdk.so' not loaded
error: os_dlopen(libvlc.so.5->libvlc.so.5): libvlc.so.5: cannot open shared object file: No such file or directory

info: Couldn't find VLC installation, VLC video source disabled
info: ---------------------------------
info:   Loaded Modules:
info:     vlc-video.so
info:     text-freetype2.so
info:     rtmp-services.so
info:     obs-x264.so
info:     obs-transitions.so
info:     obs-outputs.so
info:     obs-filters.so
info:     linux-v4l2.so
info:     linux-pulseaudio.so
info:     linux-decklink.so
info:     linux-capture.so
info:     linux-alsa.so
info:     image-source.so
info: ---------------------------------
info: ==== Startup complete ===============================================
error: Failed to get properties for encoder '' (ffmpeg_aac)
error: Could not enumerate any AAC encoder bitrates
error: Failed to create aac streaming encoder (simple output)
info: Freeing OBS context data
(...)

Seems like we are getting somewhere. Also seems like OBS Studio is making extensive use of dlopen() on the libraries in the obs-plugins directory which means that linuxdeployqt could not work its magic and we still have unbundled dependencies that need to be bundled.

At least we are getting somewhere.

probonopd · 2018-12-02T23:29:28Z

...and working 👍

This is the OBS Studio AppImage running on Clear Linux OS:

Thanks to the friendly developers on Discord who helped me make this happen.

kkartaltepe · 2018-12-02T23:47:44Z

thanks for the work on getting it working, now we will need to test on some other common distributions as the documentation suggests and find someone to maintain the appimage.

probonopd · 2018-12-02T23:53:36Z

This is the same AppImage on Ubuntu 18.04:

probonopd · 2018-12-02T23:59:41Z

This is the same AppImage on elementary OS 5.0 Juno:

probonopd · 2018-12-03T00:05:09Z

This is the same AppImage on openSUSE Tumbleweed:

probonopd · 2018-12-03T00:11:02Z

This is the same AppImage on Xubuntu 16.04:

probonopd · 2018-12-03T00:18:37Z

This is the same AppImage on Manjaro:

probonopd · 2018-12-03T00:34:23Z

This is the same AppImage on Netrunner 17.03:

probonopd · 2018-12-03T00:39:50Z

This is the same AppImage on Pop! OS 17.10:

probonopd · 2018-12-03T00:55:44Z

This is the same AppImage on Deepin Linux 15.5:

probonopd · 2018-12-03T01:02:10Z

This is the same AppImage on Maui Linux 2.1:

probonopd · 2018-12-03T01:06:39Z

This is the same AppImage on Linux Mint 18.1:

probonopd · 2018-12-03T01:14:53Z

When trying a screen capture:

info: ==== Recording Start ===============================================
info: [ffmpeg muxer: 'simple_file_output'] Writing file '/home/me/2018-12-03 02-09-50.flv'...
share/obs/obs-plugins/obs-ffmpeg/ffmpeg-mux: error while loading shared libraries: libavcodec.so.57: cannot open shared object file: No such file or directory
warning: [ffmpeg muxer: 'simple_file_output'] os_process_pipe_write for packet data failed

Argh, there seem architecture-dependent binaries to be hiding in usr/share/obs/obs-plugins/... not sure whether this is even FHS compliant.

me@host ~ $ ldd /tmp/.mount_OBS-gi7o01ja/usr/share/obs/obs-plugins/obs-ffmpeg/ffmpeg-mux
	linux-vdso.so.1 =>  (0x00007fff4afd7000)
	libavcodec.so.57 => not found
	libavutil.so.55 => not found
	libavformat.so.57 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc5a8a8c000)
	/lib64/ld-linux-x86-64.so.2 (0x000055d172d27000)

In any case, such errors seem to be pretty distribution-independent.

probonopd · 2018-12-03T01:50:58Z

Sure enough, recording works now. 👍

If you want to give it a try:
https://transfer.sh/Hh3PL/OBS-git.fc36b1c-x86_64.AppImage (link available for 14 days)

juvester · 2018-12-03T02:47:53Z

Nice!

I tested it on Ubuntu MATE 18.04 and one thing I noticed is that the Tools menu is missing these entries: Automatic Scene Switcher, Output Timer, Scripts. These are normally available in the .deb version from OBS PPA.

I believe it has something to do with frontend-tools.so not being loaded:

info: ---------------------------------
error: os_dlopen(././././lib/obs-plugins/frontend-tools.so->././././lib/obs-plugins/frontend-tools.so): libobs-scripting.so: cannot open shared object file: No such file or directory

warning: Module '././././lib/obs-plugins/frontend-tools.so' not loaded
libDeckLinkAPI.so: cannot open shared object file: No such file or directory
info: No blackmagic support
error: os_dlopen(libnvidia-encode.so.1->libnvidia-encode.so.1): libnvidia-encode.so.1: cannot open shared object file: No such file or directory

Other than that all the basic stuff seemed to be working fine: Recording, Screen Capture, Window Capture, VLC Video Source, webcam, mic, etc.

SuslikV · 2018-12-03T10:56:33Z

There is very limited number of cases where need to use OBS on linux.

Because of the wrapper any new build cannot be considered as test-build.

jp9000 · 2018-12-20T03:29:21Z

I wouldn't suggest including bazuka's version of the browser source at this point in time. I'd prefer to get our version working at some point -- it should be doable.

pkviet · 2018-12-20T09:28:04Z

Jim, that's what I meant; Bazukas suggested earlier to probono to include your browser version (can't find where it was)
edit: oh sorry for the confusion; bazukas did link to his obs-browser not yours. So strike my suggestion

pkviet · 2018-12-20T09:52:38Z

probono: check this discussion obsproject/obs-browser#141
Jim's obs-browser requires two linux fixes to work which are discussed there.

probonopd · 2018-12-20T10:07:23Z

I was able to run obs-linuxbrowser with no issues at all when using the OBS Studio AppImage, like this:

mkdir -p "$HOME/.config/obs-studio/plugins"
tar xf linuxbrowser0.5.2-obs21.1.2-64bit.tgz obs-linuxbrowser/
mv ./obs-linuxbrowser "$HOME/.config/obs-studio/plugins/"
./OBS-git.6dba6e7-x86_64.AppImage

Once obs-browser runs on Linux, I think we will be able to do the same, or bundle it in the AppImage.

probonopd · 2018-12-22T14:33:49Z

Endless OS

Illutorium · 2018-12-25T14:09:44Z

So why aren't be included "VAAPI" hardware Encode?
Then if OBS can be rend hardware on to Windows {Intel Quick Video Sync|Marketing in Technically} so Why on VAAPI can't be encode for OBS?
Info: Lubuntu 18.10 (amd64)|ACEPC T5 (HDMI Stick)|OBS from Newest git of AppImage

kkartaltepe · 2018-12-26T16:45:38Z

On my 18.04 Ubuntu system the latest app image linked on this issue provides the ffmpeg VAAPI option. (the test used to check for VAAPI support is here
https://github.com/obsproject/obs-studio/blob/master/plugins/obs-ffmpeg/obs-ffmpeg.c#L175

However on my system actually initializing the VAAPI codec fails.

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

This is on intel hardware, and the device initilizes fine when run from 22.0.3 normally.

probonopd · 2018-12-26T23:54:43Z

Seems to be a known issue: intel/media-driver#235 (comment). My OBS Studio build is compiled against i965_drv_video.so that ships with Ubuntu 14.04, because this is currently the oldest still-supported distribution release. Unfortunately Intel seems to have broken backward binary compatibility since, which means that applications compiled against the old version of the Intel library will no longer run on newer systems that ship a newer version of the Intel library.

I don't know what is the best cause of action here. Can we disable it altogether? Libraries that break backward compatibility are not something I am keen on supporting.

probonopd · 2018-12-27T00:07:33Z

Funny fact is, nothing in the AppImage seems to be hardcoding __vaDriverInit_0_32. I can't find the string in the whole AppImage. Also, nothing hardcodes i965_drv_video. So something must be loading this stuff, but I don't know what...

What happens if, on the system that shows the problem, you run

./OBS-git.6dba6e7-x86_64.AppImage --appimage-extract
find squashfs-root/ -name '*libva*' -type f -delete
./squashfs-root/AppRun

On my Xubuntu 18.04 system, I get

./bin/obs: error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory

but maybe a system with a complete Intel driver setup does have this locally. Maybe we need to not load this if a local version is present?

kkartaltepe · 2018-12-27T05:07:37Z

This is implemented entirely in ffmpeg, so its not related to anything obs is compiled against. strictly the version of ffmpeg used.

Can we disable it altogether?

You could compile without VAAPI, but to do so would make the AppImage unpalatable to most users considering how popular hardware encoders are for streamers.

probonopd · 2018-12-27T12:53:02Z

Let's decide how to best proceed once we have collected some feedback on #1565 (comment) from Intel users. I'd assume that people who know how to use hardware encoders might have the library installed locally, so that we should give preference to the local one if it exists. We sill need to ship something (a shim?) in the AppImage for those systems on which the Intel libraries are not installed, otherwise the application will not even launch.

kkartaltepe · 2018-12-27T15:54:50Z

What you are seeing when it doesnt start is the failure of ffmpeg to find its required libva dependency (because you compiled against an ffmpeg with libva). OBS itself has no direct dependency on libva and works perfectly without it. You can check yourself that obs executable has no direct dependency with objdump the libva requirement comes from libavcodec.

You dont see those symbols in any files because they are stored directly in the drivers. The drivers dynamically load the required symbols in some hellish mess. At least if amd drivers are anything to go by.

--edit--
The real dependency on libva is in the ffmpeg plugin, which is dynamically loaded by obs as all plugins are (which is separate from the ffmpeg depency for the OBS ui).

probonopd · 2018-12-27T16:20:52Z

The drivers dynamically load the required symbols in some hellish mess.

Looks like it ;-)

So ideally we would not bundle anything that has to do with the Intel drivers and let the system figure that part out. However, if I delete libva.so.1 from the AppImage then I get the error shown above. Hence my idea to make some shim library that satisfies the linker if the library is not on the system. So that OBS will at least launch.

kkartaltepe · 2018-12-27T16:38:54Z

Well if you delete the library from the appimage then the linkages are still screwed by the packaging process. So im not sure what was expected from just deleting it. Can you exclude it like libgl?

probonopd · 2019-01-06T15:43:04Z

Can you exclude it like libgl?

Then the application will not even launch on systems that don't have this library, e.g., on systems that don't even have any Intel GPU.

kkartaltepe · 2019-01-07T06:02:36Z

I think you are confused about what libva is. It is the library implementing the VA-API, which is platform agnostic. (libva the library is mostly maintained by intel, however it is the reference used by all other vendors).

This issue may also affect AMD and Nvidia (or other implementers of the VA-API interface) if they take the same tact and perhaps only support certain versions.

-- edit --
Perhaps then leaving it broken is the best option, though it makes it unappealing to me not having support for hardware encoding on potentially any platform. Though libva will be installed on basically every single linux system where users are watching or recording hardware accelerated video (except certain nvidia users).

-- edit 2 --
Personally I dont really feel to badly about requiring users to have libva installed on their system, just like we require them to have graphics drivers.

probonopd · 2019-01-07T18:25:54Z

While I may not be the typical user of OBS Studio, I am using it e.g., to record screencasts using a large collection of different Linux Live ISOs, some of which may or may not have libva preinstalled. It would be nice if OBS Studio at least continued to run everywhere, regardless of whether it is fully accelerated or not. Of course it would be best if we could make it use the acceleration on systems on which it is available while still continuing to work on systems where it is not.

kkartaltepe · 2019-01-08T04:05:04Z

Well, you may have qualms about libva. But it ships on the debian live CD. I leave it up to you to see what of your many distros include it by default even on a live CD.

This library going to be on almost any laptop or other low power device as without it you cannot watch hardware accelerated video on AMD or Intel hardware, and most nvidia hardware uses it as well. Requiring users of the appimage to have it on their system would help them if only because it finally allows their video players to use the hardware decoders they likely were not using before (including those provided by the Media Source and VLC Source which depend on libva).

But i dont feel the need to impress this any further its not my decision to make what needs to be supported if contributors want to take on owning the appimage.

probonopd · 2019-01-08T20:14:41Z

Note to self, need to

see what of your many distros include it by default even on a live CD.

Everyone's experience appreciated.

jp9000 · 2019-04-29T14:46:27Z

This doesn't work with xenial, breaks our CI, and has conflicts. if someone wants to attempt to fix this, then I'm giving it a few more weeks. if no one's interested by then, I'm closing it, and if someone really wants it they can resubmit it. I don't know what to do with it otherwise.

jp9000 · 2019-04-29T14:49:35Z

You know what, I'm just going to close this. If someone wants to take a crack at getting this working, resolving the conflicts, and making it so it doesn't break our CI, then please by all means resubmit. I really don't want this sitting on the PR list unresolved with no activity any longer.

probonopd · 2019-04-29T17:05:57Z

@jp9000

This doesn't work with xenial

What do you mean by this? Binaries built on xenial should run on later distributions, and this AppImage certainly does (I had tested it above, see the screenshots of the AppImage running on various distributions). Do you think the AppImage does not work on xenial?

breaks our CI

Forgive me if I don't remember whether this has been detailed somewhere, but can you concisely point me to what exactly it breaks?

and has conflicts

The conflicts must have happened since I had sent the PR.

I am happy to continue putting effort on this, but only if the project is genuinely interested in having an AppImage.

Gol-D-Ace · 2019-04-29T17:08:41Z

The CI is using now Xenial.
The script needs to be adjusted to be compatible with a build server running Xenial.
Also we not only have Travis but also AppVeyor and Azure.

This should ideally work with all platforms or only affect one CI service.

probonopd · 2019-04-29T17:22:55Z

The CI is using now Xenial.

I think I can use that for making the AppImage too, but the AppImage will not be able to run on trusty anymore.

Also we not only have Travis but also AppVeyor and Azure.

These are not needed for Linux, right? AppImage is only concerned with Linux.

Gol-D-Ace · 2019-04-29T17:24:54Z

Considering that Trusty is EOL that doesn't seem too bad.
All CI services will do a Linux build and should therefore not get broken by your changes.

probonopd · 2019-04-29T17:33:17Z

All CI services will do a Linux build and should therefore not get broken by your changes.

Thanks for the explanation, I was not aware of this. Can you give me a hint as to why one would want to build for Linux on more than one CI service? Just asking out of curiosity. (For building the AppImage, Travis CI is certainly sufficient, so it would be OK to run the AppImage generation only there.)

bazukas mentioned this pull request Dec 3, 2018

Appimage obs with browser plugin bazukas/obs-linuxbrowser#92

Open

jp9000 closed this Apr 29, 2019

probonopd deleted the master branch June 16, 2019 07:24

kkartaltepe mentioned this pull request Mar 1, 2020

CI: Create nightly AppImages #2441

Closed

6 tasks

kkartaltepe mentioned this pull request Jul 14, 2021

CI: Build AppImage #2868

Closed

5 tasks

CI: Create AppImage #1565

CI: Create AppImage #1565

Conversation

probonopd commented Dec 2, 2018 • edited Loading

probonopd commented Dec 2, 2018 • edited Loading

kkartaltepe commented Dec 2, 2018

probonopd commented Dec 2, 2018 • edited Loading

kkartaltepe commented Dec 2, 2018

probonopd commented Dec 2, 2018 • edited Loading

ElectronicWar commented Dec 2, 2018

kkartaltepe commented Dec 2, 2018

probonopd commented Dec 2, 2018

probonopd commented Dec 2, 2018 • edited Loading

probonopd commented Dec 2, 2018 • edited Loading

probonopd commented Dec 2, 2018 • edited Loading

probonopd commented Dec 2, 2018

probonopd commented Dec 2, 2018 • edited Loading

probonopd commented Dec 2, 2018 • edited Loading

kkartaltepe commented Dec 2, 2018

probonopd commented Dec 2, 2018

probonopd commented Dec 2, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018

probonopd commented Dec 3, 2018 • edited Loading

probonopd commented Dec 3, 2018 • edited Loading

juvester commented Dec 3, 2018

SuslikV commented Dec 3, 2018

jp9000 commented Dec 20, 2018

pkviet commented Dec 20, 2018 • edited Loading

pkviet commented Dec 20, 2018

probonopd commented Dec 20, 2018 • edited Loading

probonopd commented Dec 22, 2018

Illutorium commented Dec 25, 2018 • edited Loading

kkartaltepe commented Dec 26, 2018

probonopd commented Dec 26, 2018 • edited Loading

probonopd commented Dec 27, 2018 • edited Loading

kkartaltepe commented Dec 27, 2018 • edited Loading

probonopd commented Dec 27, 2018

kkartaltepe commented Dec 27, 2018 • edited Loading

probonopd commented Dec 27, 2018

kkartaltepe commented Dec 27, 2018

probonopd commented Jan 6, 2019

kkartaltepe commented Jan 7, 2019 • edited Loading

probonopd commented Jan 7, 2019

kkartaltepe commented Jan 8, 2019 • edited Loading

probonopd commented Jan 8, 2019

jp9000 commented Apr 29, 2019

jp9000 commented Apr 29, 2019

probonopd commented Apr 29, 2019 • edited Loading

Gol-D-Ace commented Apr 29, 2019

probonopd commented Apr 29, 2019 • edited Loading

Gol-D-Ace commented Apr 29, 2019

probonopd commented Apr 29, 2019

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 2, 2018 •

edited

Loading

probonopd commented Dec 3, 2018 •

edited

Loading

probonopd commented Dec 3, 2018 •

edited

Loading

pkviet commented Dec 20, 2018 •

edited

Loading

probonopd commented Dec 20, 2018 •

edited

Loading

Illutorium commented Dec 25, 2018 •

edited

Loading

probonopd commented Dec 26, 2018 •

edited

Loading

probonopd commented Dec 27, 2018 •

edited

Loading

kkartaltepe commented Dec 27, 2018 •

edited

Loading

kkartaltepe commented Dec 27, 2018 •

edited

Loading

kkartaltepe commented Jan 7, 2019 •

edited

Loading

kkartaltepe commented Jan 8, 2019 •

edited

Loading

probonopd commented Apr 29, 2019 •

edited

Loading

probonopd commented Apr 29, 2019 •

edited

Loading