[Possible Bug]: Recordings are not clear.

[Haiderahandali]

20240123_172213.mp4

20240123_172843.mp4

20240123_172933.mp4

I am have tried recording an win32-app window while listening to messages from
spy++64-bit.
I tried both h264 and h265, I tried iGPU and dGPU and I tried without GPU encoding all together. (this is why I am attaching different video samples, not sure if that is relevant or helpful tho).

I am not sure what info to provide ( aside from using windows 11 Pro build number 23H2) so I attached dxdiag system info to this issue.
DxDiag.txt

[mmozeiko]

The second video seems fine, it just has a very low bitrate. For a lot of changing text (or like game recordings) you should increase bitrate a lot.
And that video seems to be encoded using software encoder. But the other two are with GPU, I'll check what could be wrong there.

[Haiderahandali]

I tested a few more times with 10x more bit rate (not sure if that is enough, 80,000 kbit/s),
the software encoder does indeed seem to not have that problem for short videos (around 5 seconds or so). But if I keep recording for a bit longer the issue kind of happening (also the mouse pointer movement, went from smooth in first part to very jaggy/laggy after the glitch). Link for it below (I can not upload it to github for size limitation, and streamable removes them in 2 days :( )

https://streamable.com/z5kr4a

Also I noticed that if I double the bit rate (160,000 kbit/s) this rarely happens with software encoder.
out of the 10 videos with 160,000 kbit/s (all roughly 30 seconds long) only one had the issue (in the first 2 seconds):

https://streamable.com/s9o87f

What I found interesting is that, Video size of 80,000 kbit/s (with the glitches, as in first link 25s, 119 MB) is actually bigger than the Video size of 160,000 kbit/s (second link, 27s, 86.5 MB). I am no video expert but this hints to me that somehow the compression/encoding is at fault here, maybe keyframe encoding goes wrong.

To summarize:
1- Increasing bitrate seems to avoids the issue for the most part. For 80,000 kbit/s. this issue never happened in the first few seconds, when it had it, only after 5+ seconds (tested roughly 10 times).
2- For 160,000 kbit/s, It only happened once (roughly tested 10 times).
3- The Video sizes when a glitch happens under 80,000 kbit/s seems to make it larger -sometimes- than 160,000 kbit/s video with no glitch, roughly same duration, and roughly recording the same thing. When no glitch, the Video sizes are roughly comparable to each others.
4- All of the above is related to H264 - Software encoder, The combination of H265 & Software encoder returns an error: "Can not configure encoder Input!", I believe this is the expected behavior.
5- For iGPU/dGPU the issue still happens every time both for H264/H265.
6- I also tested both audio enabled / disabled and still the same.

[mmozeiko]

Ok, it looks like the same problem happens in the videos on streamble. I'll try to reproduce this.

As for bitrate - typically going over 50k or so does not matter much for 1080p recording. That number is not exact, the encoder is free to use less or a bit more. It's just some kind of average it tries to achieve, but depending on internal implementation limitations and what is captured from screen it may use less (or more). I would not worry about such size differences - unless the size is much more than bitrate specified.

What kind of display framerate you have set? If it is 144Hz or similar high framerate monitor then it may happen that encoder cannot encode fast enough, especially if it is laptop and it is not plugged it - maybe it is throttling the cpu or gpu. Check if you have limit on 60Hz in wcap settings. And when recording - hover the mouse over tray icon, it shows how many frames it has dropped. If that number is increasing then something is not right with performance, because recording 1080p @ 60Hz should easily be doable on any decent computer even with software encoding.

h265 is not supported by software encoding, MS does not ship encoder for it. It's available only when gpu is used to encode.

[Haiderahandali]

I am using wcap with 60 Hz (the default). I tried all settings and I think I found where the issue is:
refresh rate, setting it to 144Hz instead of 60 (which is my default), I believe removes the issue entirely, with iGPU/dGPU I did not have any issues (10 times tested). but under 60 Hz I get it every time.
I tried 144 with all power settings in win11 (optimize for performance, optimize for battery and balanced) with iGPU/dGPU and all of them had no issues. Switch to 60 Hz, and even on Performance Mode and with battery connected the issue still happens.

This is a bit counter intuitive, I expect higher framerate to make it harder for the application to record, not the opposite.

[mmozeiko]

Is your screen actually 144Hz? Or are you running 60Hz.

If it is 144, then it is strange that limiting to 60Hz does not work. You can also try putting 0 in that field. Then it won't limit anything, just record everything (same for max width/height).

[Haiderahandali]

I probably phrased it wrong, I meant switching my monitor refresh rate to 144Hz and not wcap, wcap was always set to 60Hz
Here is a video showing the problem:

https://streamable.com/hx2na6

I also might have been a bit optimistic, because even at 144Hz monitor refresh rate the problem happened today, But it is very rare, at 144Hz, I can not reproduce it consistently.