OBS weird GPU usage spikes

[STEPHANVS]

I am currently troubleshooting lagging frames. Running OBS with 3 rtspt sources via gstreamer for OBS (does not really matter, with built-in rtsp sources GPU usage is always on the peak level...) on a secondary monitor.

Since I am usually not at OBS when these happen live, I can only suspect high CPU usage, so I tried to offload as much as possible by setting gstreamer to use GPU.

Nevertheless I am testing OBS behaviour via AnyDesk. Remote PC is a i5-4460, 16GB RAM, ASUS GT640 with 4 monitor outputs, HDMI output is currently offline, so 3 desktops atm.

Screenshot is taken with OBS on a secondary monitor, focused window is the Task Manager on the main monitor. No stream or recording is running, only the 3 incoming rtmpt streams are processed. After OBS window looses focus a spike in GPU usage is observed. As soon as OBS regains window focus, the GPU spike is over. Issue is not present if OBS is on the main desktop monitor.

Does anyone have any idea why is this happening? Nothing is seen in the logs.

Edit: just noticed, there is an upload peak on the Ethernet graph too...

 

[STEPHANVS]

For the network traffic: most probably that is AnyDesk sending screen updates... Anyway, I am happy to provide any logs.

 

[STEPHANVS]

Using avdec_h264 (CPU decoder, using less CPU than using GPU decoder...) instead of d3d11h264dec (GPU decoder) for gstreamer will keep the 3D part of the GPU at ~70%, again, only on the second monitor, without window focus.

 

[johnny_bravo]

hello Stephanvs, i am struggling with the same. i upgraded my video card to a gtx1050, so 6 ip camera's should be no problem decoded by the GPU. But cup and gpu are both very high.

avdec_h264 seems less intensive than the GPU route. indeed strange.

i see also big difference when switching to multiview. Then CPU usage jumps.

 

[STEPHANVS]

hello Stephanvs, i am struggling with the same. i upgraded my video card to a gtx1050, so 6 ip camera's should be no problem decoded by the GPU. But cup and gpu are both very high.

avdec_h264 seems less intensive than the GPU route. indeed strange.

i see also big difference when switching to multiview. Then CPU usage jumps.

I just noticed, that this is my bugreport (?) thread, so I deleted everything that is present here already...

So, yesterday we had a PERFECT stream. I mean, no CPU or GPU spikes, video decode was offloaded to GPU (CPU usage was lower), and I noticed NO frame lags in the stream at all, with 100ms latency (so live view could have been totally ok on the projection screen). I am a man of faith, but when it comes to tech, I am straight scared of miracles like this...

@johnny_bravo, do you use any remote solution? Could that be the cause?

 

[johnny_bravo]

Stephanvs, everything local and bare iron, Nothing virtualised or so.

I am highly interested in your pipeline!

Tried about 4 different h264 codecs, all work fine but with 6 or 7 camera’s load get vers high and GPU usage does not seem to lower CPU usage.

 

[BluePeer]

if you have obs Open and focus there is load on the GPU so it go from idle to performance
means from 200mhz gpu speed to 1700mhz gpu speed (numbers related to the gpu settings)
the same in the other direction if load drops below a specific value the performance switch to idle

if the gpu clock down the 4% performance mode load rise up
the workload on gpu is the same like before but it use more of the gpu core related to the reduced speed

edit: sorry wired text
with OBS active gpu run with like 15% (12% OBS 3% other stuff) then the gpu run in Performance mode with like 1700mhz
if obs drops it 12% workload then the gpu go to idle and the 3% rise up to like 30% (the spike) related to the reduced MHZ from 1700 to 200

 

[STEPHANVS]

Stephanvs, everything local and bare iron, Nothing virtualised or so.

I am highly interested in your pipeline!

Tried about 4 different h264 codecs, all work fine but with 6 or 7 camera’s load get vers high and GPU usage does not seem to lower CPU usage.

My pipeline is:

rtspsrc location=rtspt://url latency=100 ! rtpjitterbuffer latency=0 ! rtph264depay ! h264parse ! d3d11h264dec ! video.

I do have to clarify, that the perfect stream was not as perfect, interesting frames here. Starts around 51:43, around 51:53 it is back not normal.
Maybe I still need to raise the latency, but to be honest this looks more like CPU (or GPU) issue than latency...

 

[BluePeer]

without the source (YT is transcode) it is hard to say whats right and wrong
the "image" itself look like that whats from the cam get? idk but that looks OK

thats totaly wrong its the Framerate feels like switch every frame have a personal frametime (individualism frames)
idk the config/bitrates/networks
but data needs to be transferd in a constant way (not in bits) over time
the result here looks like you have a 30 image buffer size for a 30fps stream and related to the transfer up/downs related to processing signal
result in a sometimes 15 sometimes 30 framerate
you see that in the hand movements sometime you see the hand go smooth 30cm Up and sometime it jumps 10cm and then smooth another 20cm

this issue can be related to a dynamic keyframe rate or a transferrate up/down
to erase that check that you buffer is bigger. for example if the cam make a 2sec/60 frame keyframe have a 4sec 120 frames buffer to compensate. if this works stable you can try reduce down to but not below 60frames on a 30fps stream with keyframe 2s
if you fine with that you can ignore, for me personal its AHHHHHH ^^

 

[STEPHANVS]

without the source (YT is transcode) it is hard to say whats right and wrong
the "image" itself look like that whats from the cam get? idk but that looks OK

thats totaly wrong its the Framerate feels like switch every frame have a personal frametime (individualism frames)
idk the config/bitrates/networks
but data needs to be transferd in a constant way (not in bits) over time
the result here looks like you have a 30 image buffer size for a 30fps stream and related to the transfer up/downs related to processing signal
result in a sometimes 15 sometimes 30 framerate
you see that in the hand movements sometime you see the hand go smooth 30cm Up and sometime it jumps 10cm and then smooth another 20cm

this issue can be related to a dynamic keyframe rate or a transferrate up/down
to erase that check that you buffer is bigger. for example if the cam make a 2sec/60 frame keyframe have a 4sec 120 frames buffer to compensate. if this works stable you can try reduce down to but not below 60frames on a 30fps stream with keyframe 2s
if you fine with that you can ignore, for me personal its AHHHHHH ^^

Yes, I original file also has what you try to describe here. However our setup is 25fps on every component of the stream system, starting with the IP camera, not sure if OBS has an internal frame rate, but encoding is again 25fps. So it should not be a framerate mismatch.

There are 2 possibilities here: CPU overload will skip frames on receiving or OBS (gstreamer) already receives the stream with skipped frames (or frames are so late, that the third frame is already shown...), which should not be the case using rtspt...

I don't know either...

 

[STEPHANVS]

I noticed, that the camera sent the h264 stream with high profile. I will set it to baseline and test.

 

[BluePeer]

simple for you for visual the software and environment you are using
have default base values for handling Data
every video and audio data a system "handle" goes after read/receive in to a buffer for Process
thats required by the base that there can only Processed in blocks
The size of this buffer are "auto" configuration in related to its bitrates, here starts a issue if you transfer them with variable rates this system Broke.
the cam's not send for example nonestop 6000 there send sometimes 4000 sometimes 8000
but the buffer system nonestop reads timebase the 6000 size this is not a problem if the 4000<->8000 flips is within the "time of buffering"
if thiss need 1ms longer this data skipped (this you see in missing frames)

so to erase this "issue" you need to increase the buffer size to a value related to the transfer system
this is a basic part of Setup and Config up this system

this is why twitch force it streamers for a 2s keyframe rate
the hole system is designed to make a buffer free stream with this setting
if you use auto keyframes for more eco on compress like 6-8 it alltime laggs on user side from time to time without transfer issues
simple on the missmatch of the time to transfer the 6 keyframes is longer then the play buffer


If you setup systems like this you need to make this test with settings and configurations by itself

its a equivalent to build a car engine itself you need to configure the fire times

 

[johnny_bravo]

rtspsrc location=rtspt://url latency=100 ! rtph264depay ! h264parse ! nvh264dec ! videoconvert ! video.

this is my pipeline.

the nvh264dec seems a little faster than d3d11h264dec. I omitted the jitter buffer, it is only useful for ump, not for tcp.

when I switch on the multiview modus, 3D GPU surges up.