Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
scripts:ffmpeg:kmsgrab_screen_capture [2022-04-06 19:26] – Tony | scripts:ffmpeg:kmsgrab_screen_capture [2025-01-03 05:46] (current) – Tony | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Better, faster screen capture with kmsgrab ====== | ||
+ | Those of you that have tried to use x11grab are probably aware that it is terrible at high resolutions. To be fair, it's not really FFMPEGs fault either to capture an aging X11 window (yes I remain hopeful for Wayland). The user experience isn't great though, and not only does it drop frames, it tends to lag the entire X server causing everything on screen to stutter as well. By the way, this isn't limited to FFMPEG, full XSHM screen capture on OBS has the same issue (and probably uses similar underlying logic. | ||
+ | |||
+ | There are a few alternatives: | ||
+ | |||
+ | * However Xcomposite works on OBS doesn' | ||
+ | * OpenGL capture also seems to work fine at higher resolutions | ||
+ | |||
+ | Anyways, here, I'm going to describe kmsgrab. Its another capture source for ffmpeg that works much better then x11grab (with some limitations). It still drops some frames but overall seems better then x11grab. It is quirky sometimes though and isn't as flexible. Also, it doesn' | ||
+ | |||
+ | Information on the input is available here: [[https:// | ||
+ | |||
+ | To use it, you first need to enable CAP_SYS_ADMIN as follows | ||
+ | < | ||
+ | |||
+ | sudo setcap cap_sys_admin+ep / | ||
+ | |||
+ | </ | ||
+ | |||
+ | Credit to [[http:// | ||
+ | |||
+ | |||
+ | You can run `which ffmpeg` to find out your binary location, but it is typically / | ||
+ | |||
+ | sudo setcap cap_sys_admin+ep / | ||
+ | | ||
+ | |||
+ | Then, to capture, you can use the following | ||
+ | < | ||
+ | |||
+ | ffmpeg -device / | ||
+ | |||
+ | </ | ||
+ | |||
+ | This also captures with VAAPI to use hardware encoding. You need vaapi setup to use it, otherwise, use libx264. See [[https:// | ||
+ | |||
+ | Adding -b:v and -maxrate will use VBR (in theory). Use the same value for both to get CBR instead (useful if you're going to stream straight to Twitch/ | ||
+ | |||
+ | Note, you may need to change / | ||
+ | |||
+ | As always, I recommend never recording to mp4 files (or anything else w/ metadata at the end) since you will corrupt the file if the recording crashes. Use mkv (or ts) instead. | ||
+ | |||
+ | |||
+ | ===== 2022-04 Update ===== | ||
+ | Looks like the h264_vaapi has a problem initializing and saving in the mkv file. A workaround is to use CPU encoding, but note that on AMD video cards, you'll need to keep the vaapi section, just not the encoder. For this, swap to normal scaling, and bgr0 format. Here is an example using the mpeg2 encoder, since it sucks, and is fast enough on slow computers. | ||
+ | |||
+ | ffmpeg -re -f alsa -i pulse -framerate 15 -device / | ||
+ | |||
+ | |||
+ | ===== 2025-01 Update ===== | ||
+ | |||
+ | Uh so this has had a fundamental issue for me since I switched to using 10 bit HDR in Wayland, which uses texture formats not supported. | ||
+ | So no kmsgrab if you are using 10 bit color, and have HDR hacks in KDE Plasma 6 for now. |