obsproject
CPU usage in Stats tab inaccurate and consistently underreported.
Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
27.2.4
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/5VFgNqpO5YlrB3eQ
OBS Studio Crash Log URL
No response
Expected Behavior
CPU usage reported in OBS Stats panel and bottom right corner appears to be consistently underreported.
Here is a screenshot capturing both Task Manager and OBS at the same point in time.
__
Current Behavior
CPU usage is consistently under reported.
Steps to Reproduce
- Start OBS with usual sources.
- Measure CPU usage from both OBS stats and Task Manager
- Compare results. ...
Anything else we should know?
Windows 11 21H2 22000.675 Ryzen 5600x 16 gig of ram Geforce RTX 3700
Not for me
I'll do you one better. Stats dock shows <10% CPU usage in OBS but Task Manager shows 45%!!!! Thats not just underreporting its just plain incorrect. IDK what the value of the OBS Stats dock is tracking but man is it incorrect.
Specs:
Ryzen 9 5900HX
64GB 3200MHz RAM
RTX 3080
2x970 Pro Raid 0
@andmayfi92 The Stats dock only tracks the obs64.exe process. If you expand OBS Studio in task manager, you'll see a bunch of obs-browser-page.exe which are all your browser sources and browser docks.
System: Core i5-6500, 32GB RAM, RTX 2070 Super OS: Windows 11, 22H2 OBS: 27.2.4
Seeing similar wild inaccuracies here in both CPU and memory usage numbers (although mem is closer to accurate) and I don't even have any browser sources:
Judging by the performance impact on my system while OBS is running, I think the usage reported in task manager is more likely the correct number.
I get the same thing on macOS. I get the impression that the "stat" is only that of the renderer itself, not the application as a whole.
I see the same problem OBS 29.0.0
CPU i7-4720HQ, GPU Nvidia GeForce GTX 970
Hokay, best I can tell, this is a legitimate bug, but perhaps not in OBS. I'm not sure exactly what's happening, but windows seems like maybe it's lying to us (though what OBS is doing differently from other software, I'm not sure).
Initial testing setup:
- OBS 30.1.0 (built from git)
- fresh scene collection
- two scenes created: an empty scene, and a scene with half a dozen media sources stacked on each other, all playing webm files that include transparency (to force CPU decoding)
- tested on Windows 11 23H2
Testing:
- switch to empty scene, verify OBS uses minimal CPU
- switch to scene with media sources. Look at CPU usage (note that both task manager and system informer normalize by CPU count so that 100% CPU == 100% of all cores):
- task manager shows 4 - 6% CPU use for the main process (there's not really other processes, no browser sources, no muxer)
- cross check with System Informer (née Process Hacker), also shows 4 - 6% CPU on main process
- OBS' status display shows 0.1 to 0.2% CPU usage
These are very obviously different.
OBS also normalizes by CPU count. If I undo that normalization (I have 24 cores -- 8 core/16 threads performance, 8 economy), 0.1% to 0.2% turns into 2.4% to 4.8%, which is a whole lot closer to the right ballpark. It's difficult to say if it's actually giving the right value, due to differing sampling intervals and such, but it's at least closer. So what's going on?
The code in OBS (in os_cpu_usage_info_query inside platform-windows.c) is, basically:
- every 3 seconds, call
GetProcessTimes(GetCurrentProcess())to get user time and system time measurements, storing the previous measurement in a variable first - at the same time, call call
GetSystemTimeAsFileTime()to get the time of the measurement - calculate amount of CPU time used by adding
(current_sys_cpu - previous_sys_cpu)and(current_user_cpu - previous_user_cpu) - calculate the percentage of the total available CPU time was used by dividing that result by
(current_time - previous_time) - normalize the result by dividing by the number of CPU cores
- convert to a percent by multiplying by 100
Logically, this makes sense. Are the windows APIs not returning what we think they're returning? Well, there's two things I can think of... but first, just a quick note: GetSystemTimeAsFileTime and GetProcessTimes both return times in terms of a FILETIME structure, which is basically just an ugly representation of an unsigned 64-bit integer measuring units of "100ns" of time. Because everything is working in the same units of time, the units cancel and we can ignore the stupid "100ns" units. The math works out the same regardless if the units are 100ns or 1s or 1h, as long as they're the same.
Anyhow, possibility 1: we're only measuring the CPU utilization of a single OBS thread, rather than all threads, in the main process. I have no way to objectively determine whether this is the case, but the documentation for GetProcessTimes explicitly says:
The time that each of the threads of the process has executed in kernel mode is determined, and then all of those times are summed together to obtain this value. and The time that each of the threads of the process has executed in user mode is determined, and then all of those times are summed together to obtain this value. So unless that's really wrong and just nobody has noticed in the past two decades, that's probably not what is happening.
Possibility 2: CPU time used for the process is already normalized by CPU count. But again looking at the documentation for GetProcessTimes, it says:
Note that this value can exceed the amount of real time elapsed (between lpCreationTime and lpExitTime) if the process executes across multiple CPU cores. It being possible for the cumulative CPU time used to exceed the total runtime of the process, due to having multiple cores, is a solid indication that this is not the case, either.
So... I got nothing. The CPU value given by OBS (at least under what should be pretty normal conditions) is wrong to the point of uselessness, but I don't see an obvious reason why. It seems like GetProcessTimes is returning bad values, but that seems unlikely. So what am I missing?
