CI: Build AppImage

[azubieta]

Description

Generate AppImage using appimage-builder

Motivation and Context

A revival of #1926

How Has This Been Tested?

Downloaded and ran AppImage.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.

[azubieta]

Hello folks,
the AppImage recipe is ready to be tested. Please grab it from the actions artifacts. Feel free to leave any comment

[univrsal]

I just ran the AppImage on Arch Linux (Kernel 5.6.8-zen1-1-zen) and it crashes on startup, running it with gdb gives me this

Thread 1 "obs" received signal SIGSEGV, Segmentation fault.
0x00007fffbe05e6aa in PyTuple_New () from /usr/lib/libpython3.8.so.1.0

Maybe I'm doing something wrong, I'll provide more information if necessary.

[azubieta]

@univrsal thanks for the feedback, It should not be using the system Python, I'll investigate it.

[azubieta]

@univrsal I did a quick test on a Docker archlinux image and it runs, I'll have to replicate your system to check why it's using the system libpython3.8.so.1.0. In the meantime can you give me the output of:

LD_DEBUG=libs ./obs.appimage 2>&1 | grep 'init: /usr'

[Fenrirthviti]

This PR replaces our current Linux PPA CI. Please correct this, we are not replacing our PPA deployment with appimage.

[Gol-D-Ace]

Having the same issue on Ubuntu 20.04
https://gist.github.com/Gol-D-Ace/f31944653c19bd38b924450776c16128

Note that I have the PPA version installed.

[Fenrirthviti]

Apologies not the PPA, but our normal Linux builds. These should not be replaced with the appimage, the appimage build in CI should be its own separate build.

[univrsal]

Here's the output
https://gist.github.com/univrsal/510d0c2ae796b1e97928fc3626f571f0

[Gol-D-Ace]

I removed the installed Ubuntu OBS Studio PPA package and the error stops occurring.
So this seems to be a conflict between the appimage and the PPA build.

Probably gets caused by all installs that install to the standard unix path.

[PatTheMav]

Thank you for the work, just a few things from my POV:

• Add the CI prefix to the PR title
• Squash your commits to a single one and format the commit message accordingly
• Instead of changing the existing ubuntu build job, please move the code into a separate build job inside the workflow
• Move appimage-builder.yml to CI/scripts/linux in keeping with the GitHub Actions directory structure
• Change AppImageCrafters/build-appimage-action@master to AppImageCrafters/build-appimage-action@v0.5.2 or another fixed version tag

[azubieta]

@univrsal @Gol-D-Ace I have review your logs. It seems that having another obs installed is the reason for the crash.

/usr/lib/obs-scripting/_obspython.so

Is being loaded from the system and pulling the python lib into the runtime. It seems that I need to also set a way of specifying the relative path to the obs-scripting folder.

[azubieta]

Thank you for the work, just a few things from my POV:

* Add the `CI` prefix to the PR title

* Squash your commits to a single one and format the commit message accordingly

* Instead of changing the existing ubuntu build job, please move the code into a separate build job inside the workflow

* Move `appimage-builder.yml` to `CI/scripts/linux` in keeping with the GitHub Actions directory structure

* Change `AppImageCrafters/build-appimage-action@master` to `AppImageCrafters/build-appimage-action@v0.5.2` or another fixed version tag

Done

[azubieta]

@univrsal @Gol-D-Ace would you mind to re-test using the new binaries, please?

https://github.com/obsproject/obs-studio/actions/runs/97665829

[univrsal]

Now it works, even loads my plugins from the ~/.config/obs-studio/plugins directory. Nice work!
The only issues seems to be that it doesn't load all plugins like the linux browser which can't seem to find libcef or obs-ndi which wants Qt 5.14. I assume that's because I installed them via the AUR which compiled them against Qt 5.14, so I don't think this is a real issue with the AppImage

[azubieta]

Now it works, even loads my plugins from the ~/.config/obs-studio/plugins directory. Nice work!
The only issues seems to be that it doesn't load all plugins like the linux browser which can't seem to find libcef or obs-ndi which wants Qt 5.14. I assume that's because I installed them via the AUR which compiled them against Qt 5.14, so I don't think this is a real issue with the AppImage

Binaries are a nightmare regarding compatibility, I would advise building the plugins in the same system that the AppImage was built. They can also be distributed with the libraries they need at runtime, which will require setting the RPATH property on the plugin elf to point where it's libraries are but it should not be a big deal.

[cg2121]

The only downside of AppImages so far, is that vaapi doesn't work. @azubieta would you know if this could get fixed?

[azubieta]

This seems to be the same issues we are experiencing in the AppImage package #3184

[domo5581]

looks like you are right @azubieta

[domo5581]

02:08:32 PM.395: X Error: GLXBadFBConfig, Major opcode: 152, Minor opcode: 0, Serial: 42
02:08:32 PM.395: Failed to create OpenGL context.
02:08:32 PM.395: Failed to create context!
02:08:32 PM.396: device_create (GL) failed

[azubieta]

Here is another build without libva https://github.com/AppImageCrafters/obs-studio/actions/runs/987466665
This one allows me to record using VAAPI with the following settings:

[domo5581]

Looking for testers with AMD/Nvidia Cards to test out the various hardware encoders on the appimage.

[DwarfFighterCleric]

(I'm new to all this, I'm lost) Excuse me, where can I download that Appimage mentioned above?
I can only see the build log and it says file size is 199 MB, but where can I download the file itself?
Thanks in advance.

[azubieta]

@DwarfFighterCleric check the artifacts section on the link above

https://github.com/AppImageCrafters/obs-studio/actions/runs/987466665

[kkartaltepe]

I tracked down the VAAPI issue to:

* [[BUG] FFMPEG VAAPI rate control setting w/o effect #2741](https://github.com/obsproject/obs-studio/issues/2741)

* https://bugs.launchpad.net/ubuntu/+source/obs-studio/+bug/1873400

But the resolution is not clear to me

unfortunately this is unrelated to the vaapi issue. The issue we are concerned with was identified clearly in the previous appimage PR #1565 (comment)

Perhaps enough time has passed that all the versions of vaapi are compatible in our supported platforms now? But it sounds like appimage still has no supportable plan for if this break happens again.

[DwarfFighterCleric]

@DwarfFighterCleric check the artifacts section on the link above

https://github.com/AppImageCrafters/obs-studio/actions/runs/987466665

OMG... I had to be logged in to see the text as a link... OK then
Since I'm here anyway, anyone having luck recording OBS using VP9 codec on Linux?
How about GPU-encoding for Ryzen laptop APU's? Do these work as well?

I have one strange issue on Linux: when I use FFmpeg in a terminal, I can record the screen using my GPU just fine, but I can't record any audio, I can only record audio using OBS, but then in OBS I can't use GPU. That's the current dilemma.

[DwarfFighterCleric]

OK, the AppImage works but crashes half the time (sometimes changing configs, other times crashes when recording is started or stopped, for example)
Post test results here or in the other thread?
Tested in MX Linux 19.3 (Oct2020 - Debian base) and Manjaro 20.1.2 (Oct2020)
Crashes much more frequently in Manjaro, less frequent crashes in MX (Debian)
-- Also, it seems to require much more CPU usage to record 1080p than my older version OBS Appimage built in late 2019. 30 FPS can't keep up. Renamed the /.config/obs-studio directory, started up the older version, and 1080p could record fine with 30% CPU usage less.
That older version Appimage I use is 67 MB in size and it says "OBS continuous-1-gf883ada-modified" (custom built by Probono user in OBS forums, late 2019)
-- For one positive, I noticed that this custom updated Appimages records audio with no stutters (despite using more CPU), so maybe it's more compatible with Pulseaudio. The older Appimage I used caused audio stutters at times.
-- None of the "extra" supposedly advanced codecs worked, I can only use libx264 (default)

[domo5581]

I use Manjaro and it's all smooth sailing, no crashes. Just takes a while changing some settings and such. @DwarfFighterCleric what are your specs?

[domo5581]

Could you link Probono's OBS Appimage for me to test out?

[probonopd]

Could you link Probono's OBS Appimage for me to test out?

Mine is somewhat older:
https://github.com/probonopd/obs-studio/releases/tag/continuous

I think that nowadays @azubieta has the better one!

[domo5581]

Could you link Probono's OBS Appimage for me to test out?

Mine is somewhat older:
https://github.com/probonopd/obs-studio/releases/tag/continuous

I think that nowadays @azubieta has the better one!

Your appimage seems like it record's at a lower CPU usage, resulting in better performance (for me at least). I might look into this and see what we can do to reduce cpu usage.

[Goddard]

Would be nice to see this on the main site eventually.

[Fenrirthviti]

Thank you for the efforts here, but it seems like there are too many issues that are not resolved, questionable supportability, and general lack of demand. The OBS Project team is not positioned to take on the responsibility of another package ecosystem at this time, and without commitments from the AppImage team and closer involvement in the core development of OBS to address and resolve issues that might come up, we unfortunately must decline to merge this.

[probonopd]

Am a bit surprised here. @azubieta has continuously put in lots of efforts and has essentially done all the work at https://github.com/AppImageCrafters/obs-studio 🥇.

without commitments from the AppImage team and closer involvement in the core development of OBS to address and resolve issues

Has anyone declined anything, what is missing @Fenrirthviti?

[Fenrirthviti]

#2868 (comment) has not been addressed, and has repeatedly been requested.

#2868 (comment) makes me concerned, as this is not exactly a commitment to support AppImage, but reads more "we'll be here to answer questions if we can after this is merged". Might be misunderstanding, but this is how it comes across to us.

I apologize if this comes across unnecessarily blunt, but I believe in this case just being honest is going to be the best policy here:

• There isn't anyone on the core development team, or part of our immediate community contributors who has any interest in maintaining the AppImage workflows, testing it, keeping up with new issues that might come up, supporting users who are using it, etc.
• The AppImage team has not been very involved in the project, has not addressed (and seemingly has ignored) several requests from our core team to fix this up, explain the current roadblocks, fix issues, and has sat stagnant for months now. Nobody has explicitly denied anything, but actions speak loudly here.
• We don't even have a good grasp of what the current issues are, and what is working, what isn't, etc.

#2868 (comment) This comment was basically ignored, and contains a crash condition. This alone is justification for not merging, and the lack of response on it tells me that the AppImage team doesn't seem to be interested in investigating and supporting it.

Again, just to be blunt here, it doesn't seem like the AppImage team is fully committed to integrating in to our development workflows, and I have some strong concerns about long-term supportability of this. If we merge it, we're giving it an effective official stamp of approval and accepting the support for it, which we just are not interested in doing at this time and I haven't heard anyone from the AppImage team step up and accept that responsibility in a clear, unambiguous statement.

Thank you for understanding.

[probonopd]

Thanks for the clarification @Fenrirthviti.

For the benefit of clarity, the AppImage team makes tools that application authors can use to produce AppImages. Like application authors can use a compiler to produce a binary. Like the developers of compilers, the AppImage team can't deep-dive into the inner workings of each and every application that gets built using it. But of course we are more than happy to fix any issues with the tooling that might come up. Anyhow, that's how I think about it.

[azubieta]

As @probonopd said we make tools for creating AppImages, but we cannot take responsibility of maintaining a given project. Yet, we sustain the offer of helping those willing to take care of the obs-studio AppImage packaging.

[Fenrirthviti]

This PR was originally conceived, developed, and submitted by AppImage developers, not our community. Thank you again for the efforts, but we are not interested in your tools at this time.

[probonopd]

Thank you again for the efforts, but we are not interested in your tools at this time.

Who's decision? On what basis?
Had that been stated clearly right from the beginning in 2018, @azubieta and I would have saved many, many hours of work.

This PR was originally conceived, developed, and submitted by AppImage developers, not our community.

Let's see who originally conceived, developed, and submitted Flatpak support. My guess is Red Hat or Flatpak or Gnome developers, not your community.

Let me check...

Indeed. The person who implemented it has pushed several Red Hat related technologies to this project: Flatpak, Wayland, Pipewire.

Certainly it has nothing to do at all with the fact that Red Hat "donated" 10,000 USD. Must be pure coincidence. For sure.
https://www.gamingonlinux.com/2021/12/red-hat-donates-10k-to-obs-studio-flatpak-to-be-official-for-linux/

This smells.
Badly.

[kkartaltepe]

Its understandable to feel frustrated that your PR was not merged, but the issue has really been the same ones that were there in 2018. Namely, no one wanted to step up and maintain this new packaging. The Appimage PR authors have put a lot of work in trying to make this work but there was never anyone to maintain and no one wants to merge something just to let it languish. I appreciate the many offers to help whoever maintains it but we really do need someone whos willing to read forum posts and talk to users and discuss with Appimage folks on how to fix issues, or its just not going to be good for users.

Believe it or not, there were people who were willing to support Wayland and wayland capture already in the team. Not only that but the author of those PRs was also kindly willing to become a maintainer of those features. Now when flatpak was proposed it had a significant advantage to Appimage, a willing maintainer.

We can all commiserate about the state of desktop Linux and RedHat's technical choices somewhere else, but rest assured Canonical making Wayland the default is much more impactful on this timeline than any donations.

[derrod]

I believe it is time to say goodbye to this thread.

[Fenrirthviti]

@probonopd So, I originally saw your comment here and twitter thread, and missed this absolute banger of an edit because you edited it after the fact, and GitHub doesn't send notifications on edits. This thread is closed, but I'm going to make a final reply before I ban you and your associate from our organization for your inflammatory, incorrect, and downright rude comments. Actions have consequences. Any time anyone asks us why we don't support AppImage, I'm going to point them to this thread, and how it was you, personally, who irrevocably burned all bridges with our development team.

Let's clear up a few things as well since you seem to have a continual issue with reading comprehension, and I don't want any misinformation floating around that you started to spread:

1. We did tell you back in 2018 we had a lot of concerns with the work. All documented in Create and upload AppImage for Linux #1926. You ignored those concerns, instead choosing to point out that it works fine for you, and I quote: "Here are two high-profile Linux users and podcasters talking about various application delivery formats for Linux and why they would like to have a OBS AppImage" in response to the bug reports. You have constantly reminded us that AppImage is a tool, and showed no interest in trying to fix reported bugs. Something that continues to this day.
2. My comment about how the PR was conceived and submitted by you was intended to point out that it was the AppImage development team pushing for AppImage support, and not a single member of our actual developers or user base. Parroting that "users want AppImages" when seemingly the only people interested in using them is the team who develops them is... well, I'll let the readers make up their own minds on that.
3. RedHat didn't pay us to support Flatpak, as has been explained in several other places, but I'm going to put that here and emphasize again for anyone coming across this: RedHat did not pay us to support Flatpak. The article simply has a slightly misleading title. They are reporting on two things that happened around the same time. The body of the article if you actually bother to read it, does not suggest the two are related. It was simply a coincidence.
4. The fact that feaneron - the original author of our Flatpak support - has ties to anything RedHat-related is irrelevant. Go look at the related Flatpak PRs, and the work and effort he put in to support both us as the maintainers, and the Flatpak build itself. We accepted it because they were communicating and not giving bullshit answers or straight ignoring questions and concerns and then whining endlessly about how nobody wants to adopt your "tools that application authors can use to produce AppImages". Take a look at how those interactions went, even when there were conflict and concerns, and maybe you'll learn something.

In any event, please do not bother our project any more. Your slander and passive aggressive comments are no longer welcome here.

[Fenrirthviti]

One more follow up comment, as this blew up a bit more than expected, just to clarify a few points. Sending this as a reply in case people are watching this, edits don't send notifications.

What has been banned from the project is probonopd and his developers who are involved in the development of the AppImage project and ecosystem. We have been effectively harassed for years by him because we didn't see the value in his proposition, and were not impressed with the lack of willingness to work with us or answer basic questions about the package. As long as he is in charge of the project, we will not be working directly with him or anyone on his team.

What has not been banned is the possibility of a community-supported AppImage package at some point in the future. We laid out our requirements very clearly over the multiple PRs and discussions we've had over the past 4 years (most of which is in this PR discussion thread), and there has been no work put towards them by anyone at this time. However, if there is enough demand and willingness to support the platform by our community, I am open to having that conversation.

Nobody will be banned from our project or communities for mentions of AppImage, nor suggesting they want one. People have been banned here, not technologies.