Question / Help High cpu usage using media sources??

C

Carson Daley

New Member
So I recently decided to buy new overlays for my stream and after I bought them I realized they were animated, nothing huge just some little moving parts on the webcam frame and such. After adding them all and getting rid of my old overlays I did a test stream cause I noticed just sitting idle not streaming the cpu usage was higher than usual. Start the test stream and I notice that when I switch scenes and sometimes when I am in game my cpu % goes from 21%-30% and I dip down to 30-50 fps.

I included a log file just incase anyone can get anything major from it, and if you guys know of any settings that can decrease this help is greatly appreciated. I did try streaming in 30 fps and I had no issues so If I can't fix it I will just have to stream in 30 fps no big deal.
 

Attachments

  • 2019-02-19 23-19-32.txt
    49.2 KB · Views: 153
Last edited:
Narcogen

Narcogen

Active Member
C

Carson Daley

New Member
Narcogen said:
23:52:40.628: Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 350 (2.9%)

GPU is overloaded.

https://obsproject.com/wiki/GPU-overload-issues

Switching to 30fps from 60 would definitely resolve this.

At 2750 bitrate, your connection can't keep up:

23:53:51.120: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 306 (36.2%)

https://obsproject.com/wiki/Dropped-Frames-And-General-Connection-Issues
Click to expand...
Ok so that's the wrong log file. So my apologies, when I get home tonight I will redo it with x264 which is what I usually use. Again sorry for that and I'm working on getting better internet.
 
Narcogen

Narcogen

Active Member
Also, Windows is out of date:

23:19:32.986: Windows Version: 10.0 Build 17134 (revision: 590; 64-bit)

And this means "game mode" is on by default and can't be switched off. Check the link below for more information.
 
Narcogen

Narcogen

Active Member
Carson Daley said:
Ok so that's the wrong log file. So my apologies, when I get home tonight I will redo it with x264 which is what I usually use. Again sorry for that and I'm working on getting better internet.
Click to expand...

To clarify: OBS needs to use the GPU whether you use hardware or CPU x264 encoding. OBS needs to render frames before encoding, and this work is done on the GPU. If GPU utilization is too high, the log shows the above error-- "rendering lag".
 
C

Carson Daley

New Member
Narcogen said:
To clarify: OBS needs to use the GPU whether you use hardware or CPU x264 encoding. OBS needs to render frames before encoding, and this work is done on the GPU. If GPU utilization is too high, the log shows the above error-- "rendering lag".
Click to expand...
Ahhhh ok, thank you for clarifying cause I didn't know it was to that extent , and I just updated my windows so I will have to see what I can do to find the new update. So I'll look into your provided link and see what I can do. Thank you for responding, and I'll let ya know how it goes. And I don't know if it's because I'm on my phone but I didn't see a link under the Windows update response. But other than that is there anything you would recommend I do?
 
Last edited:
C

Carson Daley

New Member

Attachments

  • 2019-02-21 01-33-56.txt
    13.8 KB · Views: 25
  • 2019-02-21 00-59-09.txt
    26.6 KB · Views: 14
carlmmii

carlmmii

Active Member
The truth is, most compositing work is going to be a very minimal load on your GPU (which is the reason why the GPU is leveraged in the first place), so you probably aren't going to see any difference in total loading going from 60fps to 30fps. What will change though is the minimum required frame latency for smooth capture, since that's changing from 16ms to 33ms. If you were in a situation where, for example, OBS wasn't allowed to grab frames until 25ms after the request, then that would result in stuttering at 60fps... but no issues at 30fps.

This is where the rendering lag can manifest with GPU load prioritization -- without the necessary resources allocated to OBS (which game mode exacerbates), despite requiring a very minimal amount of GPU power to perform the operations, those operations are being stalled by the other higher priority tasks (which in this case is your game).

This is exactly what's happening in the first log file you posted:

Code: 
00:13:53.616: obs_graphics_thread(16.6667 ms): min=0.063 ms, median=1.264 ms, max=523.602 ms, 99th percentile=25.742 ms, 96.9927% below 16.667 ms
00:13:53.616:  ┣tick_sources: min=0.002 ms, median=0.028 ms, max=523.37 ms, 99th percentile=0.922 ms
00:13:53.616:  ┣output_frame: min=0.058 ms, median=1.03 ms, max=116.538 ms, 99th percentile=25.025 ms
00:13:53.616:  ┃ ┣gs_context(video->graphics): min=0.057 ms, median=0.985 ms, max=116.16 ms, 99th percentile=24.802 ms
00:13:53.616:  ┃ ┃ ┣render_video: min=0.006 ms, median=0.788 ms, max=115.198 ms, 99th percentile=3.74 ms
00:13:53.616:  ┃ ┃ ┃ ┣render_main_texture: min=0.003 ms, median=0.776 ms, max=114.593 ms, 99th percentile=3.669 ms
00:13:53.616:  ┃ ┃ ┃ ┣render_output_texture: min=0.001 ms, median=0.009 ms, max=3.3 ms, 99th percentile=0.095 ms, 0.477656 calls per parent call
00:13:53.616:  ┃ ┃ ┃ ┣render_convert_texture: min=0.001 ms, median=0.01 ms, max=3.476 ms, 99th percentile=0.087 ms, 0.477656 calls per parent call
00:13:53.616:  ┃ ┃ ┃ ┗stage_output_texture: min=0 ms, median=0.002 ms, max=5.072 ms, 99th percentile=0.19 ms, 0.477656 calls per parent call
00:13:53.616:  ┃ ┃ ┣gs_flush: min=0.016 ms, median=0.081 ms, max=9.022 ms, 99th percentile=0.335 ms
00:13:53.616:  ┃ ┃ ┗download_frame: min=0 ms, median=0.001 ms, max=65.259 ms, 99th percentile=29.192 ms, 0.477656 calls per parent call
00:13:53.616:  ┃ ┗output_video_data: min=0.097 ms, median=0.192 ms, max=7.239 ms, 99th percentile=0.557 ms, 0.477546 calls per parent call
00:13:53.616:  ┗render_displays: min=0 ms, median=0.134 ms, max=44.629 ms, 99th percentile=0.865 ms

The very first line shows the total time it takes OBS to render each frame:
Code: 
00:13:53.616: obs_graphics_thread(16.6667 ms): min=0.063 ms, median=1.264 ms, max=523.602 ms, 99th percentile=25.742 ms, 96.9927% below 16.667 ms

97% of the frames are able to be grabbed within the 16.667ms timing window, meaning the remaining 3% are subject to being dropped because OBS just can't create them fast enough to send off to the encoder.

The majority of the issue comes from this:
Code: 
00:13:53.616:  ┃ ┃ ┗download_frame: min=0 ms, median=0.001 ms, max=65.259 ms, 99th percentile=29.192 ms, 0.477656 calls per parent call

This is literally just the frame grab operation. No reason it should take this long, it's just a matter of waiting in line for its turn in the GPU priority.



The reason you're probably seeing this more now with the new overlay is because there are new pipelines required when media (especially looping media) is involved. Every step in the chain adds more latency, which gets worse if it's not allowed a high enough priority.

As far as CPU usage going up when changing scenes, that's perfectly normal. OBS has to render the entirety of both scenes to perform the transition between the two, so that's twice the canvas size, along with all of the assets between the two scenes.
 
Last edited:
koala

koala

Active Member
@carlmmii if you explain that part of the logfile, please tell the people that the important value is the "99th percentile". It's the value 99% of all frames that are below, so it's a measure of the general maximum of all values, just without (usually irrelevant) spikes. If the 99th percentile of the time to download a frame is 29.192 ms, you just say 'your CPU takes 29,192 ms to download a frame". Since with 60 fps the maximum available time to download a frame is 16.66 ms, you cannot use this machine for 60 fps video.

By the way, 29.192 ms for download frame is a huge value. Usually, it's below 1 ms or not much over 1 ms. This may indicate the source of an issue. @Carson Daley, get gpu-z and post a screenshot of the first tab. Check the "Bus Interface" field. You have to have a x16 on both sides of the @. If you have a value below x16 at the right side of the @, your GPU card is not properly seated in the mainboard and not getting full pci-express bus speed.
 
C

Carson Daley

New Member
koala said:
@carlmmii if you explain that part of the logfile, please tell the people that the important value is the "99th percentile". It's the value 99% of all frames that are below, so it's a measure of the general maximum of all values, just without (usually irrelevant) spikes. If the 99th percentile of the time to download a frame is 29.192 ms, you just say 'your CPU takes 29,192 ms to download a frame". Since with 60 fps the maximum available time to download a frame is 16.66 ms, you cannot use this machine for 60 fps video.

By the way, 29.192 ms for download frame is a huge value. Usually, it's below 1 ms or not much over 1 ms. This may indicate the source of an issue. @Carson Daley, get gpu-z and post a screenshot of the first tab. Check the "Bus Interface" field. You have to have a x16 on both sides of the @. If you have a value below x16 at the right side of the @, your GPU card is not properly seated in the mainboard and not getting full pci-express bus speed.
Click to expand...
Ok so I heres the screenshot of gpuz for ya.
 

Attachments

  • gpuz screenshot.gif
    gpuz screenshot.gif
    25 KB · Views: 100
carlmmii

carlmmii

Active Member
It's the value 99% of all frames that are below, so it's a measure of the general maximum of all values, just without (usually irrelevant) spikes. If the 99th percentile of the time to download a frame is 29.192 ms, you just say 'your CPU takes 29,192 ms to download a frame". Since with 60 fps the maximum available time to download a frame is 16.66 ms, you cannot use this machine for 60 fps video.
Click to expand...
I was very careful with the way things are worded. You're right, the 99th percentile for that line is a measure of the maximum time of the lower 99% of all frame download operations. However, it's not the same as saying "your CPU takes <99th percentile> to download a frame" -- it takes up to that amount of time, but normally doesn't reach it (as evidenced by the median actually being 0.001ms). Only 3% of frames timings exceed the 16.667ms limit, as reported by the last percentage value on that line.

The takeaway is still the same -- without interruption, the GPU has no problem performing the frame grab operation. It's running into delays from external priorities, which comes down to just the common thread of "reduce in-game gpu loading" and "turn off game mode" so that OBS has the necessary GPU resources to perform its operations.
 
Last edited:
C

Carson Daley

New Member
carlmmii said:
I was very careful with the way things are worded. You're right, the 99th percentile for that line is a measure of the maximum time of the lower 99% of all frame download operations. However, it's not the same as saying "your CPU takes <99th percentile> to download a frame" -- it takes up to that amount of time, but normally doesn't reach it (as evidenced by the median actually being 0.001ms). Only 3% of frames timings exceed the 16.667ms limit, as reported by the last percentage value on that line.

The takeaway is still the same -- without interruption, the GPU has no problem performing the frame grab operation. It's running into delays from external priorities, which comes down to just the common thread of "reduce in-game gpu loading" and "turn off game mode" so that OBS has the necessary GPU resources to perform its operations.
Click to expand...
Jesus I have been wondering why no responses when my dumbass never sent the reply. So I turned off gamemode what else can I do to reduce gpu loading?
 
A

Agamemnus

Member
Check that you don't have browser sources. If you do, try remove them and see if that fixes it.

If it's still bad, your new video overlays... Try change them. If they have transparency, you need to use FFMPEG to do libvpx-vp9 encode. Default settings are fine. If they don't have transparency, I suggest using Handbrake, do x264 encode on Medium preset, change the FPS of the overlay videos to 30, and on Summary tab make format MP4, tick web-optimised box. On video tab tick box for fast decode, profile set to Main, level 4.0. If they're 1080p use CRF 22, or bitrate 2-pass with about 4Mbps.

Then take out all your overlay video sources, put in the new versions you just encoded. See if that helps.
 
K

koalaboy

New Member
Sorry for bumping this old thread, have OP find the solution?
I'm experiencing same issue now. I had an artist create me 4 overlays (starting, break, webcam frame, ending), and he delivers it in .webm , file size for each is only around 2-4Mb. After i put it into OBS as media source, my CPU usage bumped from 1% to 10% for OBS itself only. Trying to put all 4 overlays and my CPU usage is running at 40-50% for OBS only. This is so weird. I tried to use my friend's overlays which is .webm and size is 3Mb (similar to my overlays) and the CPU usage is only 3% for one scene, if i put all 4 overlays together, CPU usage is only 12% which is huge different of mine 40-50%.

What i've tried :
- disable/enable browser hardware acceleration on OBS advanced setting : did not help
- check/uncheck option 'close file when inactive' : did not help
- check/uncheck option 'use hardware decoding when available' : did not help
- try to put my overlays into streamelements, then put it into OBS as browser source, it bumped even higher, one overlays takes 13-17% CPU usage.
- put OBS process priority as above normal in advanced setting : did not help
- uninstall and reinstall fresh OBS Studio : did not help

I'm really confuse now, nothing works, i can not play game with 60% CPU reserved for OBS only, my game goes down from 250-290fps becomes 80-110fps. My PC is i7-9700k + RTX 3070, which is a good PC.

I contacted the artist who created my overlays, he said nothing's wrong with the overlays that he delivered to me, he even asked me what render output i want it to be, so he would try for me.

I think the problem is on my overlays file, isn't it? because whenever i use my friend's overlays, which is very similar format and file size, the max CPU usage is only 17%.
 
You must log in or register to reply here.
Top