GPU Screen Recorder is a screen recorder for Linux whose entire design goal is to stay out of the way: it captures your monitor, a single window, a region or a camera and encodes the result with the graphics card’s own hardware encoder, so recording a game or a desktop session costs very little CPU. Its author, dec05eba, bills it flatly as “the fastest screen recording tool for Linux”, and the ShadowPlay-style instant replay — a rolling buffer that keeps the last few minutes of gameplay in memory and writes them to disk on a keypress — is one of its two headline features, the other being live streaming without a second machine.
The project is deliberately small and self-contained. It is written in C (meson build, no runtime framework, no account, no cloud service), it is developed on its author’s own Git server rather than GitHub, and every option is a command-line flag, which makes it scriptable from top to bottom. Two optional front-ends sit on top of it: GPU Screen Recorder UI, a fullscreen overlay in the style of NVIDIA’s ShadowPlay (opened with Left Alt+Z), and the older GPU Screen Recorder GTK window, now in maintenance-only mode because it has been superseded. The current release is 6.1.4 (October 2026), packaged in Arch Linux’s extra repository and distributed as a Flatpak on Flathub.
What separates it from the general-purpose recorders is where the work happens. The capture path itself runs on the GPU — NVENC on NVIDIA, VAAPI through Mesa on AMD and Intel, with experimental Vulkan video encoding as a third path — instead of pulling every frame through the CPU and the compositor. On a mid-range gaming desktop that is the difference between recording at 60 fps and recording at 23 fps, and on modern hardware it is often the difference between “I can record this” and “recording is not worth the frame rate”.
-k h264_vulkan, hevc_vulkan, av1_vulkan), which is also a workaround for the CUDA “p2 state” downclocking that affects NVENC on older NVIDIA drivers.-w screen or a named monitor (-w DP-1) for the whole screen, a specific X11 window (-w $(xdotool selectwindow)), the currently focused window, an arbitrary region (-region, designed to take output from slop on X11 or slurp on Wayland), the desktop portal over PipeWire on Wayland (-w portal), or a V4L2 camera device such as /dev/video0. Sources can be combined with | — screen plus webcam, two monitors side by side — and each one accepts placement and scaling (x, y, width, height, percentage values, halign/valign, hflip/vflip). --list-capture-options, --list-monitors and --list-v4l2-devices report what is available.-r 30 keeps a rolling buffer of the last 30 seconds (2 to 86,400 seconds) and writes it to disk only when asked. The buffer lives in RAM by default, or on disk with -replay-storage disk; fixed saves of the last 10 s, 30 s, 60 s, 5 min, 10 min and 30 min are available as signals, and the IPC socket can save an arbitrary number of seconds. -df yes files replays into date-based folders, and -restart-replay-on-save controls whether the buffer is cleared afterwards.-ro option names a directory for ordinary recordings taken from the same capture-and-encode pipeline, toggled with SIGRTMIN. Only one pass over the screen is made, so this is more efficient than running two recorders at once.-o at any destination FFmpeg can reach: RTMP to Twitch or YouTube (-c flv -bm cbr -q 8000 -o "rtmp://live.twitch.tv/app/<key>"), or WHIP for millisecond latency with a local mediamtx server on FFmpeg 8.0 or later. -keyint trades bitrate for latency, -auth passes a bearer token (or a username:password pair), and the token can be kept off the command line in the GSR_AUTH environment variable.-a app:firefox, or app-inverse: for everything else), combining sources with | so desktop sound and microphone land in the same file. Audio-only recording is a first-class mode: leave -w out and write an .mp3 or .mkv.gpu-screen-recorder -w screen -o screenshot.jpg captures a still frame to JPEG or PNG, with libjpeg-turbo used for fast JPEG encoding.-ipc) driven by the bundled gsr-cli, whose commands (save-replay, set-paused, start-replay-recording, stop, status…) report success or the reason for failure instead of being fire-and-forget. The -sc option runs a script after every save, handing it the file path and the type (regular, replay or screenshot) — the hook people use to show a notification or file the clip under the name of the game that was running.systemctl enable --now --user gpu-screen-recorder) configured through ~/.config/gpu-screen-recorder/gpu-screen-recorder.env, and the repository ships scripts/start-replay.sh, save-replay.sh and stop-replay.sh so a hotkey in any window manager can start replay and save the last minute..mp4 and .mov are written in hybrid fragmented mode, so the file is still playable after a crash or a kill and is converted to a normal non-fragmented file when recording stops. .mkv always behaved this way.-p plugin.so loads C plugins (interface published in plugin/plugin.h, installed to the system include directory) that draw extra graphics on top of the captured frame; several can be chained, and a worked example (hello_triangle) ships with the source.-s; cursor on/off; limited or full colour range; NVIDIA performance/quality tune; AMD low-power mode; raw passthrough of extra FFmpeg options; and -exclude-metadata to strip personal metadata such as audio track titles. --info prints the GPU, codecs and capture devices in machine-readable form, and a CPU H264 fallback (-encoder cpu / -fallback-cpu-encoding yes) exists for systems where no hardware encoder is usable.Because it removes the usual trade-off between recording and playing. The project publishes its own before-and-after numbers, and they are worth quoting as the author’s measurements rather than as independent benchmarks: on an i5-4690K with a GTX 1080, capturing The Legend of Zelda: Breath of the Wild at 4K dropped from 30 fps to 7 fps under OBS Studio with NVENC, while GPU Screen Recorder kept it at 30 fps; in GTA V at 4K on maximum settings the frame rate fell from 60 to 23 fps with obs-nvfbc plus NVENC, but only to 58 fps with GPU Screen Recorder. On a Ryzen 9 5900X with an RX 7800XT the author reports no frame-rate loss at all, even recording 4K at 60 fps in AV1 with 10-bit colour. The comparisons published alongside those numbers also claim smoother output than OBS when GPU utilisation is close to 100%.
The second reason is honesty about scope. There is no scene editor, no browser-source compositor and no plugin marketplace — this records the screen, encodes it on the GPU, streams it if you want, and stops. For a lot of people that is exactly the missing piece: something light enough to leave running in the background so the last 60 seconds of a game are always available, driven from a hotkey or a script, storing nothing in the cloud, with the source code (GPL-3.0-only) on your own disk. It is also the closest thing Linux has to NVIDIA ShadowPlay and AMD ReLive, and unlike those it is not tied to one vendor — the same command works on AMD, Intel and NVIDIA.
The honest caveats are worth stating. Recording a monitor on AMD, Intel or Wayland needs access to kernel mode-setting, so a small helper (gsr-kms-server) runs with those privileges — isolated in a separate program precisely so that nothing else does; a first-run password prompt on the Flatpak build is the visible consequence. On NVIDIA a package-supplied gsr-nvidia.conf is needed to stop CUDA breaking after suspend/resume, and the default variable-frame-rate MP4 output occasionally upsets video editors (record .mkv or use constant frame rate). Finally, the project itself has no GitHub repository and no corporate sponsor — updates come from one maintainer’s own Git server, which is a fair thing to weigh alongside the technical fit.
-w portal) when direct monitor capture is not permitted on your compositor.-sc script on save to notify and file clips by application name, gsr-cli commands from a desktop hotkey or a stream deck.Linux only, on both X11 and Wayland, with AMD, Intel or NVIDIA graphics — an OpenGL ES 3.0 capable driver is the baseline (2012 vintage or newer), with Mesa plus VAAPI for AMD/Intel and CUDA plus NVENC (and nvfbc for X11 capture) for NVIDIA; Vulkan video encoding needs a current Vulkan driver. PipeWire is required for per-application audio, and FFmpeg 8.1 or later for crash-safe MP4 output. Official install paths are the source tree (meson, or install.sh), Arch Linux’s extra repository (gpu-screen-recorder and gpu-screen-recorder-ui) and Flatpak on Flathub (com.dec05eba.gpu_screen_recorder). The Flatpak is the easiest route on other distributions and ships with a patched FFmpeg — NVIDIA encoding works down to driver 470.57.02 (Kepler) while still supporting AV1 and the RTX 50-series — and with all the vendor encoder drivers included. There is no Windows or macOS build. Community packages exist for Alpine, Debian/Ubuntu (as gpu-screen-recorder-cli, currently 5.13.8 in Debian unstable, so some way behind upstream), Fedora (Copr), Guix, NixOS, Nobara, OpenMandriva, openSUSE and Void, plus an AppImage; the project warns that only the three official sources are kept in step.
GPL-3.0 (GPL-3.0-only), free and open source with no paid tier, no account and no telemetry. The badge is set from the LICENSE file in the project repository (a verbatim copy of the GNU General Public License version 3), which the project’s README and man page both state as “GPL-3.0-only”, and which Flathub’s metadata for the same application confirms.
git.dec05eba.com/gpu-screen-recorder · README · manual page · Flathub · Arch package · GPU Screen Recorder UI · GTK front-end (deprecated)