Closed notpeelz closed 1 month ago
What compositor are you on? This works well for me and others.
Currently using Hyprland (0.33.1). GPU: AMD Radeon RX 6900 XT GPU driver: amdgpu (in-tree kernel driver) kernel: 6.6.7-arch1-1 mesa: 23.3.1
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"
Gah! That exact=1 is a workaround to an ffmpeg bug and I thought it was harmless. See https://github.com/russelltg/wl-screenrec/issues/26 for the history there.
Does it work if both location and size are even?
Yeah uh... about that... now I'm even more confused :rofl:
exact=0
:cargo run -- -g "1370,814 1091x590"
: works
cargo run -- -g "1371,814 1091x590"
: works
cargo run -- -g "1372,814 1091x590"
: works
cargo run -- -g "1370,814 1090x590"
: doesn't work
cargo run -- -g "1371,814 1090x590"
: doesn't work
cargo run -- -g "1372,814 1090x590"
: doesn't work
exact=1
:cargo run -- -g "1370,814 1091x590"
: doesn't work
cargo run -- -g "1371,814 1091x590"
: doesn't work
cargo run -- -g "1372,814 1091x590"
: doesn't work
cargo run -- -g "1370,814 1090x590"
: doesn't work
cargo run -- -g "1371,814 1090x590"
: doesn't work
cargo run -- -g "1372,814 1090x590"
: doesn't work
Can confirm that changing it to exact=0
makes it behave as expected.
@ThatOneCalculator can I get your vainfo
output
Trying display: wayland
vainfo: VA-API version: 1.20 (libva 2.20.1)
vainfo: Driver version: Mesa Gallium driver 23.3.2-arch1.2.1 for AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 16.0.6, DRM 3.54, 6.6.11-zen3-xanmod1-1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Also, here's my drm_info
(more verbose)
And my ffmpeg -version
for good measure:
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 13.2.1 (GCC) 20230801
configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan
libavutil 58. 29.100 / 58. 29.100
libavcodec 60. 31.102 / 60. 31.102
libavformat 60. 16.100 / 60. 16.100
libavdevice 60. 3.100 / 60. 3.100
libavfilter 9. 12.100 / 9. 12.100
libswscale 7. 5.100 / 7. 5.100
libswresample 4. 12.100 / 4. 12.100
libpostproc 57. 3.100 / 57. 3.100
Do you get any extra output if you set AMDGPU_SIVPE_LOG_LEVEL=3
env var with wl-screenrec? If so the output would be helpful. As I indicated in the other issue, I think this is a driver bug.
EDIT: would be good to get it with an odd x,y and exact=1 (a not working case) and a working case (either even x,y OR exact=0)
Also, it would be fantastic if you could test against mesa main
branch to make sure it's still broken there
From the version that is patched with exact=0
:
$ AMDGPU_SIVPE_LOG_LEVEL=3 wl-screenrec -g "$(slurp)" --low-power=off
Using output DP-1
Opening libva device from DRM device /dev/dri/renderD128
[h264_vaapi @ 0x56328e30cb00] Driver does not support some wanted packed headers (wanted 0xd, found 0x1).
138 fps
143 fps
144 fps
Do you want output from the stock version?
No, clearly I'm looking in the wrong place :)
Does it repro if you set --encode-resolution
to some value that's not equal to the region size (keep aspect ratio tho)
Also would be interesting to see if setting AMD_DEBUG=noefc
works around it...
Does it repro if you set
--encode-resolution
to some value that's not equal to the region size (keep aspect ratio tho)
Could you give me an example?
Like wl-screenrec -g "103,103 511x511" --encode-resolution "1000x1000"
Do you want that with the exact=0
or exact=1
version?
Here's the result with the exact=1
version:
https://github.com/russelltg/wl-screenrec/assets/44733677/4906d1c5-8c73-492e-b0b5-961b633e0f14
And here's what my whole screen looks like:
I believe you're saying that --encode-resolution does indeed workaround the issue?
I guess? I'm not sure how I'd be using it day-to-day where I just use "$(slurp)" for -g
Since it does do this with wl-screenrec -g "$(slurp)" --encode-resolution "1000x1000" --low-power=off
and selecting a non-square region:
https://github.com/russelltg/wl-screenrec/assets/44733677/f83bbea0-797c-481a-bbc5-2b7fecdc154a
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.
Going to stop digging on this until you can test against latest mesa. Built it, then pass LIBVA_DRIVERS_PATH
to the path of radeonsi_drv_video.so
.
There's been a lot of changes recently in this path, notably around using this EFC (Encoder Format Conversion) hardware to do the pixel format conversion on dedicated hardware. It's possible mesa needs to fallback to converting in a shader if the origin or size (I'm still unclear on which is problematic...) is odd.
I can try again in a bit. Would you recommend I build mesa from source? I'm just using the version in the Arch repos.
But also, exact=0 works totally as expected so I think maybe it should just be set back to that....
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
That'd work, but I think a less.... "verbose" flag would be good. Flashbacks to sway+Nvidia lol
Can you send me the output files and stdout/err of both
ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -f lavfi -i testsrc=duration=10:size=1280x720 -filter_complex 'hwupload, crop=355:355:401:281:exact=1,scale_vaapi=format=nv12:w=355:h=355' -c:v h264_vaapi -loglevel 80 cropped_shift.mp4
and
ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -f lavfi -i testsrc=duration=10:size=1280x720 -filter_complex 'hwupload, crop=355:355:0:0:exact=1,scale_vaapi=format=nv12:w=355:h=355' -c:v h264_vaapi -loglevel 80 cropped_noshift.mp4
Thanks, I also want the output files (cropped_noshift.mp4, cropped_shift.mp4)
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.
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!
If somebody could test and confirm the fix, that would be fantastic. Requires building mesa, so only for those that are comfy.
I'd try, but i can't clone the mesa repo.
remote: Enumerating objects: 1743303, done.
remote: Counting objects: 100% (1390/1390), done.
remote: Compressing objects: 100% (558/558), done.
client_loop: send disconnect: Broken pipe9.21 MiB | 1.08 MiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
:-(
Edit: fixed. will see if i can build.
Ok, i've managed to build it and can confirm: the fix works.
Hm, by now the fix should be in latest mesa, right? I think it is... but weirdly enough the problem isn't fixed for me. When i tried the fix back then it was...
What mesa version are you running?
Mesa 24.0 doesn't have the commit (see the 24.0 branch)
This seems to be fixed with the latest mesa release. finally.
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)