Back when I used to use windows I used AMD ReLive alot. It, and the nVidia version ShadowPlay Instant Replay, will constantly record the screen without using too much computer resources and at the press of a keycombo will save the last 30 seconds.
I wanted something like this for Linux...
I got tired waiting for someone else to do it.
A lot of people online suggest using OBS's replay buffer feature. However this requires opening OBS and start recording. I do not know when something will happen that I want to share. Might not even happen while playing a game. I just want something in the background (like a systemd service) so that whenever something happens I can record it.
You might notice that this uses JPEG to encode frames. Initially the plan was to use hardware-accelerated encoding. However, since there is currently no way to grab frames directly on the GPU, sending frames to the GPU and encoded packets back became a huge bottleneck that limited me to no more than ~40-50 FPS and lagged basically any game I tried playing. I changed plan of attack based on the idea that:
- most of the frames will probably get discarded so why bother working hard on them?
- we can reencode them properly when we need to save
- the inital encoding of the frames can be cheap and is more a form a memory-compression
- turns out that an image format from 1992 is very easy for modern computers
Thus, this program does use JPEG (specifically libjpeg-turbo) for encoding frames, but then switches to x264 when you want to save it. The compressed frames are stored temporarily in memory inside a circle buffer which will automatically grow and shrink depending on the compressability of the frames, while also allowing space for future growth without many resizes.
There is an official AUR package that gets updated from the CI (thanks to Bennett Hardwick): replay-sorcery.
Sergey A. has also setup a -git AUR package: replay-sorcery-git.
This project needs cmake, make and nasm (used by x264) for compiling. All dependencies (other than X11 development files) are built as part of the binary and statically linked in. Don't @ me it makes distribution easier.
$ git submodule update --init
$ cmake -B bin -DCMAKE_BUILD_TYPE=Release
$ make -C bin
$ sudo make -C bin install
It can be enabled as a user systemd service:
$ systemctl --user enable --now replay-sorcery
Once it is running, just press Ctrl+Super+R to save the last 30 seconds.
You can also use systemd to look at the output:
$ journalctl --user -fu replay-sorcery
The config files use the XDG base directory specification with a filename of replay-sorcery.conf. If you do not know what that means you can probably assume that the program will look for configuration files in the following spots:
/etc/xdg/replay-sorcery.conf~/.config/replay-sorcery.conf./replay-sorcery.conf
The configuration files themselves are simple <key> = <value> # <optional comment> pairs. An example config could be:
# 1440p monitor...
width = 2560
height = 1440
# ...to the right of a 1080p monitor
offsetX = 1920
# Reduce memory usage
compressQuality = 50
# Output files into their own folder
outputFile = ~/Videos/ReplaySorcery/%F_%H-%M-%S.mp4
These four options work together to specify the rectangle of the display to grab frames from. This allows you to select which monitor to read from or potentially just read part of a monitor. width and height can be set to auto to specify the whole screen. Default is 0, 0, auto, and auto respectively.
framerate is the framerate to record at while duration is the maximum duration of the replay buffer in seconds, before it starts to overwrite itself. Together they create the maximum size of the replay buffer (framerate * duration). Default is 30 and 30 respectively.
A value from 1-100 to specify the JPEG compression quality. Don't be afraid to lower this value for higher resolutions. The quality loss isn't that noticable most of the time and it greatly reduces the memory usage. Default is 70.
The key combo to use. Must be a series of modifiers followed by an X11 key name, all seperated by +. Due to limitations with XStringToKeysym, the keys are case sensitive. Valid modifiers are Ctrl, Shift, Alt, and Super. Default is Ctrl+Super+R.
The path to output the videos to. Can use strftime formatting. If you care about folder organization it is probably a good idea to make ReplaySorcery output into a subfolder inside Videos, for example ~/Videos/ReplaySorcery/%F_%H-%M-%S.mp4. This is not the default since currently ReplaySorcery cannot create folders and thus you have to make sure the folder exists before hand. Default is ~/Videos/ReplaySorcery_%F_%H-%M-%S.mp4.
These options can be used to run commands before or after outputting a video, for instance generating notifications, playing sounds or running post processing. Failures from these commands do not stop ReplaySorcery. The default is setup to show a notification when the output is finished, but it requires libnotify to be installed. Default is an empty string and notify-send ReplaySorcery "Video saved!" respectively.
These options control the audio recording and its quallity. audioDeviceName can be auto which will pick the default capture device (probably a microphone). A list of available capture devices is listed when the program launches. Look for device with name Monitor of..., that will let you record your sound. You can also change the device you want to record on the fly with a program like pavucontrol. audioChannels sellects how many channels you want to record. Tested vales are 1 for mono and 2 for stereo. 5.1 and other systems are not tested as of yet. audioSamplerate is how many samples per second you want to capture. It's best to select the same samplerate as your device, otherwise we'll have to convert the samples and that just wastes cpu and memory for no gains. Unless you changed something in your system you probably run at 44100hz which is the default. audioBitrate is the bitrate of the encoded audio. We use AAC encoder. Default is 96000.
- Does not track frame timing properly so if there is lag or dropped frames the output will be played back faster.
- Can be a bit resource hungry at times (in particular memory)
- Document code better
- Cross-platform support
- Doubt there is any demand though
- Maybe for Intel devices if they are fast enough?
- Smaller tweaks:
- Add sound effect for when it saves
- Add configuration option for changing hotkey
- Allow downscaling before saving