2022-11-29 Update: This post aged like milk, unfortunately. After an upgrade to Fedora Silverblue 37, the script to build vl42loopback contained entirely within a Podman container no longer works for me, and despite diving in to the code, I haven’t yet been able to figure out why. The Kernel module builds, but I’m presented with a blue/purple image attempting to consume the virtual camera feed in OBS Studio. I hope to figure out the issue and submit a PR, but for now the virtual camera is unusable. The rest of Silverblue, Toolbox and OBS Studio works great, though!
Several months ago, I switched my daily driver and work laptop OS over from Fedora to Fedora Silverblue. The idea behind Silverblue is an immutable operating system layer, with anything other than the very base OS running in Linux containers - either traditional Podman containers, Flatpak packaged apps, or toolbox containers. This design is to more strictly separate user applications from the operating system itself, leading to more stability and security for the operating system, and providing more flexibility and variability for user-installed applications. It’s a pretty big shift in philosophy and technology from where Linux desktop and workstations have come from, and the learning curve is not really gentle if you try to fight against that shift.
One of the things I wanted to do with my daily driver was to have a more professional appearance in online meetings, and to do this, I wanted to use OBS Studio. OBS allows you to create a virtual camera that you can use as the camera for things like Meet or Zoom, and you can tweak the image stream with filters (such as using a green screen to create a uniform background), adding overlay text or images, etc. and work with it much like a television studio might. Streamers will be pretty familiar with the concept.
About a year ago, I’d played with OBS with Flatpak and a normal Fedora system, and struggled a lot to manage the streams, plugins, audio, etc., so I was pretty concerned that I may not be able to pull off what I wanted to do with Flatpak and Fedora Silverblue. Luckily, this ended up being a surprisingly, wonderfully easy process!
Virtual Camera and v4l2loopback
As I’m writing this, the OBS Studio Flatpak package on Flathub seems to have resolved every issue with it that I’d had in the past, chief among which is support for a virtual camera through a v4l2loopback device. It looks like this was baked into OBS Studio version 27 or later thanks to Github user
GeorgesStavracas’s merged pull request #4552, and I’m currently using 28.3. Out of the box, however, there is no “Start Virtual Camera” option, and I suspected that was because the v4l2loopback kernel module didn’t exist on Silverblue by default.
I was concerned that I might not be able to build the v4l2loopback kernel module on Fedora Silverblue, or if I could, that it might require installing a ton of overlay packages to the ostree. I have been trying to focus on doing everything inside of containers and keep from using any overlay RPMs to this point. I suspect going the container route will make what I do more easily shareable with others using Silverblue, and for reasons I can’t fully explain, I dislike the idea of adding overlay packages into an immutable ostree. I dunno, it’s a quirk.
Luckily, someone has already solved this conundrum for me. Robert Bohne, aka Github user rbo, created a script to build vl42loopback contained entirely within a Podman container, and a handy little function to load or unload the kernel module itself.
Note: As a coworker of mine, I trust Robert, but given that this is messing around with both kernel modules and privileged containers, you should check out the script yourself before you use it.
His code worked like a treat, though. I forked his repo for easy access later, but otherwise was able to build the module and install it with two easy commands:
# After cloning the repository $ sudo ./silverblue-v4l2loopback-module build $ sudo ./silverblue-v4l2loopback-module load
After a restart of OBS Studio, the “Start Virtual Camera” button was there and I was able to select the virtual device from the list of camera devices.
I did notice that there was a delay in the camera capture in OBS and what was shown through the virtual camera, but that turned out to be the “Use Buffering” setting in the video capture device source settings for my physical camera, so it didn’t have anything to do with the v4l2loopback, and was likely a leftover setting of my own in OBS rather than an issue with OBS itself.
Importing Scenes and Profiles
The only other issue I had with OBS Studio via Flatpak was figuring out where or how to import the Scenes and Profiles I had already created on another Fedora machine. With a normal installation, all the OBS Studio configuration information follows the XDG Base Directory Specification, and stores configuration information in
~/.config/obs-studio. I suspected that the Flatpak package wasn’t going to be able to read this directory. One of the key principles of Flatpak is to try to segregate the application from the host system as much as possible, to increase security. I gave it a shot, just in case, and copied all the config from my other machine over to the
~/.config/obs-studio directory on the Silverblue machine. Sure enough, when I started OBS Studio, none of the Scenes were there, so I had to do a little digging.
Turns out I needed only a little trowel and not a giant backhoe to dig into this issue. Immediately, I found documentation about Flatpak’s Sandbox Permissions explaining that
$XDG_RUNTIME_DIR/app/$FLATPAK_ID were the only two writable directories by default. What that meant didn’t immediately click for me, but I quickly found a Reddit thread discussing plugins and OBS Studio in a Flatpak, where the OP explained the config directory was in
~/.var./app/com.obsproject.Studio/config/obs-studio. BINGO! After copying my obs-studio config to that directory and restarting OBS, all of my Scenes and Profiles were there.
The last hurdle was making sure all of the images referenced in the Scenes were updated - I didn’t really know what I was doing the first time I setup OBS, so they were linked from all over on the previous machine - but OBS made that easy with the missing files prompt that pops up immediately when opening a Scene. I ended up creating a
~/Pictures/obs-studio/ directory with my backgrounds and other images, and easily updated the scenes to point to them there.
This section exists just to express my shock and awe at just how well Pipewire works with the Flatpak OBS Studio package. Sharing a full screen or an individual window works just like you’d expect it to in 2022. Anything I tried to select on my system was immediately visible within the OBS Studio stream, either as a full screen capture or an individual window share. The improvement since my previous foray into Flatpak-packaged OBS has been huge and I’m stunned how much work has been done in less than a year.
When I first started looking into using OBS as a virtual camera - or even just a basic streaming program - on Fedora Silverblue, I fully expected it to either not work at all, or require some crazy number of hoops to jump through. As Linux users, I think we’ve all become used to having to tweak things here or there to get them to work, but especially with audio and video. I was extremely pleasantly surprised to be able to easily and effortlessly install a containerized version of OBS Studio with Flatpak, get the v4l2loopback kernel module installed (yeah, “LOL, you had to compile a kernel module to get it to work” - fair, but it was STUPID easy…), and finally migrate my existing Scenes and Profiles.
I can honestly say that while Silverblue has been a pretty steep learning curve, the process itself has been really effortless, well supported by the community, and boils down to just learning a new philosophy rather than fixing bugs and working around problems. My experience with OBS Studio in Flatpak - and a kernel module, no less - has been a perfect highlight of that for me, and it makes me enjoy Silverblue even more.