wl-screenrec: geometry parameter doesn't use the correct coordinates

If I run wl-screenrec -g "$(slurp)", it always records from the top left corner of my monitor. The dimension is honored however.

e.g wl-screenrec -g "1375,814 1091x589" gives me a video with a resolution of 1091x589, as expected… except all I see is the top left corner of my screen.

Distro: Arch Linux (x86-64) wl-screenrec version: 195176732b2be737ec39098c85f7f5d8bb611573 (wl-screenrec-git on the AUR) ffmpeg version: 6.1 (Arch package version: 2:6.1-3)

About this issue

  • Original URL
  • State: open
  • Created 6 months ago
  • Comments: 41 (23 by maintainers)

Most upvoted comments

Ok, i’ve managed to build it and can confirm: the fix works.

Reported upstream at https://gitlab.freedesktop.org/mesa/mesa/-/issues/10658. If possible, please make an account there and turn on notifications if Mesa devs ask you to test any patches.

Hopefully we can get this resolved soon!

Mesa 24.0 doesn’t have the commit (see the 24.0 branch)

If somebody could test and confirm the fix, that would be fantastic. Requires building mesa, so only for those that are comfy.

Okay, fantastic. I believe this is a mesa bug. I want the logs+output of one a few more commands:

ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -f lavfi -i testsrc=duration=10:size=1280x720 -filter_complex 'hwupload, crop=356:356:401:281:exact=1,scale_vaapi=format=nv12:w=356:h=356' -c:v h264_vaapi -loglevel 80 cropped_evensize_oddshift.mp4
ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -f lavfi -i testsrc=duration=10:size=1280x720 -filter_complex 'hwupload, crop=356:356:402:282:exact=1,scale_vaapi=format=nv12:w=356:h=356' -c:v h264_vaapi -loglevel 80 cropped_evensize_evenshift.mp4
ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -f lavfi -i testsrc=duration=10:size=1280x720 -filter_complex 'hwupload, crop=355:355:402:282:exact=1,scale_vaapi=format=nv12:w=355:h=355' -c:v h264_vaapi -loglevel 80 cropped_oddsize_evenshift.mp4

I’ll create a mesa bug with as much info as I can add. I’ll link it here when I do. It would be fantastic if you could subscribe to the issue to respond if mesa developers have questions/patches to test as I don’t have the hardware to test this.

I guess I can add a --my-driver-is-buggy-with-odd-dimensions flag…but exact=0 is already a workaround to a ffmpeg bug. see #26

Right, encode resolution will have to have the same aspect ratio as your input, it’s a pretty suboptimal solution as it adds scaling, but it was more of a debugging step–it seems it fixes the “always captures at origin” though. Did you try AMD_DEBUG=noefc?

If you wanted to use --encode-resolution, you’d want to script it. But again, it’s not a real fix.

Like wl-screenrec -g "103,103 511x511" --encode-resolution "1000x1000"

Also would be interesting to see if setting AMD_DEBUG=noefc works around it…

This fixes it for me, not sure why though:

diff --git a/src/main.rs b/src/main.rs
index 3bcf3a1..4fdd307 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -1634,7 +1634,7 @@ fn video_filter(
         .input("out", 0)
         .unwrap()
         .parse(&format!(
-            "crop={roi_w}:{roi_h}:{roi_x}:{roi_y}:exact=1,scale_vaapi=format={output_real_pixfmt_name}:w={enc_w}:h={enc_h}{}",
+            "crop={roi_w}:{roi_h}:{roi_x}:{roi_y}:exact=0,scale_vaapi=format={output_real_pixfmt_name}:w={enc_w}:h={enc_h}{}",
             if let EncodePixelFormat::Vaapi(_) = pix_fmt {
                 ""
             } else {

Tested on 772b9a1a600ff681fe912c99d21106449a7d089b using cargo run -- -g "1375,814 1091x590"