gpu-screen-recorder/include/recorder/replay_save.h, branch debianThe fastest screen recording tool for Linux
https://sekoohaka.ddns.net/Debian/gpu-screen-recorder/atom?h=debian2026-08-07T11:53:40ZRevert "Clear replay data in replay save thread to not block the main capture thread"2026-08-07T11:53:40Zdec05ebadec05eba@protonmail.com2026-08-07T11:53:40Zurn:sha1:90ac49f372f4c3d3d12f4d0d58ab0473a86821d5
This reverts commit 5db30f3fb99545524fc80f87ecc488972aec1711.
Clear replay data in replay save thread to not block the main capture thread2026-08-06T10:56:48Zdec05ebadec05eba@protonmail.com2026-08-06T10:56:48Zurn:sha1:5db30f3fb99545524fc80f87ecc488972aec1711Add -ipc option to control gpu-screen-recorder over a unix domain socket2026-08-01T23:11:53Zdec05ebadec05eba@protonmail.com2026-08-01T23:11:33Zurn:sha1:d72113be395891f4289f0d86a32a37a99a4d5b38
The socket accepts the same commands as the signal handlers, except that
saving a replay takes an arbitrary number of seconds instead of only the
fixed times that the signals provide. Requests and replies are newline
terminated json objects and every request is replied to, parsed with the
sj.h json library that was added to external.
Requests are handled on a thread that only runs while the recorder
exists, so the recorder control fields are now atomics, which they have
to be now that another thread writes them.
Move muxing and replay saving from main.cpp into muxer and replay_save modules2026-08-01T21:02:07Zdec05ebadec05eba@protonmail.com2026-08-01T21:02:07Zurn:sha1:40b6a13d14680cfacb3cdb59f04224540b80d9e4
Replay saving uses a pthread with an owning result struct instead of
std::future and a global output filepath.