Kooha: A Minimal GTK4 Screen Recorder for Wayland and X11 Linux Desktops

What Kooha Is For, and What It Is Not

Kooha is a screen recorder for Linux desktops, written in Rust and built on GTK4 and libadwaita. The README describes it as a simple screen recorder with a minimal interface, where you can click the record button without configuring a pile of settings. That sentence is the whole product thesis: it is a capture tool for people who want one clip, not a studio.

The feature list is short and specific. It records the microphone, desktop audio, or both. It writes WebM, MP4, GIF, and Matroska. You can pick a monitor or a portion of the screen, set the saving location, toggle the pointer, choose a frame rate, and set a delay. Hardware-accelerated encoding exists but is described as experimental.

So the audience is a Linux desktop user who wants to record a bug, a demo, or a short tutorial and then stop. It is not for someone who needs scene composition, multi-track audio mixing, or a streaming pipeline. Those needs sit outside the feature list entirely.

How the Recording Pipeline Actually Works

The mechanism is visible in Cargo.toml. Kooha depends on gstreamer with the v1_22 feature, on gst-plugin-gif, and on gst-plugin-gtk4 with the dmabuf, gtk_v4_14, wayland, x11egl, and x11glx features enabled. The gtk4 plugin is how a GTK4 window becomes a GStreamer video source, and the dmabuf plus Wayland and X11 EGL/GLX features are what let that source hand over GPU buffers instead of copying frames through system memory.

That explains the runtime requirements. Kooha needs pipewire, gstreamer-plugin-pipewire, xdg-desktop-portal, and a portal backend such as gtk, kde, or wlr. On a Wayland session, the compositor does not let an ordinary application read the framebuffer. The portal mediates that: Kooha asks the desktop for a screencast, the portal shows a consent dialog, and PipeWire carries the frames to GStreamer. Kooha itself never touches the screen directly.

The practical consequence is that most "it does not work" reports are not Kooha bugs. The README says as much, pointing readers to the screencast compatibility page of the xdg-desktop-portal-wlr wiki to check whether their distribution supports it out of the box, and to a troubleshooting checklist if it does. The app is the last link in a chain that starts with your compositor.

Installing Kooha from Flathub and Recording a First Clip

Flathub is the distribution channel the README puts first, with a download badge linking to the io.github.seadve.Kooha listing. If you have the Flatpak remote configured, the install is a single command.

flatpak install flathub io.github.seadve.Kooha

After it completes, launch it from your application menu or with the run command below. The window that opens is the recorder: a source selector, an audio selector, and a record button.

flatpak run io.github.seadve.Kooha

Press record. Your desktop should show a portal consent dialog asking what to share; approve it, and recording starts. Press stop, and Kooha saves the file to the location configured in its preferences. The README lists the saving location, pointer visibility, frame rate, and delay as the configurable settings, so those are the ones to look at if the output is not what you expected.

The README also documents an environment variable for the features it disables by default. Setting KOOHA_EXPERIMENTAL to all turns on every experimental feature at once, and the README gives this example:

KOOHA_EXPERIMENTAL=all flatpak run io.github.seadve.Kooha

You can also enable features individually by passing a comma-separated list of keys, such as experimental-formats and window-recording. The README warns that these are off by default because of stability issues and possible performance degradation, so treat them as opt-in experiments rather than settings.

The Experimental Flags and Their Documented Failure Modes

The README's table of experimental features is unusually honest, and it is the most useful page in the repository. Three keys are listed. experimental-formats enables other codecs, including hardware-accelerated encoders, VP9, and AV1, and the documented issue is stability. multiple-video-sources enables recording multiple monitors or windows, and the documented issues are stability and performance. window-recording enables recording a specific window, and the documented issue is flickering.

Read that table as a statement of where the project is. Window recording flickers, which is exactly the kind of artifact that makes a capture unusable for a demo. Multi-source recording costs performance, which matters because encoding is already the expensive part of the pipeline. Hardware encoders are gated behind a flag because they are not reliable across the driver and GStreamer combinations that users actually have.

The MP4 path carries its own requirements. The build prerequisites list x264 for MP4 and gstreamer-plugins-ugly for MP4, while gstreamer-plugins-bad is listed for VA encoders. If you install through Flatpak those are bundled, but a distribution package that omits them will not produce MP4 even though the format appears in the UI. That is a packaging problem, not a Kooha problem, and the README notes that third-party packages are not officially supported by the developer.

Building Kooha with Meson Instead of Flatpak

The README recommends GNOME Builder, which uses Flatpak manifests to create a consistent build and run environment across distributions. The manual path is Meson, and it expects a long list of development packages: meson, ninja, appstreamcli for checks, cargo, x264, gstreamer plus gstreamer-plugins-base, gstreamer-plugins-ugly, and gstreamer-plugins-bad, glib2, gtk4, and libadwaita.

git clone https://github.com/SeaDve/Kooha.git
cd Kooha
meson _build --prefix=/usr/local
ninja -C _build install

The Cargo.toml pins the toolchain expectations. The crate declares edition 2024 and rust-version 1.90, and the release profile enables link-time optimization while the dev profile strips debug info and sets debug to 0. That dev profile note in the manifest is explicit: it trades line numbers in backtraces for build time. If you are debugging a crash in a locally built copy, that trade-off is worth remembering.

Version numbers are pinned tightly across the GTK stack: libadwaita 0.9 with the v1_9 feature, gtk4 0.11 with the gnome_50 feature, gstreamer 0.25 with v1_22, and the gst-plugin-gtk4 and gst-plugin-gif crates at 0.15. A distribution that ships older GTK or GStreamer will fail to build rather than degrade gracefully.

Where Kooha Is the Wrong Tool

The first limitation is environmental, and it is not negotiable. Kooha cannot record on a desktop that lacks a screencast-capable portal backend. The README lists xdg-desktop-portal-(e.g., gtk, kde, wlr) as a runtime requirement, and it sends users to the xdg-desktop-portal-wlr wiki to determine whether their distribution has support out of the box. If your window manager or compositor has no screencast implementation, no amount of configuration inside Kooha will help.

The second limitation is scope. Kooha is a GUI application. There is no command-line recording mode described in the README, and no scripting interface. If your use case is capturing a headless CI job, a scheduled recording, or a pipeline that starts and stops capture programmatically, Kooha is the wrong layer. You want GStreamer directly, or a tool that exposes a CLI.

The third is the experimental surface. Window recording flickers and multi-source recording costs performance, per the README's own table. Anyone whose workflow depends on either should plan around the flag being off by default, and should test the specific combination of compositor, GPU, and encoder they intend to use.

Finally, the GitHub releases show a slow cadence: v2.3.0 in March 2024, v2.3.1 in August 2025, and v2.3.2 in June 2026. The last push to the default branch was on 2026-09-18, so the repository is not dormant, but the release rhythm means fixes arrive in batches rather than continuously.

Kooha Against OBS Studio and Against GStreamer Directly

The obvious alternative for Linux desktop recording is OBS Studio, and the difference is architectural rather than cosmetic. OBS is a compositing and streaming application: scenes, sources, filters, and an output graph you assemble before recording. Kooha is a capture dialog. It has no scene model, no source mixing beyond audio selection, and no streaming output in the README's feature list.

That is not a knock. It is the reason Kooha's interface is one window. If you need to switch between a webcam and a screen mid-recording, or overlay a logo, OBS is the tool, and Kooha is not attempting to compete there. If you need a thirty-second clip of a window, OBS asks you to configure more than Kooha does.

The other alternative is using GStreamer yourself. Kooha is essentially a GTK4 front end over a GStreamer pipeline that receives PipeWire frames through the portal. Writing that pipeline by hand gives you control Kooha deliberately hides: arbitrary encoders, arbitrary muxers, arbitrary post-processing, and a scriptable command line. The cost is that you own the portal negotiation, the format negotiation, and the failure modes. Kooha's value is packaging that chain into a window with a record button, and the README's troubleshooting section exists precisely because the chain has many links.

Licence and Maintenance Cost

Kooha is licensed GPL-3.0-or-later. The Cargo.toml states the crate licence as GPL-3.0-or-later and the repository carries a COPYING file at the top level. For most desktop users this changes nothing. For anyone embedding Kooha's code in another application, the copyleft terms apply to the combined work, and that is a question for a lawyer rather than for this article.

The maintenance picture is straightforward. The repository is not archived, and the last push to main was on 2026-09-18. Releases are infrequent: v2.3.2 arrived in June 2026, roughly nine months after v2.3.1 and more than two years after v2.3.0. The version in Cargo.toml is 2.3.2, matching the latest release.

Upgrade cost is low if you install from Flathub, since the runtime and its GStreamer plugins travel with the app. It is higher if you build from source, because the pinned GTK, libadwaita, and GStreamer crate versions mean a distribution upgrade that moves those libraries can require a rebuild against matching versions. The README directs third-party package users to Repology to see what is available, and states plainly that those packages are not officially supported by the developer.

Editorial conclusion

Adopt Kooha if you are on a Wayland or X11 Linux desktop with PipeWire and a working xdg-desktop-portal backend, and you want a short recording without opening a settings dialog. Do not adopt it if your compositor lacks a screencast portal implementation, or if you need scripted, headless capture; the app is a GUI, and the README points to the xdg-desktop-portal-wlr compatibility page when it does not work. Before relying on it, verify that a portal backend is installed for your desktop and confirm which output format your encoder stack supports.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SeaDve/Kooha on GitHub