While OBS is in RPM Fusion free, it does not ship with the Browser Source (and a couple other plugins), which for me as a streamer is a real turn-off. Browser Source is used extensively for Overlays, and with OBS 27 we even finally get Browser Docks, which also rely on the same underlying Browser Plugin.
Note: While there is a (depracated) third-party plugin that still works, this has its own issues and does not support Browser Docks anyway.
Short background
Initially I attributed the missing Browser Source simply being down to outstanding dependency issues. But seeing as compilation was explicitly disabled in the F34 OBS spec-file, I believe that there is either no willingness to include it, conflicts with the Fedora Packaging Guidelines (or any number of other obscure guideline documents), or simply licensing issues with CEF (although other CEF based packages like Discord are available, so this is unlikely).
The solution
Seeing as nothing would be happening anytime soon I set out to build it myself after my adventures in the small linux problem thread (also, thanks again for helping me figure out mock and my usergroup issues).
I used the aforementioned RPM Fusion spec-file as a base and after a couple hours of headbanging-against-the-wall I finally got it to compile and it’s working great.
The goal
Ideally I would like this to eventually be at feature-parity with the official Ubuntu PPA, missing is currently still FTL and AMF Encoding. Both of which I don’t know if they are still useful:
I don’t know if any streaming service outside Mixer ever used FTL and/or if it’s still maintained. Re-checked, FTL is enabled
I don’t know if AMF is actually in the Ubuntu PPA or if that is Windows exclusive (all other platform specific plugins have platform-prefix, which makes me think it is also on Linux, but I thought ffmpeg took care of that).
The questions
Now, ideally I would like to put it on COPR, and here’s where my questions come in:
This is probably my biggest issue right now. I don’t know if I’m even allowed to put this package on COPR in the first place. I tried going through the FAQ and Guidelines, but they are complex enough that I have trouble understanding what exactly is allowed and what is not. From what I can tell, basically anything that is an “open” license is allowed, but here is where it gets tricky. The CEF License is fairly short. It essentially only states this license file must be provided with the packaged software in some way:
“Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.”
However, looking at other software utilising CEF (e.g. Discord via Electron on RPM Fusion nonfree), it’s not always included (according to dnf repoquery --list discord), so either I’m reading it wrong or it’s just not taken seriously.
How do I “properly” handle the Release in the spec-file? Since DNF is looking for the package name in all enabled repositories users could end up switching between the RPM Fusion version and the COPR repo, depending what happens to be the latest Release at the time of updating. This would also mean I would have to push a new Release of the spec-file every time there was an update in RPM Fusion, and preferably fast. I see 2 options:
Use a higher Release to start with, e.g. start at 10 or 11 and go up from there. Not very clean but it would guarantee it’s always the “higher” version and requires no user-interaction (presumably they want to keep the higher version at all times anyway).
Make the user edit their /etc/dnf/dnf.conf to ignore the OBS package in RPM Fusion. Technically cleaner, but not everyone likes messing with their system config. Would also have to look up how that would be done.
any others I’m missing?
OBS utilises a bunch of git submodules, which in turn have their own submodules. To get it to work I was manually listing the (recursive) submodules and put them all in separate SourceX definitions. Obviously that’s a lot of work and could be solved by doing a git clone --recursive, but I cannot find documentation if that is allowed in an RPM and/or on COPR.
This is more out of curiosity then necessity, but is there a way of marking a package as an early/beta release in a way that it is not automatically pulled? For example if the user just installs using dnf install obs-studio it would pull a stable version, even if there is a higher version available, but marked as a beta release (which could be installed by specifying the version). Is this an option in RPM at all?
If you made it this far, thanks for reading
And if anyone can enlighten me, I’m all ears eyes.
No, I might though if I don’t find a solution. Didn’t even think about their contacts
I don’t have a Looking Glass setup (or any passthrough at all for that matter), so there’s not much I can test other then if the plugin loads, unfortunately.
edit:
Chatted them up in the irc-channel linked at the bottom of the COPR page, no answer as of an hour later…
So in the mean time I just created my Fedora account (also an ordeal ), and created the repo (no code in there yet), and was greeted by this nice warning:
Well, that’s what I already read… but I don’t see any mention of rpmfusion in there. And also, there are are a ton of repos that use rpmfusion as a dependency, so I’m just really confused on what’s allowed and what isn’t…
Just in case this gets removed eventually, are there any other build services I could use instead?
So, I asked in their IRC and while it took a bit, I finally got a definitive answer which is… unfortunately now:
[05:44] <…> the issue won’t be CEF blob, it’s that x264/x265/ffmpeg aren’t permitted on Fedora infrastructure
[05:45] <…> you cannot build OBS Studio on Fedora infrastructure unless you can come up with versions of those dependencies that don’t infringe on software patents
[05:45] <…> (sadly, that’s not easy to do…)
[05:46] <…> technically this is a problem with the CEF blob if it has multimedia support built in
[05:46] <…> (no idea if it does or doesn’t, though)
I’ll look into the Open Build Service, maybe I can host it there.
From what I can tell though and speaking with a couple people in the OBS Studio discord, it seems on the Open Build Service it’s even more restricted… can’t add external repos unless I’m blind. Also using/including the CEF blob is apparently not very well liked.
Does anyone know of another build service or another instance of the Open Build Service (i.e. one not hosted by SUSE), that allows this stuff?
If all else fails I’ll try to figure out GitHub releases so I can maybe upload it there…
You can modify the list of enabled repositories for a particular Fedora version you’re building for, I’ve done that before. If what they said about ffmpeg and x264/5 mean that the packages cannot exist in any form on the Fedora infrastructure, even pulled in as a dependency, you might have to look into other hosting options.
For a couple of repos of mine (mainly 32 bit wine for CentOS 8) I’ve built the packages locally using mock (which is what COPR uses on the backend) and I’m hosting them on my own FTP server (http port is blocked by ISP).
I can host it if you want
I did that (and fun fact, when you enable rpmfusion repositories it even shows a warning that that’s almost never a good idea).
That’s exactly it, unfortunately.
That’s what I’m doing right now
The hosting itself isn’t really that big of problem (hell I could upload it to the forum ), what I wanted though was DNF integration (i.e. a real repo with autoupdate and everything). I don’t even care about automatic builds too much (since OBS doesn’t update that often and I need to test the builds anyway), even though it would be a nice bonus.
(thanks for the offer though )
Gave up on the automated builds (for now) and uploaded it manually. First release here:
Service Integrations work locally (with a separate compile of course), but I need to clarify with the OBS people whether I’m allowed to use their Client-IDs. If I am allowed to I also want to find a way of passing on Environment variables to mock, since I don’t want to put the ClientID on GitHub for obvious reasons.
edit: had to reupload the RPM because I forgot the libs (lol),
Update:
Finally pushed the 27 Final RPM to GitHub yesterday:
If anyone knows of a build service I can use to build this (or even a Repo I can manually upload to), feel free to ping me.
To be clear: COPR and Open Build Service are not an option.
Yeah, a repo hosted on an ftp server. I got one of those VPS things so now I can host over http(s) too.
Don’t need to sign it unless you really want to.
I know this is late and random, but… This feature has been in the flatpak for some time. I believe the workaround was a feature that spotify uses. There are post on GitHub on how to build the flatpak on your own until it is merged into the repo.
for “some time” is not entirely accuracte, it was released at the same time
But yes I know about that, I just happen to not be a huge fan of flatpak and snap and whatever else.
They have their place (IMO mostly for super-frequent releases like rpcs3, or for proprietary software that relies on specific lib versions), but for most especially open source applications I just don’t get the hype about them because everyone and their mother wants to make a flatpak for every tiny project. And on all projects I’ve seen them on they produced more issues then they solved.
anyway… /rant
Thanks for the hint, and if people want to use it of course they are free to, I just like packaging it natively
I mean “for some time” because this has been active since last year (ver. 24 ish ) that I’m aware of in some form or another. It wasn’t until March of this year that a working version, and one agreed to by the devs was published. I think they are using the flatpak to push more experimental work which when implemented properly Is actually a good channel for it.
Most of the issues I’ve seen are from devs being unaware of how it works or can work. There’s so much, that it will take time for all the scenarios to iron out. In my opinion, It does help in the distribution of packages. When done “properly” it’s just one less headache.
The Flatpak is not even maintained by the OBS team
The Flatpak maintainers do tend to put in some experimental stuff sometimes yes.
With the browser its a bit more complicated. It was working for a time until some issues were discovered with CEF and how it integrated with Qt. The Flatpak had it working because they used some specific lib versions I think, but the official release had it disabled again with 25. In 26 those issues were fixed and are now available for all Distros.
There is still one outstanding bug that is most likely an issue with Qt and only happens with Docked Browser panels, but that should hopefully be fixed at some point #4488 if you’re interested.
Probably the case with anything dev related, but yes. It’s just that personally for something that can be re-compiled anytime to fix potential issues with incompatible lib-versions, I don’t see the point in Flatpak/snap/AppImage where they pin lib-versions.
I also don’t really get the difference between the 3 and why Flatpak and snap were introduced in the first place when AppImage already existed, but that’s a whole different discussion
Do you possibly know if this OBS repo of yours also works with quicksync through VAAPI? I’ve never been able to get quickync working with my haswell CPU on Fedora, even though nvenc works perfectly. Quicksync works perfectly on windows OBS.
I seem to remember reading it had to do with rpmfusion OBS not being shipped with the VAAPI plugin or something?
I don’t have an Intel CPU at hand unfortunately, so I can’t test.
I used the RPM Fusion spec as a base and just added the Browser Stuff though so if it didn’t work on RPM Fusion it is unlikely it will here.
If you have some pointers what needs to be added I can try to get it in though (or throw me a pull request if you know what needs to go in ).
FFMPEG VAAPI is an option in the encoder settings though, so from the OBS side it “should” just work™
But on that note: VAAPI is an ffmpeg thing and if ffmpeg is available (which it should be since it’s a hard dependency) then it should just work? Provided RPM Fusion ffmpeg was built with VAAPI support that is. I’m not sure if ffmpeg VAAPI support needs any other intel driver specifics from Mesa maybe. Might have to check ffmpeg’s documentation for that.
edit:
You might need libva-intel-driver to enable QuickSync, if that’s not already installed
), and created the repo (no code in there yet), and was greeted by this nice warning:
) that I’m aware of in some form or another. It wasn’t until March of this year that a working version, and one agreed to by the devs was published. I think they are using the flatpak to push more experimental work which when implemented properly Is actually a good channel for it.
