How to debug Encoding overloaded?

[tari3x]

I am seeing a persistent 'Encoding overloaded' with certain settings and I don't know how to figure out the bottleneck. GPU processor and memory look very mild, same for CPU and RAM. Nothing exciting in the logs, even with --verbose. Is there a way for me to get more information on what's wrong?

I am not posting any details of my settings on purpose - at this point I am not looking for advice of the form "you should change your settings", rather I am interested in how I could figure it out myself in a principled manner.

 

[koala]

The message "Encoding overloaded! Consider turning down video settings or using a faster encoding preset." will appear, if there are more than 0.1% frames currently skipped by the encoder. A frame is skipped by the encoder, if the encoder wasn't able to encode it within the time span available for encoding one frame. For 60 fps, that's 16.6667 ms per frame.

This will happen, if the computing power available for encoding one frame isn't available. In general, the more data you try to encode, the more computing power required. The higher the resolution your output video has, the more data. The more fps your output video has, the more data.
It might also be possible the GPU is currently transferring a huge amount of data between CPU memory and GPU memory for the app or game you're running, and there isn't enough pci-express bandwidth available to both transfer this data and the data for OBS.

If it's lacking computing power, it depends on various factors. If you use x264, it's the CPU power that is lacking. If you use a hardware encoder, it depends on the GPU type (Intel, AMD, Nvidia) what might be the issue. Nvenc is a dedicated circuit on the GPU and has a fixed encoding power. If you ask too much from Nvenc, it simply stalls, no matter what the app/game is currently using as 3D computing power. For Intel and AMD GPUs, the hardware encoder requires significant resources of the same type a 3D app/game requires, so they compete for resources.

There is a second reason for overload situations, these are logged in the log as lagged frames. These are the result of OBS not being able to composite a frame within the time available until the next frame. It's also 16.6667 ms. I don't know if OBS also throws the "Encoding overload" message for this. This situation happens if there are not enough GPU drawing (3D) resources for OBS compositing the output frame. Chances are good, you also have GPU overload if you have encoding overload. GPU overload is usually the result from the app/game competing with OBS for GPU resources. The reason for OBS demanding too much GPU resources might be a complex scene setup or too much video filters. Or latency introduced with files for media sources being pulled from a network drive or the output video file being written to a too slow hard disk or an external hard disk without write back cache.

The official OBS troubleshooting guide for encoding overload is this:

Encoding Performance Troubleshooting | OBS

OBS Knowledge Base. Learn best practices to solve encoding performance issues

obsproject.com

 

[tari3x]

Hi, thanks for speedy response!

I don't fully understand why there is a limit on the encoding time per frame when I'm recording - there should be no rush. But I asked that in a separate question.

> The message "Encoding overloaded! Consider turning down video settings or using a faster encoding preset." will appear, if there are more than 0.1% frames currently skipped by the encoder.

As you describe yourself, there are many different reasons for a frame to be dropped. Would it be feasible for obs to capture more information about why exactly it is dropping frames? Like "sorry, I didn't get a frame from GPU in time" or "sorry, I did get a frame from GPU, but the CPU couldn't encode it in time" or "sorry, I can't write your frames to network fast enough". Does this sound like a reasonable feature request? I feel like it could save me weeks of stumbling, as well as saving your time.

Upon closer inspection, I suspect that the CPU might actually be the bottleneck - it looks like OBS is using only 8 cores out of 32. For encoding lossless in simple mode (utvideo), is there a way to convince it to use more cores?

 

[Phandasm]

The time limit is because if you can't encode frames at least as fast as you get them then you have to start buffering input frames, potentially endlessly (until you run out of memory) and raw frames are quite heavy.

Dropped frames due to render lag, encoding lag, and network congestion are all counted differently in the stats panel (view->stats), so I'm pretty sure encoder overload is actually just the encoder.

x264 normally maxes out the threads automatically, so it might just be that lossless mode is different somehow.
You can try to force it by setting threads=32 in the x264 options in advanced settings but I suspect it won't accomplish much.
Other suspects would normally be aggressive B-frame, ref frame, and motion estimation settings but I'm not sure they're even used in lossless encoding.
If anything I'm suspicious that writing to the file might be counted as encoding time and the massive bitrate from lossless encoding is the bottleneck.

 

[tari3x]

> The time limit is because if you can't encode frames at least as fast as you get them then you have to start buffering input frames, potentially endlessly (until you run out of memory) and raw frames are quite heavy.

Would there be a way for me to sign off my rights to complain and to enable an infinite buffer? I have 192G of RAM an I only want to record 5 minutes of video - I might just about make it. And if I don't, ordering several TB more RAM on amazon today seems far easier than the weeks I've already spent trying out different tools and combing through various forums.

> If anything I'm suspicious that writing to the file might be counted as encoding time and the massive bitrate from lossless encoding is the bottleneck.

The total size of the encoded file is 50G - that fits in memory no problem, so if it drops frames due to disk speed, that would be a very sad misfortune indeed. I have a reason to believe it's not the reason though - it can keep up when I switch to a different colourspace, which shouldn't make much of a difference in terms of file size? Maybe it does? If you know a good reading source on colourspaces, I'd appreciate a pointer!

 

[tari3x]

Oh, and regarding threads=32: is there a way for me to convert my simple setting into the equivalent advanced one, so I can try out adding these flags?

 

[Phandasm]

Would there be a way for me to sign off my rights to complain and to enable an infinite buffer?

I don't think OBS is built to do that.

The total size of the encoded file is 50G - that fits in memory no problem, so if it drops frames due to disk speed, that would be a very sad misfortune indeed. I have a reason to believe it's not the reason though - it can keep up when I switch to a different colourspace, which shouldn't make much of a difference in terms of file size? Maybe it does? If you know a good reading source on colourspaces, I'd appreciate a pointer!

A 4:2:0 colorspace has 1/4 the chroma resolution and 1/2 the bandwidth of a full (4:4:4) colorspace. It's done specifically to reduce the bitrate.
If disk speed is indeed the bottleneck, you could maybe save the file to a ramdisk since you have so much ram.

Oh, and regarding threads=32: is there a way for me to convert my simple setting into the equivalent advanced one, so I can try out adding these flags?

I've actually never used the simple settings, so I'm not too sure what it does. x264 with a fast-ish preset and crf 0 (usually qp 0 but I think crf 0 works too) should get you lossless though.

 

[koala]

For encoding lossless in simple mode (utvideo), is there a way to convince it to use more cores?

If you intend to record lossless, disk bandwidth is a likely bottleneck. For resolutions higher than 1920x1080, a spinning disk is too slow for writing that much data at a steady rate. Record to a SSD, and don't record to an external drive.

If it comes to the other things you suggested, well, OBS is designed the way it is. It's designed to process data in real time, and if the computer isn't able to process the data in real time, it chokes.

About your request for more detailed logging: that's extremely difficult for not much benefit. There are always multiple items to process within time. As long as the sum of all things don't add up to more than the frame time, everything is well. Only if the sum of all processing is above, there is lagging or lost frames. Every item itself is lower than the limit, but the sum of all is above. What thing is now at fault?

If you want a detailed analysis of the program modules, terminate OBS after a recording session, then load the log file from that session into a text editor. You will find a footer at the end of that file OBS writes at shutdown that contains detailed timing information.

 

[Suslik V]

...it be feasible for obs to capture more information about why exactly it is dropping frames? Like "sorry, I didn't get a frame from GPU in time" or "sorry, I did get a frame from GPU, but the CPU couldn't encode it in time"...

OBS log-file (when OBS session was complete OK) has profiling info (named "Profiler Results", time in ms). There you can see how many time takes each OBS task.

 

[tari3x]

Ah yes, thanks, this does look useful:

info: obs_graphics_thread(16.6667 ms): min=0.38 ms, median=16.537 ms, max=87.996 ms, 99th percentile=38.608 ms, 55.2415% below 16.667 ms
info:  ┣tick_sources: min=0 ms, median=15.439 ms, max=87.127 ms, 99th percentile=28.597 ms
info:  ┣output_frame: min=0.098 ms, median=0.333 ms, max=30.424 ms, 99th percentile=9.163 ms
info:  ┃ ┣gs_context(video->graphics): min=0.098 ms, median=0.33 ms, max=11.415 ms, 99th percentile=2.892 ms
info:  ┃ ┃ ┣render_video: min=0.006 ms, median=0.169 ms, max=11.206 ms, 99th percentile=0.324 ms
info:  ┃ ┃ ┃ ┣render_main_texture: min=0.004 ms, median=0.113 ms, max=3.479 ms, 99th percentile=0.228 ms
info:  ┃ ┃ ┃ ┣render_output_texture: min=0.032 ms, median=0.038 ms, max=0.729 ms, 99th percentile=0.076 ms, 0.519435 calls per parent call
info:  ┃ ┃ ┃ ┗stage_output_texture: min=0.02 ms, median=0.025 ms, max=10.315 ms, 99th percentile=0.094 ms, 0.519435 calls per parent call
info:  ┃ ┃ ┣gs_flush: min=0 ms, median=0.007 ms, max=1 ms, 99th percentile=0.057 ms
info:  ┃ ┃ ┗download_frame: min=0 ms, median=0.002 ms, max=0.004 ms, 99th percentile=0.003 ms, 0.519435 calls per parent call
info:  ┃ ┗output_video_data: min=0 ms, median=0 ms, max=25.232 ms, 99th percentile=21.686 ms, 0.518257 calls per parent call
info:  ┗render_displays: min=0.099 ms, median=0.455 ms, max=56.167 ms, 99th percentile=1.873 ms
info: video_thread(video): min=0 ms, median=60.407 ms, max=978.188 ms, 99th percentile=978.188 ms

Not qutie sure how to match it to what we discussed though - which bits correspond to encoding and which bits are disk IO?

 

[tari3x]

Oh, and here's something weird - I changed the settings such that I don't see "Encoding overloaded" any more. But I still see

obs_graphics_thread(16.6667 ms): min=0.355 ms, median=16.72 ms, max=120.827 ms, 99th percentile=30.976 ms, 48.2896% below 16.667 ms

This suggests that 52% of frames are above 16.6667 and thus should have been dropped! But you said "Encoding overloaded" is shown when at least 0.1% are dropped.

 

[Suslik V]

"obs_graphics_thread" is about textures and GPU so, it is likely about "rendering lag". OBS uses acceleration from your video card to compose the scene (because processing overlays - one source above other - on CPU is less efficient). But if your GPU is busy - you may get higher numbers than expected.

Software encoding in OBS works like this (roughly): prepare textures of all sources > upload textures to GPU > composition of the frame by GPU > download from GPU > encode final frame by CPU > save frame to disk (or send_packet). Of course, final frame should be shown in OBS Preview, or in other words - render_displays.

Your log shows that the tick_sources (first stage of OBS processing) is the slowest. There is no sense to go further (even prepare texture from the source is slow in your environment, general recommendation here - get rid of slow sources). Try simple Color source (solid color) and record this static image. Look at OBS log and compare. Then, for example, run "fr-043" (rove by Farbrausch) demo from Breakpoint 2010 and try to capture it, record and compare. And so on.

Also, you may wanna read this: https://obsproject.com/forum/thread...frame-loss-of-a-recorded-video-in-obs.152443/

 

[tari3x]

"obs_graphics_thread" is about textures and GPU so, it is likely about "rendering lag".

Ah, that's good to know! So it's the video_thread that corresponds to encoding and is responsible for skipping frames? I guess I should mostly worry about video_thread then, since I don't care about lag - I'm not streaming. Here's an example from a recording where I did not see "Encoding overloaded":

video_thread(video): min=9.558 ms, median=10.074 ms, max=34.265 ms, 99th percentile=27.596 ms

The 99th percentile being above 16ms means that at least 1% of frames should have been skipped, according to @koala - but the logs suggest that no frames got skipped. Could you clarify once more the condition for skipping a frame?

prepare textures of all sources > upload textures to GPU

Sorry, I don't understand this bit. When I am recording my screen, what exactly gets uploaded to the GPU?

Your log shows that the tick_sources (first stage of OBS processing) is the slowest.

So for recording, does this mean that my graphics card is slow to give frames to OBS? My card is A6000 fwiw and I tried two different ones, so they are not faulty.

 

[Phandasm]

Ah, that's good to know! So it's the video_thread that corresponds to encoding and is responsible for skipping frames? I guess I should mostly worry about video_thread then, since I don't care about lag - I'm not streaming.

Rendering lag means you drop frames at the rendering stage before you even get to the encoder. Lag anywhere in the pipeline is bad.

So for recording, does this mean that my graphics card is slow to give frames to OBS? My card is A6000 fwiw and I tried two different ones, so they are not faulty.

Tick refers to whatever logic your sources are doing (on the CPU mostly) to prepare for the render stage.
Generally this involves fetching data from somewhere and/or transforming it so it's ready to be displayed on the next render call.

You have something in your scene that is taking a long time to do whatever it's doing.
Try clearing all the sources from your scene and add them back one at a time until you find the culprit.
Edit: maybe do this on a whole new scene collection, sources in inactive scenes can still cause problems.

 

[Suslik V]

...since I don't care about lag - I'm not streaming

There, read "rendering lag" as "frame time was increased" (itself it was long phrase, so, to shorten the UI, it was replaced by the "rendering lag").
It was named "lag" because each frame is valid only few ms (1/FPS = frame time sec). When current frame time increases - you have a lag.
Delay in the response to your actions (as you may knew the "lag" word) has nothing to do with the "due to rendering lag" phrase in OBS. OBS simply explains that frame time increased a lot (and when "time" increases - you may say it is "lag").

OBS attempts to record at fixed FPS (not variable) and real-time (FPS at which OBS will render its output can be set in Settings > Video). If new frame not ready in time - you get "rendering lag" and required frames will be missing (OBS substitutes missing frames by doubling previous frames until new one will be ready). So, you are care about the "rendering lag" and care a lot. Encoding is useless if it encodes only endlessly doubled pictures of one of the previous frames.

Only insignificant variations of timestamps is possible in the recorded file when final video was remuxed from one media container to another (~1 ms, and because of nature of remuxing process, more info was here: https://obsproject.com/forum/threads/remuxing-mkv-file-results-in-variable-framerate.93674/ and in other sub-links in that thread).

...When I am recording my screen, what exactly gets uploaded to the GPU?

In the worst case - anything will be uploaded to GPU. The worst case, multi-GPU setup (APUs, CrossFireX, SLI etc), OBS renders its composition on one GPU and gets textures for all its sources from other GPU.

 

[tari3x]

Rendering lag means you drop frames at the rendering stage before you even get to the encoder.

To lag means to arrive late. If something does not arrive, it is not lagging, it is missing. Should I file a bug report asking to fix the message in the logs?

In the worst case - anything will be uploaded to GPU.

Sorry, perhaps I'm not being clear. I'm not talking about the general case. To ask my question again: When I am recording my screen, what exactly gets uploaded to the GPU? I only have one source and that is my screen.

 

[Suslik V]

...If something does not arrive, it is not lagging, it is missing. Should I file a bug report asking to fix the message in the logs?

You may try, of course. But take in mind "frame time" and consistency of the info in UI and in the log.

...Sorry, perhaps I'm not being clear. I'm not talking about the general case. To ask my question again: When I am recording my screen, what exactly gets uploaded to the GPU? I only have one source and that is my screen.

Display Capture source?

 

[tari3x]

Sadly I think we keep talking past each other, so I'll stop wasting your time Thanks all!

 

[tari3x]

How to debug "Encoding overloaded"? · Issue #9395 · obsproject/obs-studio

Operating System Info Windows 11 Other OS No response OBS Studio Version 29.1.3 OBS Studio Version (Other) No response OBS Studio Log URL https://obsproject.com/logs/mP6ZBzFIxBGu0uKA OBS Studio Cra...

github.com