Encoding overload issues

Sho0te3r

New Member
I will cut straight to the point. Streaming games seems fine, but when I try to record tthe same games it just flops with encoding overload. I had PC with GTX 1060 and didn't have such problems like I do now. Help is very much appreciated.

PC statistics:
GPU: NVIDIA GeForce RTX 3060 Ti
CPU: AMD Ryzen 5 3600 6-Core Processor
RAM: 16 GB


Log file: https://obsproject.com/logs/Ob48dofoVfb0W9lR
 

shansmi

Member
ya your setup is wrong for recording. CBR is not recommended for recording. You are dropping frames per the logs. There is a guide posted about streaming vs recording and another that deal with frame loss. Also I see you are at least mounting a cloud device. record locally for best results even if the far end device is on your LAN, don't do it.



09:43:38.707: ==== Recording Start ===============================================
09:43:38.707: [ffmpeg muxer: 'adv_file_output'] Writing file 'D:/Videos/2022-02-01 09-43-38.mkv'...
09:44:16.579: Stopping recording due to hotkey
09:44:17.022: [ffmpeg muxer: 'adv_file_output'] Output of file 'D:/Videos/2022-02-01 09-43-38.mkv' stopped
09:44:17.022: Output 'adv_file_output': stopping
09:44:17.022: Output 'adv_file_output': Total frames output: 2273
09:44:17.022: Output 'adv_file_output': Total drawn frames: 2299
09:44:17.022: ==== Recording Stop ================================================
09:44:17.023: Video stopped, number of skipped frames due to encoding lag: 371/2292 (16.2%) <<<<<<


09:54:21.329: ---------------------------------
09:54:21.329: [x264 encoder: 'test_x264'] preset: veryfast
09:54:21.330: [x264 encoder: 'test_x264'] settings:
09:54:21.330: rate_control: CBR <<<<<<<<<<<<<<<<<<<<<<<<<
09:54:21.330: bitrate: 6000
09:54:21.330: buffer size: 6000
09:54:21.330: crf: 23
 

Sho0te3r

New Member
ya your setup is wrong for recording. CBR is not recommended for recording. You are dropping frames per the logs. There is a guide posted about streaming vs recording and another that deal with frame loss. Also I see you are at least mounting a cloud device. record locally for best results even if the far end device is on your LAN, don't do it.



09:43:38.707: ==== Recording Start ===============================================
09:43:38.707: [ffmpeg muxer: 'adv_file_output'] Writing file 'D:/Videos/2022-02-01 09-43-38.mkv'...
09:44:16.579: Stopping recording due to hotkey
09:44:17.022: [ffmpeg muxer: 'adv_file_output'] Output of file 'D:/Videos/2022-02-01 09-43-38.mkv' stopped
09:44:17.022: Output 'adv_file_output': stopping
09:44:17.022: Output 'adv_file_output': Total frames output: 2273
09:44:17.022: Output 'adv_file_output': Total drawn frames: 2299
09:44:17.022: ==== Recording Stop ================================================
09:44:17.023: Video stopped, number of skipped frames due to encoding lag: 371/2292 (16.2%) <<<<<<


09:54:21.329: ---------------------------------
09:54:21.329: [x264 encoder: 'test_x264'] preset: veryfast
09:54:21.330: [x264 encoder: 'test_x264'] settings:
09:54:21.330: rate_control: CBR <<<<<<<<<<<<<<<<<<<<<<<<<
09:54:21.330: bitrate: 6000
09:54:21.330: buffer size: 6000
09:54:21.330: crf: 23

I tried CBR because CQP didn't work (I tried settings which should get me shity result but not encoding overloads but apparently not). I downloaded streamelements addon. Do you mean that by cloud device? Also in the meantime I tried CQP and CBR best and worst settings with no better result (I even went into games and got everything to the lowest settings). Finaly I reinstalled obs and reseted all settings but I still haven't got rid of a problem.

Currently I have it on this:
rate_control: CQP
Keyframe interval: 0
Preset: Quality
Profile: High
cq level: 15
b-frames: 2

Tried once more but problem still persists: https://obsproject.com/logs/TWQSyIQrbDAbFVSq
 

Lawrence_SoCal

Active Member
That StreamElements plugin is known to cause LOTS of problems on some systems. but not all.. just beware. That plugin pukes all over the OBS log, combined with other factors means I'd never consider using it. but that is just me and my circumstance/use case.

I ALWAYS partition my drives, separating OS from Data (seriously old school), so I get that recording to D:\ doesn't necessarily mean cloud service. However, on my latest OBS machine, I have a 256GB C drive (NVMe) and an archive data HDD (d:\). I do NOT record to D:\, even though it should be fine, as I have plenty of Disk I/O on the NVME drive. So I record/remux to C:\ [NVMe], in my case, run a off-site data/sync of the recording, and after that completes, then move recording file to data HDD. My recordings currently are in the 10-13GB each, and I have more than 100GB free so no flash write-levelling concerns for me.

I suspect a CQP of 15 is your problem. see post from folks way more knowledgeable than I on the subject

17:20:48.964: [jim-nvenc: 'recording_h264'] settings:​
17:20:48.964: rate_control: CQP​
17:20:48.964: bitrate: 0​
17:20:48.964: cqp: 15​
17:20:48.964: keyint: 250​
17:20:48.964: preset: hq​
17:20:48.964: profile: high​
17:20:48.964: width: 1920​
17:20:48.964: height: 1080​
17:20:48.964: 2-pass: false​
17:20:48.964: b-frames: 4​
17:20:48.964: lookahead: true​
17:20:48.964: psycho_aq: true​

From https://obsproject.com/forum/threads/best-settings.140188/#post-514693 see @FerretBomb comment #2
2) Record using CQP or CRF, not CBR. CBR is only used for streaming, where the back-end infrastructure requires it. CQP/CRF are quality-target based encodes, and will use as much or as little bitrate as is needed to maintain a constant image quality. No wasting bitrate on simple/slow scenes, no choking on fast-moving or complex scenes. 22 is a good starting point. 16 will result in much larger files, but near-perfect video. 12 should only be used if you plan to edit and re-encode later, and will be VERY large. Anything lower than 12 shouldn't be used unless you know exactly why you need it, and what problems it can cause.​
a little more detail posted later/elsewhere on same subject
22 is the normal 'good' point, 16 for 'visually lossless', and 12 is generally the lowest you'll want to go even if you plan to edit the video later (to cut down on re-encoding artifacts). The lower the number, the closer to 'lossless' video it gets. But below 16 the filesizes get ridiculously large very fast.​
Which begs the question of your disk I/O capacity when using CPQ=15?

the following is something I'd advise to test/check only if still having an issue AFTER adjusting CQP to a reasonable value
3) Use the Quality preset, not Max Quality. Likewise, turn off Psychovisual Tuning. Both of these options use CUDA cores, and tend to cause significant problems like encoding overload when it should otherwise not be happening.​

So
- 1st make sure your recording target can handle the disk I/O.
- do real-time monitoring on GPU NVENC to see if actually overloaded, or if bottleneck elsewhere.
 

Sho0te3r

New Member
That StreamElements plugin is known to cause LOTS of problems on some systems. but not all.. just beware. That plugin pukes all over the OBS log, combined with other factors means I'd never consider using it. but that is just me and my circumstance/use case.

I ALWAYS partition my drives, separating OS from Data (seriously old school), so I get that recording to D:\ doesn't necessarily mean cloud service. However, on my latest OBS machine, I have a 256GB C drive (NVMe) and an archive data HDD (d:\). I do NOT record to D:\, even though it should be fine, as I have plenty of Disk I/O on the NVME drive. So I record/remux to C:\ [NVMe], in my case, run a off-site data/sync of the recording, and after that completes, then move recording file to data HDD. My recordings currently are in the 10-13GB each, and I have more than 100GB free so no flash write-levelling concerns for me.

I suspect a CQP of 15 is your problem. see post from folks way more knowledgeable than I on the subject

17:20:48.964: [jim-nvenc: 'recording_h264'] settings:​
17:20:48.964: rate_control: CQP​
17:20:48.964: bitrate: 0​
17:20:48.964: cqp: 15​
17:20:48.964: keyint: 250​
17:20:48.964: preset: hq​
17:20:48.964: profile: high​
17:20:48.964: width: 1920​
17:20:48.964: height: 1080​
17:20:48.964: 2-pass: false​
17:20:48.964: b-frames: 4​
17:20:48.964: lookahead: true​
17:20:48.964: psycho_aq: true​

From https://obsproject.com/forum/threads/best-settings.140188/#post-514693 see @FerretBomb comment #2
2) Record using CQP or CRF, not CBR. CBR is only used for streaming, where the back-end infrastructure requires it. CQP/CRF are quality-target based encodes, and will use as much or as little bitrate as is needed to maintain a constant image quality. No wasting bitrate on simple/slow scenes, no choking on fast-moving or complex scenes. 22 is a good starting point. 16 will result in much larger files, but near-perfect video. 12 should only be used if you plan to edit and re-encode later, and will be VERY large. Anything lower than 12 shouldn't be used unless you know exactly why you need it, and what problems it can cause.​
a little more detail posted later/elsewhere on same subject
22 is the normal 'good' point, 16 for 'visually lossless', and 12 is generally the lowest you'll want to go even if you plan to edit the video later (to cut down on re-encoding artifacts). The lower the number, the closer to 'lossless' video it gets. But below 16 the filesizes get ridiculously large very fast.​
Which begs the question of your disk I/O capacity when using CPQ=15?

the following is something I'd advise to test/check only if still having an issue AFTER adjusting CQP to a reasonable value
3) Use the Quality preset, not Max Quality. Likewise, turn off Psychovisual Tuning. Both of these options use CUDA cores, and tend to cause significant problems like encoding overload when it should otherwise not be happening.​

So
- 1st make sure your recording target can handle the disk I/O.
- do real-time monitoring on GPU NVENC to see if actually overloaded, or if bottleneck elsewhere.
Sorry for late response. I checked my disk and switched it to SSD instead of HDD. Now I have quite common apperances of encoding overload but aat least it's not constant. I also tried to see gpu trough geforce aplication and it seems that nothing is wrong with my gpu
 
Top