[BUG] The video is glitched, looks like checkerboard pattern

[dec05eba]

Describe the bug The video is glitched when recording on wayland

To Reproduce gpu-screen-recorder -w screen -f 60 -o video.mp4

Expected behavior The video shouldn't look glitched

Screenshots

Desktop (please complete the following information):

• X11 or Wayland: Wayland
  • Desktop environment/Window Manager: Gnome
• Distro: Arch Linux
• GPU: Intel Iris Xe Graphics G7
• Version: aur

Additional context Terminal output:

[hevc_vaapi @ 0x6239a97bb380] ignoring invalid SAR: 0/0
[hevc_vaapi @ 0x6239a97bb380] Driver does not support some wanted packed headers (wanted 0xd, found 0x1).
Info: using hevc encoder because a codec was not specified
gsr info: gsr_kms_client_init: waiting for server to connect
kms server info: connecting to the client
gsr info: gsr_kms_client_init: server connected
gsr info: replacing file-backed unix domain socket with socketpair
kms server info: connected to the client
gsr info: using socketpair
[hevc_vaapi @ 0x6239a97bb380] ignoring invalid SAR: 0/0
[hevc_vaapi @ 0x6239a97bb380] Driver does not support some wanted packed headers (wanted 0xd, found 0x1).
update fps: 247
update fps: 247

drm_info output: drm_info.log

• [x] I played the video with the command mpv --no-config video.mp4 (if applicable)
• [ ] I use a laptop with integrated GPU and dedicated GPU

[DatCaptainHorse]

-w screen -f 60 -c mkv -k av1 -o "output.mkv" since it doesn't detect H.264 or H.265 under openSUSE, also..

That patch did it :eyes: (the previous patch is also still applied, I'll try without first patch as well, just a moment..)

Update: Only that 2nd patch is needed, first patch is not!

[dec05eba]

Ohh ok thanks.. Can you also tell me the terminal output? that contains the modifier value so I can see what it was

[DatCaptainHorse]

Here you go!

gsr info: gsr_kms_client_init: waiting for server to connect
kms server info: connecting to the client
gsr info: gsr_kms_client_init: server connected
gsr info: replacing file-backed unix domain socket with socketpair
kms server info: connected to the client
gsr info: using socketpair
modifier: 72057594037927945
modifier: 72057594037927945

[dec05eba]

Oh I see... thanks. Can you try if this works on wayland as well? using both patches and then with only the second one

[DatCaptainHorse]

Wayland:

• Only 2nd patch: No
• With both patches: :tada: WORKS :tada:

[dec05eba]

Kiitos! now i'll just have to figure out when its ok to do this. On some intel systems it produces a black video output if you do that. I think i'll be able to test that on my iGPU :)

[DatCaptainHorse]

Ole hyvä! I'll apply the patches for my intel-flavored Nestri image so I can test with the older iGPU on my server :+1:

[DatCaptainHorse]

Hm, I guess due to my server having NVIDIA GPU + Intel iGPU it complains with the error - Error: no /dev/dri/cardX device found. ?

I tried with sudo as well, but this'd be separate issue from this one. I also tried to patch in -device argument support, however despite me defining /dev/dri/card1 it throws same error. (Patch is attached incase that's of any interest) deviceselection.txt

[quazar-omega]

Awesome progress on this! Thank you both

[dec05eba]

I pushed the fix to git @quyse can you try building gpu screen recorder from source and see if it works now? my guess is no but I want to see what it looks like now. git clone https://repo.dec05eba.com/gpu-screen-recorder and run sudo ./install.sh

[dec05eba]

@DatCaptainHorse can you run sudo drm_info > log.log on that system and upload that log file? also does it work with ffmpeg instead? I haven't seen anybody else have that error before so it might be specific to the virtualized docker setup or something else with the setup

[quyse]

@dec05eba Sure, pulled latest changes and built, still records black screen + mouse pointer.

[DatCaptainHorse]

@dec05eba yeah I guess I'd need a dummy plug / display connected for it to work with current setup, though I'll take a look at other headless docker projects on how they might've solved it.

Anyhow, here's the outputs:

[AVHWDeviceContext @ 0x55b879a6bf00] Opened DRM device /dev/dri/card1: driver i915 version 1.6.0.
[kmsgrab @ 0x55b879a6c0c0] No usable planes found.
[in#0 @ 0x55b879a6bfc0] Error opening input: Invalid argument
Error opening input file -.
Error opening input files: Invalid argument

drminfoserver.log

[dec05eba]

@DatCaptainHorse yes i can see from the log that thats the issue. Even if gpu screen recorder didn't give that error there it would fail later since it would say that the monitor you are trying to capture doesn't exist (and "screen" is just an alias for the first monitor of the available connected monitors). I made a change now to allow capturing a window on x11 without having a monitor connected, so that can be used as a solution as well (untested).

[DatCaptainHorse]

Having no luck with X11 when it's headless, but as the patches fixed a wayland issue, I'm trying to see if I can make that work (at least I hope wl would be more flexible.. well see..)

[dec05eba]

Maybe its better to discuss it here instead: https://github.com/nestriness/nestri/issues/68 or https://github.com/nestriness/nestri/discussions/54 as it's not related specifically to gpu screen recorder but for setup with nestri (and maybe somebody there knows how to setup amd/intel x11 headless properly).

And btw, the fix for intel arc has already been pushed to git so if you pull the latest commit then you wont need the patches.

[guiodic]

with newer version I have black screen with only mouse cursor (Intel Tiger lake, X11)

[dec05eba]

@guiodic but it didn't work before either right? as you got the glitched output. Or do you also get a black screen when you record a single window (which worked for you before)? (getting a black screen now is expected if you got glitched output before).

[guiodic]

@guiodic but it didn't work before either right? as you got the glitched output.

yes, before it was glitched, now is black.

Or do you also get a black screen when you record a single window (which worked for you before)?

Window recording is still ok

[dec05eba]

I added the option to record with desktop portal (pipewire) now on wayland that should be a workaround for this. It's still experimental so it hasn't been tested a lot. This option is only available at the moment when installing gpu screen recorder from source or from aur and you use it by running gpu screen recorder with the -w portal option. The option hasn't been added to the gui yet.

[quyse]

Tried the current master, now it records correct video for me with -w portal on Intel Graphics and Wayland, cool!

[dec05eba]

For record, which wayland compositor did you record on? so I know which ones it works on

[quyse]

For record, which wayland compositor did you record on? so I know which ones it works on

I use Sway

[dec05eba]

Oh, I didn't even know that sway supported the screencast desktop portal. Good to know.

[quyse]

Oh, I didn't even know that sway supported the screencast desktop portal. Good to know.

BTW it requires clicking on a display to start capturing, but it does not show any dialog popup. It just waits for you to click, without displaying any prompt or hint to a user. It's not just gpu-screen-recorder, websites using Screen Capture web API behave the same way with Firefox. Sway displays almost zero UI of its own, so it's probably working as intended, or maybe their implementation is kind of a stub at the moment. Just not very obvious for a user.

[Nama]

Oh, I didn't even know that sway supported the screencast desktop portal. Good to know.

Pretty sure I wrote you an email that it works looooong while ago :D

Portal needs to be used interactively right? So in scripting (with gamemode) we cant use it.

[guiodic]

in Plasma X11 it doesn't work

gpu-screen-recorder -w portal -f 60 -o video.mp4 Info: using h264 encoder because a codec was not specified [h264_vaapi @ 0x63209b1eac00] ignoring invalid SAR: 0/0 gsr info: gsr_capture_portal_setup_dbus: CreateSession gsr error: gsr_dbus_call_screencast_method: response message is not an object path or unix fd gsr error: gsr_capture_portal_setup_dbus: CreateSession failed gsr error: gsr_capture_start failed

[dec05eba]

@guiodic plasma x11 doesn't support desktop portal. Desktop portal in general is only supported on wayland. I added a better error message about that (not uploaded to aur yet).

[dec05eba]

@Nama All of the wayland compositors I tested (including sway now) support session tokens, which means you can save the capture option and the next time you start gpu screen recorder it will record without showing a prompt. But this token is only used if you run gpu screen recorder with the -restore-portal-session yes option. But yes, you cant program the capture option with portal, it has to be selected by the user once in the prompt.

[dec05eba]

I made some changes in how capture works which might fix this issue, @guiodic can you (or anyone else that had this issue) try the latest version from source or aur ? try gpu-screen-recorder -w screen -f 60 -o video.mp4 (on x11 and wayland) and also gpu-screen-recorder -w portal -f 60 -o video.mp4 (this portal option only works on wayland). Thanks