[BUG] Framerate mode "constant" results in stuttering video export on Ubuntu

[Sturmlocke86]

Describe the bug
Not sure if this is a bug or not, seeking help here. Video framerate is stuttering and unstable in certain games when using "constant" framerate for recording. I require constant framerate for video editing post recording. Some games run just fine, others are stuttering at 1 fps. Tested with both Steam + Proton as Flatpak and Snap on Ubuntu 23.10 and 22.04.

Example stuttering video: Alien Isolation, Everquest 2

Example fluid 60 fps video: Turok 2 PC remaster, Aliens vs Predator 1, Crazy Taxi

To Reproduce

See attached screenshot: I tried lowering the video quality settings to medium, changing the codec from H265 to H264, and dropping the resolution of the game to lower levels. I usually record at 4k60 resolution, but lower resolutions have the same issue. Lowering the graphics in-game to the lowest setting doesn't help the issue either.

• Install Ubuntu 22.04 or 23.10
• Install Steam Snap or Flatpak
• Enable Proton 8 or Experimental
• Nvidia Powermizer is set to prefer max performance
• CPU energy profile is set to max cpu performance
• Launch Alien Isolation or Everquest 2 via Steam
• Launch gpu screen recorder with the recommended settings
• Record video and quit game
• Playback video with VLC or MPV player and observe the stuttering video with low framerate
• Also tried with gamemoderun %command% on and off

Expected behavior
I expect the video to run at buttery smooth 60 fps.

Screenshots
See screenshots and video examples attached to this report.

Desktop (please complete the following information):

• X11 or Wayland: X11
• Desktop environment/Window Manager: Gnome 46
• Distro: Ubuntu 24.04 but also tested with 23.10
• GPU: Nvidia RTX A2000
• Nvidia driver version: 535.171.04 (tested and recommended by Ubuntu's driver tool)
• Version: latest flatpak version of gpu screen rec

Additional context

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 21:42:45.851: Failed to load module "canberra-gtk-module" Gtk-Message: 21:42:45.852: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388707 Warning: opus and flac audio codecs are temporary disabled, using aac audio codec instead [hevc_nvenc @ 0x603820a9c280] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x603820a9c280] ignoring invalid SAR: 0/0 update fps: 239 update fps: 77 update fps: 27 update fps: 17 update fps: 13 update fps: 10 update fps: 10 update fps: 9 update fps: 7 update fps: 6 update fps: 5 update fps: 4 update fps: 4 update fps: 5 update fps: 4 update fps: 4 update fps: 3 update fps: 3 update fps: 3 update fps: 3 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 1 update fps: 2 update fps: 2 update fps: 2 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1 Notification: title: GPU Screen Recorder, body: The recording was saved to /home/sturmlocke/Videos/GPU Screen Rec/Video_2024-04-26_21-44-12.mp4

I have been recording on openSUSE Leap 15.5 with another PC that is identical to this one hardware-wise, and have not experienced these issues on openSUSE (recording with the exact same settings with constant framerate mode produces 60 fps smooth videos on Suse). On Ubuntu, recording anything outside of Steam and Proton runs just fine. I have tried recording standalone Flatpak and Snap games, such as Xonotic, and the video is super smooth at 60 fps. Worth mentioning: I've noticed that the Nvidia video engine is often at 90-100% load for the videos recorded where it's stuttering badly. In other words, 90-100% load during recording. No fps-drops in gameplay, only the video stutters post recording.

Tested with MPV player, VLC and Gnome Video player. Importing the video into Shotcut or Kdenlive video editior shows the same stuttering picture.

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

Feel free to ask for more infos, will gladly provide more feedback.

Video_2024-04-26_22-42-38.mp4

[Sturmlocke86]

Reuploading the video because it's not showing the video in the bug report above (only the audio can be heard). Here is the video in .zip.

Video_2024-04-26_22-42-38-constantfps.zip

[dec05eba]

I usually record at 4k60 resolution

Is that for the game resolution or screen resolution? are you recording at 4k60fps on the opensuse system too? the game resolution doesn't matter, only the system resolution does.
If you record with variable framerate mode what does it output in the terminal? (the update fps message), when recording the game that causes that video lag

[dec05eba]

other than that, you can try if updating your nvidia driver to the same version as the one used in opensuse (or just the latest version that ubuntu allows in the driver menu) to see if that fixes it (remember to run flatpak update after that and reboot as well, as flatpak driver version also needs to match the system nvidia driver version).
Also when did you record on opensuse? are you using the same gpu screen recorder version on both? if there has been a gpu screen recorder update since then then you can try install an older version of gpu screen recorder (I can find the version if you tell me a date).

[Sturmlocke86]

I usually record at 4k60 resolution

Is that for the game resolution or screen resolution? are you recording at 4k60fps on the opensuse system too? the game resolution doesn't matter, only the system resolution does. If you record with variable framerate mode what does it output in the terminal? (the update fps message), when recording the game that causes that video lag

It's both the game and screen resolution. It's a 4k60 Samsung monitor and I have all games set to the native 4k60 reso of the monitor. Yes, it's the same reso for openSUSE too. Will try to record Alien Isolation with variable framerate right now and will post the terminal results for you. Be right back!

[Sturmlocke86]

other than that, you can try if updating your nvidia driver to the same version as the one used in opensuse (or just the latest version that ubuntu allows in the driver menu) to see if that fixes it (remember to run flatpak update after that and reboot as well, as flatpak driver version also needs to match the system nvidia driver version). Also when did you record on opensuse? if there has been a gpu screen recorder update since then then you can try install an older version of gpu screen recorder (I can find the version if you tell me a date).

Yeah, I was thinking about doing that, but Ubuntu doesn't offer any of the new drivers via its driver tool due to some outstanding bugs in 23.10 and 24.04: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/2062967

Right now V535 is the newest driver that Ubuntu offers in 24.04 lts via its driver tool.

I would have to add the community PPA for newer drivers, but I am very hesitant of doing so because I have experienced serious issues with stability by using anything other than the "tested" and "recommended" Ubuntu driver. Last time I used an "untested" driver, system updates nuked the Ubuntu system, rendering it unbootable (recovery was necessary). This is actually a point where openSUSE does it much more stable and reliable tbh.

Good question, iirc the last video that I recorded on openSUSE was approx 3-4 weeks ago, see here for performance: https://youtu.be/nXboAhXmZlE?si=lfijWpEjM3geBn2E

Pretty sure that was on the openSUSE machine. But to be 100% certain, we could go back as far as two months, because that's when I recorded this video here: https://youtu.be/df-xd067L_Y?si=Qf7vgibLJbKERsVq&t=92

In both cases, I recorded at 4k60 game and screen resolution, which you can see because the quality of the videos is really good (make sure to select 4k reso in the Youtube player). I haven't tested DCUO on Ubuntu 24.04 yet, but I will give it a whirl right now together with Alien Isolation. Brb.

[dec05eba]

the video description in those videos say that you recorded with obs studio. Is that just incorrect information or was it recorded with obs studio?

[Sturmlocke86]

the video description in those videos say that you recorded with obs studio. Is that just incorrect information or was it recorded with obs studio?

It's incorrect information because I copy and paste some of the descriptions from previous videos to save time. Totally forgot to add gpu screen record, but I did at it at the end of the 1h long dcuo video during the credit screen roll at the very end (software used for the video). Thx for pointing that out! Will correct that soon. I was using obs for the longest time, but had to switch because of audio hiccups with it. Also, obs struggles to do 4k60 with the simple preset settings, and then I found your app, which was doing really well at 4k60 as you can see in the videos on yt.

Here's the output from Alien Isolation with variable framerate mode:

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 23:48:34.392: Failed to load module "canberra-gtk-module" Gtk-Message: 23:48:34.393: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388623 Warning: opus and flac audio codecs are temporary disabled, using aac audio codec instead [hevc_nvenc @ 0x5e067fe39fc0] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x5e067fe39fc0] ignoring invalid SAR: 0/0 update fps: 138 update fps: 57 update fps: 57 update fps: 57 update fps: 59 update fps: 56 update fps: 56 update fps: 56 update fps: 53 update fps: 50 update fps: 52 update fps: 176 update fps: 51 update fps: 49 update fps: 52 update fps: 54 update fps: 53 update fps: 54 update fps: 53 update fps: 52 update fps: 54 update fps: 57 update fps: 58 update fps: 57 update fps: 154 update fps: 113 update fps: 56 update fps: 54 update fps: 53 update fps: 52 update fps: 53 update fps: 54 update fps: 55 update fps: 55 update fps: 54 update fps: 53 update fps: 51 update fps: 51 update fps: 54 update fps: 111 update fps: 246 update fps: 207 update fps: 54 update fps: 57 update fps: 46 update fps: 43 update fps: 46 update fps: 42 update fps: 35 update fps: 34 update fps: 42 update fps: 44 update fps: 46 update fps: 44 update fps: 42 update fps: 47 update fps: 47 update fps: 45 update fps: 41 update fps: 39 update fps: 46 update fps: 39 update fps: 44 update fps: 48 update fps: 43 update fps: 43 update fps: 45 update fps: 44 update fps: 51 update fps: 45 update fps: 47 update fps: 48 update fps: 47 update fps: 46 update fps: 42 update fps: 45 update fps: 47 update fps: 57 update fps: 48 update fps: 44 update fps: 42 update fps: 47 update fps: 47 update fps: 44 update fps: 42 update fps: 47 update fps: 46 update fps: 47 update fps: 45 update fps: 43 update fps: 43 update fps: 48 update fps: 50 update fps: 48 update fps: 49 update fps: 41 update fps: 47 update fps: 44 update fps: 46 update fps: 44 update fps: 39 update fps: 42 update fps: 45 update fps: 40 update fps: 40 update fps: 42 update fps: 44 update fps: 44 update fps: 42 update fps: 42 update fps: 39 update fps: 44 update fps: 47 update fps: 42 Notification: title: GPU Screen Recorder, body: The recording was saved to /home/sturmlocke/Videos/GPU Screen Rec/Video_2024-04-26_23-49-04.mp4

This is running around for one or two minutes. Fps is all over the place. In-game though it's buttery smooth 60fps. Dcuo is next. Will try constant fps and see what happens. brb

[dec05eba]

no need to try constant fps, it will be bad. That update fps means that either you gpu simply cant encode video fast enough or opengl fps in gpu screen recorder gets limited for whatever reason. If it works in opensuse but not ubuntu then it might really be an issue in the nvidia driver that might get fixed by an update.

[dec05eba]

One thing you can try doing is record the monitor instead of window, and only have one monitor connected.
If that doesn't change anything you can try downgrading gpu screen recorder by running: flatpak update --commit=f352ca2bdc926b74e0a1bf3ecaf4909bef38adc1e1914f5732dc1ed430527b8c com.dec05eba.gpu_screen_recorder (2 month old version) to see if it changes anything? run with variable framerate mode with this version as well and post the terminal output.
If this doesn't change anything then you can try installing gpu screen recorder from source. There is a small difference if you use the non-flatpak version.

[Sturmlocke86]

Ok, can't login to dcuo right now. Not sure why, will check later. Will try downgrading gpu screen rec right now. brb

[dec05eba]

Ok, can't login to dcuo right now. Not sure why, will check later. Will try downgrading gpu screen rec right now. brb

testing with alien isolation only should be fine, that variable framerate terminal output from alien isolation tells me everything I need to know. But can you try recording your monitor first (instead of window) before you downgrade? and only have one monitor connected

[Sturmlocke86]

One thing you can try doing is record the monitor instead of window, and only have one monitor connected. If that doesn't change anything you can try downgrading gpu screen recorder by running: flatpak update --commit=f352ca2bdc926b74e0a1bf3ecaf4909bef38adc1e1914f5732dc1ed430527b8c com.dec05eba.gpu_screen_recorder (2 month old version) to see if it changes anything? run with variable framerate mode with this version as well and post the terminal output. If this doesn't change anything then you can try installing gpu screen recorder from source. There is a small difference if you use the non-flatpak version.

This worked! Downgrading to that version actually worked. Recording at very high settings + constant framerate mode at 4k60 reso = buttery smooth again. I'll record a short clip and show it to you right now. I recorded my window like I always do, worked like a charm this time.

[dec05eba]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

[Sturmlocke86]

One thing you can try doing is record the monitor instead of window, and only have one monitor connected. If that doesn't change anything you can try downgrading gpu screen recorder by running: flatpak update --commit=f352ca2bdc926b74e0a1bf3ecaf4909bef38adc1e1914f5732dc1ed430527b8c com.dec05eba.gpu_screen_recorder (2 month old version) to see if it changes anything? run with variable framerate mode with this version as well and post the terminal output. If this doesn't change anything then you can try installing gpu screen recorder from source. There is a small difference if you use the non-flatpak version.

This worked! Downgrading to that version actually worked. Recording at very high settings + constant framerate mode at 4k60 reso = buttery smooth again. I'll record a short clip and show it to you right now. I recorded my window like I always do, worked like a charm this time.

Quoting myself here. This is the video when using this comment of yours. Works great! See attached zip.

Video_2024-04-27_00-32-34-constant.zip

[Sturmlocke86]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Sure, will test and report in a few minutes. brb

ps: do I have to reboot the computer after switching versions?

[dec05eba]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Sure, will test and report in a few minutes. brb

ps: do I have to reboot the computer after switching versions?

no

[Sturmlocke86]

But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Want me to test recording the monitor with the current version before using the new commit or after I switch to the new version that you posted?

[dec05eba]

But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Want me to test recording the monitor with the current version before using the new commit or after I switch to the new version that you posted?

update to that version and record with variable framerate and record window like you do now and post the terminal output. If it shows 50~ fps instead of 247~ something then try with recording your monitor instead

[dec05eba]

but also I wanted to see the terminal output when you captured in that working version, when recording with variable framerate. It's important even if it's working. Also you dont have to record for minutes, you can just alt-tab the game, change gpu screen recorder version, alt tab back to game and record ~10 seconds

[Sturmlocke86]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Ok, tested this commit here and the issue is back. Constant framerate mode is stuttering and even though variable framerate mode is a bit more stable now, fps is still very low compared to the in-game fps. Variable mode: in-game 60fps and the recorded video is worse. Logs:

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 00:48:01.032: Failed to load module "canberra-gtk-module" Gtk-Message: 00:48:01.033: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388671 [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 update fps: 72 update fps: 43 update fps: 44 update fps: 42 update fps: 43 update fps: 43 update fps: 42 update fps: 42 update fps: 43 update fps: 43 update fps: 44 update fps: 44 update fps: 43 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 45 update fps: 43 update fps: 42 update fps: 41 update fps: 42 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 48 update fps: 43 update fps: 41 update fps: 42 update fps: 42 update fps: 45 update fps: 44 update fps: 42 update fps: 45 update fps: 44 update fps: 41 update fps: 45 update fps: 45 update fps: 45 update fps: 43 update fps: 39 update fps: 48 update fps: 44 update fps: 46 update fps: 50 update fps: 54

It's not maintaining 60fps and you can tell it's not that smooth by watching the video. I also noticed how performance of the game degraded to what feels like 20 fps after hitting record and stop a couple of times. I had to quit the game and relaunch it for the performance to go back to normal to 60fps as it was before.

[Sturmlocke86]

but also I wanted to see the terminal output when you captured in that working version, when recording with variable framerate. It's important even if it's working. Also you dont have to record for minutes, you can just alt-tab the game, change gpu screen recorder version, alt tab back to game and record ~10 seconds

Ok, I can switch back to the working version and provide the logs for that. Brb

[dec05eba]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Ok, tested this commit here and the issue is back. Constant framerate mode is stuttering and even though variable framerate mode is a bit more stable now, fps is still very low compared to the in-game fps. Variable mode: in-game 60fps and the recorded video is worse. Logs:

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 00:48:01.032: Failed to load module "canberra-gtk-module" Gtk-Message: 00:48:01.033: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388671 [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 update fps: 72 update fps: 43 update fps: 44 update fps: 42 update fps: 43 update fps: 43 update fps: 42 update fps: 42 update fps: 43 update fps: 43 update fps: 44 update fps: 44 update fps: 43 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 45 update fps: 43 update fps: 42 update fps: 41 update fps: 42 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 48 update fps: 43 update fps: 41 update fps: 42 update fps: 42 update fps: 45 update fps: 44 update fps: 42 update fps: 45 update fps: 44 update fps: 41 update fps: 45 update fps: 45 update fps: 45 update fps: 43 update fps: 39 update fps: 48 update fps: 44 update fps: 46 update fps: 50 update fps: 54

It's not maintaining 60fps and you can tell it's not that smooth by watching the video. I also noticed how performance of the game degraded to what feels like 20 fps after hitting record and stop a couple of times. I had to quit the game and relaunch it for the performance to go back to normal to 60fps as it was before.

is that log when recording monitor?

[Sturmlocke86]

hmm damn ok, can you try flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder and record and see if that messes it up? that will give me the exact commit that made it worse. But also that makes it worse can you try recording your monitor instead of a single window to see if it also has performance issue? that will also help with debug

Ok, tested this commit here and the issue is back. Constant framerate mode is stuttering and even though variable framerate mode is a bit more stable now, fps is still very low compared to the in-game fps. Variable mode: in-game 60fps and the recorded video is worse. Logs:
flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 00:48:01.032: Failed to load module "canberra-gtk-module" Gtk-Message: 00:48:01.033: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388671 [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x63b8779f9180] ignoring invalid SAR: 0/0 update fps: 72 update fps: 43 update fps: 44 update fps: 42 update fps: 43 update fps: 43 update fps: 42 update fps: 42 update fps: 43 update fps: 43 update fps: 44 update fps: 44 update fps: 43 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 45 update fps: 43 update fps: 42 update fps: 41 update fps: 42 update fps: 44 update fps: 44 update fps: 44 update fps: 45 update fps: 42 update fps: 44 update fps: 45 update fps: 42 update fps: 43 update fps: 48 update fps: 43 update fps: 41 update fps: 42 update fps: 42 update fps: 45 update fps: 44 update fps: 42 update fps: 45 update fps: 44 update fps: 41 update fps: 45 update fps: 45 update fps: 45 update fps: 43 update fps: 39 update fps: 48 update fps: 44 update fps: 46 update fps: 50 update fps: 54
It's not maintaining 60fps and you can tell it's not that smooth by watching the video. I also noticed how performance of the game degraded to what feels like 20 fps after hitting record and stop a couple of times. I had to quit the game and relaunch it for the performance to go back to normal to 60fps as it was before.

is that log when recording monitor?

No, that's the log when recording the window. I can retry with the monitor if you want? Just recorded the variable framerate log for the working version. Will post in a second. brb

[Sturmlocke86]

This is the log for the working version with variable framerate and window selection in gpu screen rec:

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 01:02:24.002: Failed to load module "canberra-gtk-module" Gtk-Message: 01:02:24.003: Failed to load module "canberra-gtk-module" window name: Alien: Isolation, window id: 8388703 [hevc_nvenc @ 0x5b9edc98f6c0] ignoring invalid SAR: 0/0 Info: using hevc encoder because a codec was not specified [hevc_nvenc @ 0x5b9edc98f6c0] ignoring invalid SAR: 0/0 update fps: 244 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 246 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247 update fps: 247

The recorded video is buttery smooth with both variable and constant framerate mode with the working version of gpu screen rec. I can also tell that the file size it creates is actually bigger now.

[dec05eba]

Ok thanks, finally can you try recording variable framerate mode with this version: flatpak update --commit=09931552deea1e3d5087944b83a9a62fcd45e497b8d1ae8bf2a39651b997ca34 com.dec05eba.gpu_screen_recorder ? and post terminal output.

[Sturmlocke86]

Ok thanks, finally can you try recording variable framerate mode with this version: flatpak update --commit=09931552deea1e3d5087944b83a9a62fcd45e497b8d1ae8bf2a39651b997ca34 com.dec05eba.gpu_screen_recorder ? and post terminal output.

Ok, brb

[Sturmlocke86]

Ok thanks, finally can you try recording variable framerate mode with this version: flatpak update --commit=09931552deea1e3d5087944b83a9a62fcd45e497b8d1ae8bf2a39651b997ca34 com.dec05eba.gpu_screen_recorder ? and post terminal output.

Ok, the variable logs for this version:

flatpak run com.dec05eba.gpu_screen_recorder Gtk-Message: 01:13:10.380: Failed to load module "canberra-gtk-module" Gtk-Message: 01:13:10.381: Failed to load module "canberra-gtk-module" /home/sturmlocke Warning: Invalid config option: main.color_range limited Warning: Invalid config option: main.show_notifications true Warning: Invalid config option: record.pause_recording_hotkey 65509 0 window name: Alien: Isolation, window id: 8388711 [hevc_nvenc @ 0x5d01240a3480] ignoring invalid SAR: 0/0 Info: using h265 encoder because a codec was not specified [hevc_nvenc @ 0x5d01240a3480] ignoring invalid SAR: 0/0 update fps: 120 update fps: 46 update fps: 47 update fps: 45 update fps: 44 update fps: 47 update fps: 44 update fps: 48 update fps: 44 update fps: 43 update fps: 44 update fps: 47 update fps: 44 update fps: 53 update fps: 55 update fps: 56 update fps: 47 update fps: 47 update fps: 45 update fps: 42 update fps: 43 update fps: 41 update fps: 48 update fps: 48 update fps: 46 update fps: 48

The constant logs for this version:

[hevc_nvenc @ 0x61ac64f2d480] ignoring invalid SAR: 0/0 Info: using h265 encoder because a codec was not specified [hevc_nvenc @ 0x61ac64f2d480] ignoring invalid SAR: 0/0 update fps: 51 update fps: 5 update fps: 3 update fps: 3 update fps: 2 update fps: 2 update fps: 2 update fps: 2 update fps: 1 update fps: 1 update fps: 1 update fps: 1 update fps: 1

Both variable and constant video modes are not smooth in this version and video playback when recording in constant mode is back to stuttering like crazy.

[dec05eba]

ok thanks God, im pretty certain i know what the issue is then. Your gpu doesn't support p5 preset or the driver version you have is bugged. I'll change it to p4 (the same as in that working version). I'll post a command you can run to test that version after some time here. Thanks for testing!

[Sturmlocke86]

On mobile right now. Thanks a bunch for all the help! Your response time is incredible. Will test the final Flatpak in a couple of minutes. Btw, feel free to add me on Steam. You'll find my nick on my yt page 👍🏻🥂

[dec05eba]

It will take a few hours before flathub publishes it :p

[Sturmlocke86]

It will take a few hours before flathub publishes it :p

Thanks, I like how fast you work! Alrighty, I downloaded the new Flatpak and tested it with a few games: Turok 1,2,3, Alien Isolation, Everquest 2, Crazy Taxi, Need For Speed Most Wanted, Tomb Raider Underworld and a couple of other titles. I recorded each game around ten times for a couple of minutes. So far everything is looking good and nearly all games are super smooth now. The only game that I have seen get slowdowns now (1fps video) is Everquest 2. In EQ2 it happens after recording for about 50-70 minutes in very specific locations. It doesn't happen everywhere, only in certain locations / zones within EQ2 and thus far only after a while. This might just be a driver/proton issue though, or maybe the game itself since it switched to DirectX11 recently, but I will try to reproduce or trigger it and check the terminal logs for info. Will report back later tonight.

[dec05eba]

The thing is, it's not really a bug and it's not really related to the game itself. Your gpu is on the border of being able to handle 4k60fps recording and the things that can slow it down is complexity of the scene and the motion. That increase the work your gpu video encoding unit has to do. So even recording videos can cause it to happen. If the video encoding drops below the target fps of 60 fps it has to repeat encode the frames for constant framerate video (which is why variable framerate video is recommended). Since it encodes multiple times per frame the video encoding performance goes down even more and more until its at 1 fps.
The only thing I can do is to try change it so it doesn't get stuck at 1 fps at least.
There is a reason why nvidia shadowplay, xbox gamebar, etc use variable framerate video.

But when update fps goes down to 1 fps you can check nvtop to see system vram usage. Maybe there is a leak in gpu screen recorder and you see this issue when vram is almost full?

[Sturmlocke86]

Alrighty, I'm back. I have been testing a couple of games on and off with constant and variable framerate mode in gpu screen recorder. Yeah, what you said could actually be the case, sounds reasonable tbh. What bothers me about this though is that I have been recording a lot of 4k60 video content in the last couple of months, ever since switching to gpu screen rec, and I was not experiencing these single digit 1-fps frame drops at all, even when the game dipped below 60 fps in-game during some scenes. I went back and re-recorded some of the scenes that I had already done in EQ2 at 4k60 some time ago, for comparisons sake ofc, and now the exported video sometimes drop to 1-fps during the same scenes. It's the same spot, same scene, just with reproducible stuttery video now in constant video mode.

What's interesting here is that I can't seem to reproduce the same effect in other games. I have tried with around ten different games, some of which push the hardware even more than EQ2 (Alien Isolation, Cyberpunk, Terminator Resistance etc.), and the video export remains fluid even when the fps-rate dips below 60 in these games. For example, I tried Terminator: Resistance via Steam and Proton 8 and set everything to 4k60 reso + "epic" graphics preset in-game, and that gives me an fps-rate of approx 20-30fps without using its built-in AMD FSR feature (with FSR = rock solid 60fps btw). I recorded the game without FSR and the exported video was just fine. Sure, you can see that the game is not running at 60 fps, but it's identical to what I see on screen. So the game running at these settings = 20-30 fps and the video export doesn't drop to 1 fps. It pretty much looks the same as what I'm seeing live in-game. All of this in constant video mode.

This leads me to believe that it must be something else going on here. In EQ2 there are a few places where the fps-rate can drop below 60 fps when using 4k reso with all the bells and whistles enabled in-game, mostly when there is a ton of stuff happening on screen, and as soon as that happens the recorded video stutters at 1 fps again. All of this when using constant video mode in gpu screen recorder. I retested with variable framerate mode and was not able to reproduce the issue. So it would seem that it's strictly limited to constant video mode for this game.

I managed to catch it on video a couple of times if you want to take a look at it?

Since I was recording this just fine via constant video mode with the old version of screen rec from 2-3 months ago, I decided to retest with that version, but the same thing happens again in EQ2, and only in EQ2 thus far. So maybe it's something else? The only other thing that is different for this rig is:

• Ubuntu 24.04 instead of openSUSE Leap 15.5
• Currently testing with the Steam Snap
• Nvidia driver V535.X instead of V550.X
• Secureboot enabled for this machine
• Generally speaking: EQ2 went from DirectX9 to DirectX11 in a recent update and so now the game runs exclusively with DX11 api

Other than that, nothing else is different. So I might use a second hard drive with a fresh Ubuntu install and upgrade those Nvidia drivers and then I might retest without Snap and Flatpak Steam by using a natively installed version of vanilla Wine. Using variable framerate mode would be nice ofc, if I could. The only reason why I haven't been able to use it is because variable mode causes issues when importing video clips into the likes of Shotcut and Kdenlive etc. In their forums they recommend to use constant video mode for editing and exporting, or to alternatively convert a variable video to constant h264 for more stability etc. Problem with this is that if you don't convert from variable to constant, it can result in number of issues during and post video edit. Converting it to constant within Shotcut / Kdenlive has its own problems too though, because then you have to recheck the entire video for potential video and audio glitches that can happen after the conversion. On top of that, converting takes more time and reduces the video quality. All of this means editing the video takes a ton more time and gets far more complicated. Here are a few examples of this topic:

• https://forum.shotcut.org/t/variable-frame-rate-message-after-i-put-the-video-on-the-timeline/34860/3

• https://forum.shotcut.org/t/4-k-recording-from-iphone-this-file-is-variable-frame-rate/32544/14

• https://forum.shotcut.org/t/vfr-footage-conversion-really-required-for-simple-edits/34386/2

So that's why I prefer to just use constant video mode. Ideally I could completely avoid it. Hm, I just realised that you mentioned that you can change it so it doesn't get stuck at 1 fps. How does that work and what would it do instead then? Good point btw, I'll check how high vram usage gets when it drops down to 1 fps.

I shall return!

[Sturmlocke86]

Ok, took a while, a ton of stuff going on irl right now, but I was able to test a bit more. I haven't been able to test on a native Steam install, so I'm still using Snap Steam + Ubuntu 24.04 and Nvidia 535 under X11 right now. I tested a bunch of additional games, even Cyberpunk at higher details + 4k reso, and even though games like Cyberpunk push gpu and video engine utilization to around 95-98%, the video created remains very smooth post recording. Same goes for all other games in my Steam list - with the exception of Everquest 2. Even Alien Isolation doesn't go over 70% video engine utilization at maximum graphic details and 4k reso.

So I continued testing EQ2 and realized that GPU shadows makes the game go from 30-50% gpu and video engine utilization when shadows are disabled all the way up to 95-100% for both gpu and video engine utilization when shadows are enabled. As soon as this happens the video recording turns into a 1-fps show during certain gameplay scenes when the in-game framerate dips below 30fps. Disabling gpu shadows makes the fps-rate immediately go up to 60fps again. So disabling gpu shadows seemingly fixes the stuttering video post recording. Video RAM is not a problem as far as I can tell, because nvidia-settings reports around 40% utilization and it doesn't change that much even after half an hour of gameplay and recording.

So now this has me wondering if it has anything to do with the new DirectX11 client that EQ2 switched to a few weeks ago, because recording with the old DirectX9 client wasn't causing any of this. I am not able to reproduce it in any other game thus far. The good news is that the update you pushed fixed the framerate for all other games in the list, recording remains to be super fluid now, so whatever is going on with EQ2 seems to be limited to that game.

[dec05eba]

Ok thanks for testing, that's weird..

[Sturmlocke86]

Ok thanks for testing, that's weird..

Sure thing, trying to help narrow it down.

I tested with Steam Flatpak on Ubuntu half of the day and it's doing the very same thing that the Snap was doing (shadows on = 1fps, shadows off = 60fps video). Since downgrading the Proton version didn't help, I'll try to test outside of Steam and Proton and if that doesn't help then I'll try to test with more recent Nvidia drivers. If all else fails then it's most likely some issue with the game itself. I'll report back asap.

[Sturmlocke86]

Alrighty, I'm back.

First of all: I tried installing the newest Nvidia drivers on Ubuntu 24.04 by adding this ppa since Ubuntu currently only offers up to V535 (tested): https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa?ref=itsfoss.com

Sadly, even after adding the ppa, Ubuntu only offered V545 for my gpu, and installing that went very wrong. I mentioned it in a previous post so this happening comes as no surprise. During the install of that driver I got an error message and after a reboot the system wouldn't boot into X11 anymore - only Wayland without 3D acceleration. So basically I was left with a borked Nvidia driver install and Gnome didn't have any animations whatsoever and 3D acceleration was gone. Trying to fix it took a while and resulted in a black screen with a white blinking cursor during boot, and that's where I gave up. Ubuntu buglist recommends sticking to the tested V535 until they fix outstanding issues with newer drivers.

So then I installed openSUSE 15.5 Leap on this machine, because that's what I was successfully using with gpu screen rec for the some time, previously without any issues as mentioned further above. Same settings as before: constant fps-rate, window recording, tried both h265/264. Typing from 15.5 Leap right now after installing the newest Nvidia V550.78 drivers and after giving EQ2 a try again. Verdict: It's doing 1fps video on Suse too now as long as the in-game shadows are enabled. I used Steam Flatpak for this test. So both openSUSE and Ubuntu are suffering from the same issue in EQ2.

This is how it was running a few months ago via the Steam Flatpak and with gpu screen rec at 4k60 reso and all in-game settings maxed out (including the shadows): https://www.youtube.com/watch?v=nXboAhXmZlE&t=4207s

Any ideas how we could further troubleshoot this? The game is free btw, would you be willing to give it a go on your end?

[dec05eba]

I'll give it a try when I have time. I will have to switch out my amd gpu with my older nvidia gpu first.

[Sturmlocke86]

Thanks! Hope it doesn't cause too much trouble. I wish I had another Nvidia machine to test with a completely different gpu series, but the only other thing that I have around here right now would be from AMD. Btw, I went ahead and tried to work with VFR videos instead of doing it with CFR material because with VFR the slowdown does not happen in EQ2 (so disabling shadows or using VFR fixes the issue). These are the results which explain why CFR is the preferred method in my use case.

Video Editor: Shotcut

Working with VFR:

• Import video H265 3h length in VFR
• Shotcut asks you to convert to CFR for mentioned reasons
• Convertion to CFR takes around 8-9 hours
• Filesize goes from around 15GB to 192GB
• Convertion is done in the lowest quality preset available via lossy format H264, which impacts overall video quality, other formats take much longer to convert (12+ hours)
• Working with such a huge filesize in 4k reso makes video editing difficult though, so enabling hardware accelerated proxy is necessary which in itself takes another 5-9 hours to convert into a proxy friendly format
• Export the video at 4k60 via nvenc hardware acceleration: it now takes around 5-8 hours due to the big filesize
• Now I have to check the entire video length of 3 hours for audio desync or other glitches after going from CFR to VFR because it is known to cause issues in some cases
• I will have to rinse and repeat this process for 10 new videos that I just shot

Verdict: way too much effort, time and quality loss, filesize increase and I have to leave the computer running all night.

Screenshots:

• Converting from CFR to VFR in Shotcut: Link
• Filzesize CFR after convertion from VFR: Link
• Filesize VFR original not converted: Link

Normally this is how it would work by using a CFR video source:

• Import video H264/H265 3h length in CFR
• Edit video without issues because filesize is around 15GB and video is in CFR
• Export video after edit: 2-4 hours via nvenc hardware acceleration
• Done

Verdict: Easy peasy and productive.

The thing is that even Davinci Resolve has issues with VFR: https://www.reddit.com/r/davinciresolve/comments/16ve2av/does_dr186_indicate_if_footage_is_variable_frame/

Quote: "Resolve will figure out the video playback fine in most cases, but often it will cause audio desync when cutting. Re-encode as Constant Frame Rate using Handbrake or Shutter Encoder."

As such you have to convert it into CFR for optimal results. The same feedback can be seen over at Shotcut's forum from their community. Same for Kdenlive. So all in all, trying to work with video material in VFR is highly problematic if you want to edit your videos afterwards, but manually converting it from VFR into a video edit friendly format like CFR is way too complicated for longer videos.

[dec05eba]

Just a question. When you record with gpu screen recorder do you have any multimedia application running? if any application is using the nvidia gpu for video decoding/encoding then it will decrease the performance of nvidia encoding in gpu screen recorder, especially as you are hitting the limit of what your gpu is capable of at 4k

[Sturmlocke86]

Sup mate, nah, the only other thing running besides the game itself is Steam and screen rec. Not sure how much of a performance impact Steam would have here, but according to nvidia-settings my GPU is idling around at zero percent for the video engine after a cold boot. It's a fresh Leap install here too, so there's no bloat or anything running in the background.

I know Steam uses the GPU for some hardware accelerated elements of the gui, but so far no other game is underperforming or anything like that. I could try without Steam just to see what happens. Maybe there is a compat conflict of some sort here?

If the GPU is near it's limit, why doesn't it happen in any other game and why didn't it happen before in eq2? That's what's so strange to me. Something must have changed, but what? I'm on mobile rn and will continue testing in about an hour or so.

[dec05eba]

Ok so, I cant launch everquest II after switching to my nvidia gpu, it worked on my amd gpu. Other games work. Everquest II just quits by itself after pressing play.
Did you try the older gpu screen recorder version in everquest? flatpak update --commit=95dfff4968bfd3059a362b01155e2c6034c313515ec15c7e3b66e324f8d8e8ce com.dec05eba.gpu_screen_recorder. Also try recording on a different desktop environment, recording the monitor as well then. Try recording in replay mode as well without saving and see if it still drops to low update fps (to test if there is an issue with the harddrive instead). But other than that I cant really do anything from my side. You said that it just broke by itself but if it doesn't work in old gpu screen recorder version either then something must have happened to your gpu or your desktops configuration. Nobody else has reported this issue either.

[Sturmlocke86]

Thanks for giving it a go on your Nvidia! It doesn't launch? Are you trying it with Steam + Proton Flatpak or by any other means like vanilla Wine, Lutris etc.? Yeah, I tried the older gpu screen rec version, but it was still doing the same thing, but only for EQ2 of course. All other games can be recorded fine with constant framerate mode. That's why I thought it must be related to something the game is doing now, because if even the older version is showing the same problem, then it probably isn't gpu screen rec. I tried rec the monitor instead of the window, but it does the same thing. I haven't tried rec under a different DE, it's always Gnome here, but I did try different Gnome versions since Ubuntu 23.10 / 24.04 have a more modern iteration of Gnome than what is shipped in Leap. Which DE are you using for the test? I could try something more basic like lxde/lxqt without 3D effects. Ok, will try the replay mode and report back. I actually tried different drives the other day because I have several drives in my pc. The drives I'm using for rec are all NVME SSD, not tried with a mechanical hdd yet. I can test with an hdd though.

Yeah, I'll try all of the steps above and report back asap, but tbh I actually think it might be more related to EQ2 because it started happening right after EQ2 got updated to DX11. It's strange that it's only this game and either switching to variable framerate mode or disabling the in-game shadows fixes the problem completely. Why would disabling shadows fix it? Usually an API change like this will be coupled to some bugs and glitches that get sorted out over time, so it wouldn't surprise me if this is the case. I'll ask around in the EQ2 forums too, maybe someone else has seen this happen.

Whatever the case, thanks a ton for helping out! My donation offer still stands.

[Sturmlocke86]

Another quick update: I have not tested the above yet, will do so tonight, but I did test streaming to Youtube via gpu screen rec and I noticed a few things:

First test run was alright, but according to the terminal output gpu screen rec switches to constant bitrate mode for Youtube streaming. Is there any way to force variable mode, does yt support that or does it always go to constant mode when streaming? I ask because as you can see in the following video, sometimes in the middle of the stream the fps-rate would tank to 1-fps again: https://www.youtube.com/live/vnb83RKsV1U?si=M8VDFlz6HmOg7Pas&t=3574

I chose to show you the spot at the very end via the link above, which should be at 59:34 minutes, because there you can see how the stream was doing well for the most part, and then the fps-rate tanks all of a sudden and "locks" into that fps-rate. It doesn't go back up again and just stays that way. It did happen earlier, but miraculously it actually recovered and went back up again - not so during the end of the video as seen above though. I stopped the stream at that point. Gameplay was doing fine and did not slow down. That's the same issue that I'm seeing when recording in constant framerate mode only that during recording it happens much faster. For streaming I chose: high quality preset (recommended for streaming), ACC audio, automatic framerate mode (it switched to constant mode automatically) and FLV container. I wasn't able to do MP4 container as it would spit out an error about not being able to stream due to incompatible settings (might have to do with this, will have to retest tonight: "opus audio codec is only supported by .mp4 and .mkv files, falling back to aac instead"). I also tried MKV but the screen remained black during the stream -> I will retest MKV though because it might just have been a hiccup. FLV worked fine though and that's what I used for the video above.

When using the built in gpu screen rec Youtube preset for streaming I wasn't able to stream even after copy and pasting the key that yt provided. It just kept spitting out this error: "GPU Screen Recorder, body: Failed to stream video. There is either an error in your streaming config or your graphics card doesn't support GPU Screen Recorder with the settings you used". So then I switched through all sorts of video and audio settings, nothing worked.

Then I checked the terminal for infos:

Error: Could not open 'rtmp://a.rtmp.youtube.com/live2/': Input/output error
waitpid failed: Keine Kind-Prozesse (= no child process)

Further checking what could be causing this I compared the link above to the link that yt was showing me via yt studio:

rtmp://x.rtmp.youtube.com/live2/

(the backup link uses "y" instead of "x" btw)

Seems like gpu screen rec is trying to use the link with a.rtmp and yt is generating the link with x.rtmp for me via yt studio. Could this be the issue? In order to bypass this I switched to "custom" mode in gpu screen rec and then copy and pasted the streaming url from Youtube directly: rtmp://x.rtmp.youtube.com/live2/KEY

KEY = copy and paste generated yt key.

With that + FLV + ACC audio codec I was able to start streaming, see video above.

Just some feedback before I hit the sheets. Will return later.

[Sturmlocke86]

Update: Ok, before I go to bed I tested gpu screen rec with IceWM (preinstalled on openSUSE Leap as a fallback option) and LXQT/LXDE and it's the same issue: constant framerate mode makes the fps tank to 1-fps. Variable is buttery smooth, no issues. So it's not the DE (Gnome). Will continue testing later, my left eye is already closed. gn

[dec05eba]

Youtube shows a.rtmp for me, I think it should work for you as well, but I see that there is a bug in the key. The youtube and twitch keys were switched, so it used the wrong key when you tested.. I fixed that now.

[Sturmlocke86]

Awesome, ty! Is the update out yet? Edit: Ok, update is out now. It was showing 3.7.4 a few seconds ago but it's 3.7.5 now in Gnome Software. I can try it in approx 2 hours and report back. Will try the normal Yt preset in the app and see how it goes. Btw, is it right that streaming to yt will always be in constant bitrate / framerate mode? Is it possible to add a selection between the two in order to do variable instead since which isn't causing any issues in EQ2? Or does yt always default to constant?

[Sturmlocke86]

Ok, quick update: I tried the replay function in constant framerate mode. Replay without saving: no issues, no frame drops, not even a single fps drop, gameplay buttery smooth at 60fps and 4k reso. Replay after saving video and video playback post recording: 1 fps, unwatchable, same issue as when recording normally. Same here, turning off gpu shadows in-game fixes it. Haven't tried with variable framerate mode yet.

[dec05eba]

Im not sure what you mean, does the update fps stay at ~247 when using replay but then go to 1 fps after you save?

[Sturmlocke86]

The framerate starts out fluid at around ~247 but then it suddenly tanks at some point even though standing still. Gameplay is smooth as always though, so the fps issue can not be seen when I'm playing the game. Playing the game EQ2 remains at steady 60fps without any hiccups whatsoever. Only when I save the video and play it back via vlc or mpv is when I can see how the video is performing at 1 fps (same as in the stream that I linked yesterday), which the terminal output can confirm.

sturm@linux:~> flatpak run com.dec05eba.gpu_screen_recorder
Gtk-Message: 00:42:34.092: Failed to load module "canberra-gtk-module"
Gtk-Message: 00:42:34.121: Failed to load module "canberra-gtk-module"
Gtk-Message: 00:42:34.122: Failed to load module "canberra-gtk-module"
window name: EverQuest II (May 10 2024 09:51:45) USER OPTIMIZED
[hevc_nvenc @ 0x55d09f2e6480] ignoring invalid SAR: 0/0
[hevc_nvenc @ 0x55d09f2e6480] ignoring invalid SAR: 0/0
update fps: 241
update fps: 243
update fps: 241
update fps: 242
update fps: 243
update fps: 242
update fps: 242
update fps: 242
update fps: 240
update fps: 242
update fps: 242
update fps: 241
update fps: 243
update fps: 241
update fps: 241
update fps: 243
update fps: 241
update fps: 240
update fps: 241
update fps: 241
update fps: 241
update fps: 243
update fps: 240
update fps: 241
update fps: 242
update fps: 243
update fps: 241
update fps: 240
update fps: 242
update fps: 242
update fps: 242
update fps: 56
update fps: 24
update fps: 13
update fps: 8
update fps: 7
update fps: 5
update fps: 4
update fps: 4
update fps: 3
update fps: 3
update fps: 3
update fps: 3
update fps: 2
update fps: 2
update fps: 2
update fps: 2
update fps: 2
update fps: 2
update fps: 2
update fps: 2
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1
update fps: 1

Now if I go and disable the gpu shadows in-game the fps-rate remains at around ~247 and does not go down to 1-fps according to the terminal logs. The same happens if I switch to variable framerate mode, the fps-rate is steady at ~247 according to the terminal logs even with gpu shadows enabled. So variable + shadows enabled = no problem. Constant + shadows enabled = fps tanks to 1 fps. Constant + shadows disabled = no problem. EQ2 is the only game doing this. I just tried with Cyberpunk 2077 at very high details and 4k reso and the fps-rate is always stable and high, no problem here.

[dec05eba]

Awesome, ty! Is the update out yet? Edit: Ok, update is out now. It was showing 3.7.4 a few seconds ago but it's 3.7.5 now in Gnome Software. I can try it in approx 2 hours and report back. Will try the normal Yt preset in the app and see how it goes. Btw, is it right that streaming to yt will always be in constant bitrate / framerate mode? Is it possible to add a selection between the two in order to do variable instead since which isn't causing any issues in EQ2? Or does yt always default to constant?

I tested with variable framerate and that seems to work on twitch and youtube so i removed the force constant framerate for videos. It will now use constant or variable framerate depending on what the user selects in the settings. It will be available in flathub later (version 3.7.6).

[Sturmlocke86]

Awesome!

I tested it a bit more and it seems that even variable can actually go down a bit with gpu shadows enabled -> depending on the scene. In some scenes variable always shows stable ~247 with gpu shadows enabled, and in some scenes it can go down to 60-120 (plus, minus), but the recorded video always remains very smooth despite the dip. I saved a video during a scene with gpu shadows enabled and the fps-rate went down to ~70 in variable mode (seen in terminal), but the exported video was still very smooth. The only thing that absolutely tanks to single digit numbers is constant framerate mode with gpu shadows enabled at 4k reso (doing 2k reso helps improve the fps-rate sometimes but not always). I also checked more of my locally recorded videos and I can see that I was able to record in DirectX9 with gpu shadows enabled at 4k60 reso and constant video mode, and it was always buttery smooth. So this further indicates that EQ2 is probably doing something different now after switching to DX11 and that might be causing the additional performance impact / overhead.

I opened up a bug report in EQ2: https://forums.everquest2.com/index.php?threads/gpu-shadows-causing-framerate-issues-when-recording-gameplay.2058/

It seems like other players are also experiencing some hiccups after DirectX11 became the new standard in EQ2: https://forums.everquest2.com/index.php?threads/directx11-stuttering.2060/

So for now having the option in gpu screen rec to either use constant or variable mode for recording and streaming seems to be a good solution to this problem. I actually didn't even know that Yt and Twitch supported variable framerates. Looks like it's been there for a while now: https://www.reddit.com/r/Twitch/comments/13ymnq3/why_does_twitch_encode_videos_as_variable_frame/

So thank you for adding this option! Very much appreciated! Will test both the fixed Youtube streaming preset and the variable streaming mode in a couple of hours.

[dec05eba]

For whatever reason flathub didn't update the package. Maybe because the date I set is 1 day in the future according to USA timezone 🤷‍♂️

[Sturmlocke86]

I was already wondering and checking Gnome Software periodically :) No idea about Flathub, have never uploaded anything there. Do they have an faq for questions like that? No worries though, I'll be here later tonight anyway. On standby for the new version. Will test right away once it's there.

[Sturmlocke86]

Got the update and will give it a go in a few minutes via a live stream to see how it goes.

[Sturmlocke86]

Alrighty, typing from my phone now, but glad to report:

• the YouTube prefix works fine now and I was able to select YouTube -> enter key and stream without any issues whatsoever. Simple and elegant.

• streaming to YouTube in variable framerate mode works great now!

I'm actually streaming right now, feel free to check and see how it's doing. You fixed all of the issues! Well done and big thanks for taking care of it all! I wish I could donate for your hard work and dedication, this app deserves every single cent it can get. Thanks to you I can record and stream in high quality now.

[dec05eba]

Thanks for testing. If I find a way to make constant framerate stay at 60 fps even if encoding cant do 60 fps then I'll remove variable framerate and always use that. It's technically possible but no other screen recorder does it and I dont know if ffmpeg/nvenc has any option to do it (since I dont think even ffmpeg can do it when you record directly with ffmpeg).

[Sturmlocke86]

Yeah, I'm content that it works well with variable. Tbh, I would always like to have the choice between the two, the way it is now basically. It's useful for workaround use cases like mine. You could make constant the default (recommended) but still allow users to use variable for streaming if needed. Having options is good 👍🏻