wl-screenrec

wl-screenrec

High performance screen recorder for wlroots Wayland.

Uses dma-buf transfers to get surface, and uses the GPU to do both the pixel format conversion and the encoding, meaning the raw video data never touches the CPU, leaving it free to run your applications.

Open an issue if something is not working, I'm happy to take a look.

System Requirements

• Wayland compositor supporting the following protocols:

  • wlr-screencopy-unstable-v1 OR ext-image-copy-capture-v1

  • linux-dmabuf-v1

  • xdg-output-unstable-v1

    These compositors all meet this criteria:

    compositor	version
    Cage	0.2.0
    COSMIC	...
    Hyprland	0.48
    Jay	1.11.0
    Labwc	0.9.0
    Louvre	2.14.1
    Mir	2.19
    niri	25.08
    Sway	1.11
    Treeland	0.6.1
    Wayfire	0.9.0

• vaapi encode support, consult your distribution for how to set this up. Known good configurations:

  • Intel iGPUs
  • Radeon GPUs[^1]

[^1]: Mesa vaapi (which Radeon GPUs use) does not support transform, so wl-screenrec will not work if you have a monitor that has transform applied to it

Performance

(relatively unscientific) benchmark setup:

• 4kp60 display
• i9-11900H CPU/GPU
• vkcube running on screen, as both wf-recorder and wl-screenrec don't copy/encode frames when there is no difference

Additionally, with either wf-recorder setup there is visible stuttering in the vkcube window. wl-screenrec does not seem to stutter at all.

However, it does come at the cost of using slightly more GPU. Those number seem stable and I hypothesize that they are statistically significant, but still not a huge change.

Installation

From the AUR

paru -S wl-screenrec
# OR
paru -S wl-screenrec-git

Or, manually:

git clone https://aur.archlinux.org/wl-screenrec-git.git
cd wl-screenrec-git
makepkg -si

From source using cargo

Install ffmpeg 6 or later, which is a required dependency. ffmpeg 5 may work, but is untested (open an issue or PR if you test with ffmpeg 5 so I can update these docs on if it works or not)

cargo install wl-screenrec # stable version
# OR
cargo install --git https://github.com/russelltg/wl-screenrec # git version

Fedora

To install wl-screenrec on Fedora, it's recommended to install it from cargo. Before you do that though, make sure you have the following dependencies installed (you can get them all via DNF):

• libdrm-devel
• freeglut-devel
• clang
• ffmpeg-free-devel

Also, make sure you install full ffmpeg and codecs for hardware acceleration support via RPM Fusion.

FreeBSD

pkg install wl-screenrec

Usage

Capture entire output:

wl-screenrec         # valid when you only have one output
wl-screenrec -o DP-1 # specify output

Capture region:

wl-screenrec -g "$(slurp)"    # use slurp
wl-screenrec -g "0,0 128x128" # manual region

Capture 444 video (no pixel format compression):

NOTE: Look at vainfo -a to see your supported pixel formats. Support is very hardware-dependent. For example, on my machine only HEVC supports 444 formats, and all of 8-bit RGB formats didn't work for whatever reason.

wl-screenrec --codec hevc --encode-pixfmt vuyx   # 8-bit 444
wl-screenrec --codec hevc --encode-pixfmt xrgb10 # 10-bit 444

Capture with audio:

wl-screenrec --audio                                                                 # default capture device
wl-screenrec --audio --audio-device alsa_output.pci-0000_00_1f.3.hdmi-stereo.monitor # capture desktop audio (example, use `pactl list short sources` to figure out what you should put here)

Record with history:

wl-screenrec --history 10 & # record the most recent 10 seconds into memory, not writing into the file
# ... some important event occurs
killall -USR1 wl-screenrec  # flush the most recent 10 seconds onto the file, and start appending to the file like recording normally

Capture to v4l2loopback (for Zoom, etc):

sudo modprobe v4l2loopback
v4l2-ctl --list-devices # find "Dummy video device" device. /dev/video6 in my case.
wl-screenrec --ffmpeg-muxer v4l2 -f /dev/video6

All options

…

Known issues

• Cannot capture a region that spans more than one display. This is probably possible but quite difficult, especially with potential differences in refresh rate. Probably will never be supported.