[BUG] Screen recording resolution calculation

porridgewithraisins commented 2 weeks ago

Describe the bug Hi, you might recognise me from the emails where I implemented the beginnings of region capture for x11/intel.

Context

I don't know if I am using the right terms here, so bear with me. I have a laptop, where I want to have fractional scaling. And you know the story of that on linux. The solution I use (and it works well) is setting xfce window manager zoom to 2x, and then scale the display to 1.6x. What this seems to do is render the desktop to a larger canvas, but the windows on that canvas are all 2x'd. So this ends up giving a good result. I have to set GDK_SCALE_whatever and QT_whatever also.

Old behaviour

In this setup, gpu-screen-recorder used to give me proper results. For example, this video from april 2023. I had the same desktop scaling setup back then as well (I think, because I don't remember changing anything). And it recorded fine, as you can see in the video, at 1920x1200 resolution (my screen resolution).

New behaviour

Now, the videos I record look like this. What could be the reason? Now, it records at the 1.6x scaled 3072x1920 resolution.

Command ran gpu-screen-recorder -w screen -f 60 -o /tmp/lol.mp4

Desktop (please complete the following information):

X11 or Wayland: X11
- Desktop environment/Window Manager: xfce, xfwm4 4.18.0-3
Distro: Arch
GPU: AMD Ryzen 5 3600 Integrated GPU
Version (latest flatpak version, aur or source): AUR, happens with source as well.

Additional context drm-info.txt.

dec05eba commented 2 weeks ago

Hmm thats weird. Can you run xrandr and post the output?

porridgewithraisins commented 2 weeks ago

Xrandr says 3072x1920...

sandy [~] $ xrandr
Screen 0: minimum 320 x 200, current 3072 x 1920, maximum 16384 x 16384
eDP connected 3072x1920+0+0 (normal left inverted right x axis y axis) 286mm x 178mm
   1920x1200     60.03*+  40.02  
   1920x1080     60.03  
   1600x1200     60.03  
   1680x1050     60.03  
   1280x1024     60.03  
   1440x900      60.03  
   1280x800      60.03  
   1280x720      60.03  
   1024x768      60.03  
   800x600       60.03  
   640x480       60.03  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)

Additional investigation, there doesn't seem to be a problem with your code, I overrode crt_info->width and crt_info->height in for_each_active_monitor_output_x11_not_cached and it seems to work fine now. And I checked the commits in that file, it seems like this app has always just called Xrandr library function the same way and not done anything funky.

So, I am not sure why the behaviour changed. That part of xrandr code hasn't seen changes in years, again going by the commits in the corresponding files in libxrandr. So I must be missing something. I also don't remember what xrandr used to return unfortunately...

What's the way I can fix this?

dec05eba commented 2 weeks ago

One part did change long ago. Its needed for proper monitor handling on x11, for example with rotated monitors. I can see if i can maybe try and fix it. When you said scaling the display, did you mean using xrandr --output DP-1 --scale 1.6 for example?

porridgewithraisins commented 2 weeks ago

I did it in the xfce display settings, but now I turned that back to 1x and did it with your xrandr command, and it seems to do the same thing. So yes.

Also, curious, what changed in that rotation handling code? From what I saw, it doesn't do anything on x11?

/* Monitor size is already rotated on x11 when the monitor is rotated, no need to apply it ourselves */

dec05eba commented 2 weeks ago

Ah ok no I remembered wrong. I checked git history and it has to do with capturing external monitor on laptops with dedicated nvidia gpu on x11. The external monitor info wont be available in the drm info output (as seen when running the drm_info command) for the monitor connected to the nvidia gpu (the hdmi slot), as nvidia doesn't use linux drm api on x11. So you have to query that information from x11 instead to be able to capture the external monitor on such systems (my laptop has this setup). This is when trying to capture the external monitor with the iGPU (intel), when the external monitor is connected to the dedicated nvidia gpu.

Anyways, I pushed a fix for this issue. Can you update to the latest aur version and test again? Note that If you try to capture a window instead then it will capture at a scaled size, although it wont have black bars on the side like in the video you posted. There isn't really anything to do about that, the window texture itself is that size so its correct.

porridgewithraisins commented 2 weeks ago

Yes, I ran a git pull, built it and all seems well.

About the full screen window thing: You're right that it records at a higher resolution, but when I send it on e.g whatsapp, or open it in VLC, the black bars don't appear, so that's fine by me, I guess I down-scale the video after the fact whenever file size matters to me, although that does require a re-encode as I understand it. Can you tell me how the bars disappeared BTW?

Also, do you think it makes sense to have the downscaling feature in this app itself? Or in general (a subset of) ffmpeg "output filters"? My favorite windows screen recorder ShareX had that feature. I understand if it's too complex because, IIRC, sharex simply shelled out to ffmpeg

dec05eba commented 2 weeks ago

Thanks for testing!

The black bars when recording the monitor appeared because it said the monitor size was 3072x1920 but the framebuffer captured itself was 1920x1200 so it just displayed it in the center of the video (thats how gpu screen recorder behaves). When capturing a window the window texture itself is that larger size so gpu screen recorder records that, so the video size matches the window texture size so there aren't any black bars.

The reason why the monitor framebuffer isn't larger than 1920x1200 but the window is is because when you scale the output in x11 x11 will scale every window, but when it finally displays it on the screen it will downscale it to the monitors real resolution and display that. gpu screen recorder captures that final framebuffer when you record the monitor.

Also, do you think it makes sense to have the downscaling feature in this app itself?

Thats a feature that was added very recently :) . Use the -s option, for example -s 1920x1080. Before this option was only for focused window to set the size, but now it sets the video resolution and scales the captured content to that video resolution. (This option sets the max video resolution, the resolution in any axis can be different because it respects the aspect ratio of the captured content). Note that scaling with -s might not give the best quality as its a very fast scaling option right now (free opengl texture scaling). But it seemed to work nicely when scaling the monitor with x11 like that and capturing a window and then downscaling it.

ffmpeg output filters likely wont be supported as I dont think they can work here properly. But I intend to someday add plugin support in which case you can manipulate the output or add additional graphics to the output.

porridgewithraisins commented 2 weeks ago

Great, thanks for the quick resolution. Upgraded to latest gpu-screen-recorder, -gtk as well. Everything works fine.

dec05eba / gpu-screen-recorder-issues