Question / Help CPU Goes Very High

[RudyWisDOT]

Hello, I'm new to this forum and in using OBS Studio, but I'm having an odd situation with CPU usage. I'm hoping you might be able to shed some light on things.

My agency wishes to start using OBS Studio to do its webcasting via YouTube Live. We use a Roland VR-50HD video and audio switcher/mixer device for our media input. That gets ported to a computer via a USB 3.0 connection where the OSB Studio is running. All of this appears to work just fine; OSB sees the media device and ships it off to YouTube for livestreaming.

The problem we have, however, is that our plan was to use a laptop, as it's far more portable when we do remote broadcasts. Our initial tests indicated this shouldn't be a problem. But once we received the laptop and got it configured for production work, we noticed that the CPU usage would go from the low teen percentage to the 80% region, then go back down, then go up, etc. It seems to be quite inconsistent. And this happens when we're JUST RECORDING as well as streaming.

The oddity is, if we connect the hardware exactly the same way to an older tower PC, it processes at a very steady CPU rate; usually in the upper teens to low 20 percent.

The older tower PC has an i5-4750, 3.2 GHz Intel CPU with 8 GB of RAM on a 64 bit Windows 10 OS.
The new laptop is a ThinkPad P53s and has an i7-8565U, 1.8 GHz Intel CPU with 15 GB RAM, also on a 64 bit Windows 10 OS.

So, why is the CPU usage so inconsistent on the laptop when it should, in theory, have more processing power, more RAM, etc., than an older tower PC? And it's the exact same media input signal, operating system and infrastructure as the tower PC. There may be a problem with the video driver being used on the laptop (should be running the NVIDIA but appears to be using the Intel instead). I'm having our IT folks look into that. Could that have an effect on the CPU?

Any help would be greatly appreciated!

 

[Narcogen]

Please post a log with your issue! Here's how...

All other things being equal, desktop CPUs and GPUs are better suited to recording and streaming. The kind of constant load caused by running software encoding is going to trigger thermal throttling on your laptop, and I'd wager than the difference in clock speed between them is more than making up for any advantages your mobile i7 has over the older desktop i5.

If you want to do encoding on a laptop, you really want one that supports NVENC so you aren't dependent on the CPU.

 

[RudyWisDOT]

Thank you so much for your response and, again, my apologies for not following protocol. I'm new to this forum and using OBS, so please excuse my mistakes. Attached is the log file as requested. Plus, here is the address where it can be viewed online:

https://obsproject.com/logs/gPYiIBdOLfL-X10n

.

Although I do have some understanding of PCs, I'm by no means an expert with them. And within our department, we don't have control over the PCs, our IT folks have to handle that. So some of the things you may talk about or suggest could be above my head, but I'll do my best to have other folks with more knowledge look into any suggestions you or others might have.

But to give a quick background: When we looked into using a laptop for our recording/streaming both we and our IT folks were concerned that the hardware would have a problem. So the IT folks supplied us with the latest, greatest laptop we had, configured in the way we would need it, for testing purposes. We installed OBS Studio and ran that thing non-stop for several weeks, performing simultaneous streaming and recording at full 1080 in both mediums. These streams would go for a minimum of 1 hour, but most often we'd run them between 90 minutes and 2 hours. On a few occasions we streamed/recorded for several hours. In every scenario, the CPU never went over 15%.

Then the IT folks brought us the next version of laptops the department was going to be getting (the Lenovo ThinkPad P53s), which was even more robust than the previous laptop. Again, we put it through it's paces with multiple stream/recording scenarios at full HD for hours on end. It never broke a sweat of over 15% during any of those tests. So we were quite confident that this setup would work much better than our previous webcasting format had been going. And, therefore, we went ahead and got 2 laptops for the sole purpose of live streaming and recording.

But immediately upon doing our tests with the new gear we found the CPU running off the charts. We expect it to be something not set up right or the same way on the laptop as we had before. But it's very difficult to troubleshoot these when we have to rely on an IT person to handle all the work, and they're not always around or our problem isn't as high on their priority list. So we're trying to get all the information we can to go back to them and make any changes that are needed.

So, if there's anything you spot in these logs that would cause this problem, please let us know and we'll relay that information to our IT group and have them look at this.

Thanks in advance for your help!

 

[RudyWisDOT]

Please post a log with your issue! Here's how...

All other things being equal, desktop CPUs and GPUs are better suited to recording and streaming. The kind of constant load caused by running software encoding is going to trigger thermal throttling on your laptop, and I'd wager than the difference in clock speed between them is more than making up for any advantages your mobile i7 has over the older desktop i5.

If you want to do encoding on a laptop, you really want one that supports NVENC so you aren't dependent on the CPU.

Thank you so much for your response and, again, my apologies for not following protocol. I'm new to this forum and using OBS, so please excuse my mistakes. Attached is the log file as requested. Plus, here is the address where it can be viewed online:
https://obsproject.com/logs/gPYiIBdOLfL-X10n.

Although I do have some understanding of PCs, I'm by no means an expert with them. And within our department, we don't have control over the PCs, our IT folks have to handle that. So some of the things you may talk about or suggest could be above my head, but I'll do my best to have other folks with more knowledge look into any suggestions you or others might have.

But to give a quick background: When we looked into using a laptop for our recording/streaming both we and our IT folks were concerned that the hardware would have a problem. So the IT folks supplied us with the latest, greatest laptop we had, configured in the way we would need it, for testing purposes. We installed OBS Studio and ran that thing non-stop for several weeks, performing simultaneous streaming and recording at full 1080 in both mediums. These streams would go for a minimum of 1 hour, but most often we'd run them between 90 minutes and 2 hours. On a few occasions we streamed/recorded for several hours. In every scenario, the CPU never went over 15%.

Then the IT folks brought us the next version of laptops the department was going to be getting (the Lenovo ThinkPad P53s), which was even more robust than the previous laptop. Again, we put it through it's paces with multiple stream/recording scenarios at full HD for hours on end. It never broke a sweat of over 15% during any of those tests. So we were quite confident that this setup would work much better than our previous webcasting format had been going. And, therefore, we went ahead and got 2 laptops for the sole purpose of live streaming and recording.

But immediately upon doing our tests with the new gear we found the CPU running off the charts. We expect it to be something not set up right or the same way on the laptop as we had before. But it's very difficult to troubleshoot these when we have to rely on an IT person to handle all the work, and they're not always around or our problem isn't as high on their priority list. So we're trying to get all the information we can to go back to them and make any changes that are needed.

So, if there's anything you spot in these logs that would cause this problem, please let us know and we'll relay that information to our IT group and have them look at this.

Thanks in advance for your help!

 

[Narcogen]

Need a logfile that contains an output session to comment more fully.

To do that:

Open OBS. Begin recording or streaming, whatever your planned activity is. Let it run until you see your issue (high CPU utilization, stutter, whatever the problem is). Stop the output session. From the Help menu, upload the Current log without quitting OBS.

I have no idea without logfiles from the relevant sessions what, if anything, was different between the test sessions on the ThinkPad P53s were everything was fine, and the production sessions on the ThinkPad P53s that showed high CPU utilization. You say you were testing simultaneous streaming and recording in 1080 on this equipment, but one logfile shows scaling down to 720 (the first one).

However, for this work in particular, I would say that it's not entirely accurate to say the lower clock speed CPU in the ThinkPad is more robust for use with OBS than the machine you had before, and that a laptop with an Nvidia GPU that supports at least the Pascal or Volta, but preferably the Turing hardware NVENC encoder, would be a better choice to almost any laptop without one of those chips, no matter how much newer or faster the CPU is.

For the older Nvidia GPUs (Volta or Pascal) their encoders are clearly superior when doing local recordings where you can allow for large files, but can fall behind a strong CPU encoder when streaming, especially in low bandwidth situations.

The equipment you're running on has an Nvidia chip, but it does not appear to me that it supports NVENC, or that NVENC support is enabled:

13:39:11.621: LoadLibrary failed for 'nvEncodeAPI64.dll': The specified module could not be found.

It appears that the Nvidia GPU in this laptop does NOT support NVENC, which makes it significantly less desirable for your task than.. well, almost any other Nvidia chipset that does.

Video Encode and Decode GPU Support Matrix

Find the related video encoding and decoding support for all NVIDIA GPU products.

developer.nvidia.com

In fact one of the only reasons to prefer the Quadro line, aimed at enterprise customers, than the GeForce line, aimed at consumers and gamers, is that the Quadro GPUs from Nvidia that DO support NVENC usually support an unlimited number of NVENC sessions, making those cards suitable for running multiple simultaneous encoding sessions, where most, if not all, of the GeForce cards are limited to two simultaneous sessions. However it sounds to me like two sessions would be enough for you, and you only need two if you want to record and stream at two different levels of quality.


For the latest (Turing) encoder in the 1650 Super or 1660Ti, the NVENC encoder is very competitive quality-wise even for streaming applications, and is generally considered as good if not better than the recommended CPU preset for most x264 tasks, which is "veryfast".

The P53 is absolutely a decent performer for general purpose use. It is not particularly well suited for live video encoding tasks. Any laptop with a Turing encoder chip, such as those aimed at gamers, are better suited for live video encoding. Some are cheaper than the P53!

https://www.nvidia.com/en-us/shop/geforce/laptop/?page=1&limit=9&locale=en-us&gpu=GTX%201660%20Ti&category=LAPTOP

 

[RudyWisDOT]

Need a logfile that contains an output session to comment more fully.

To do that:

Open OBS. Begin recording or streaming, whatever your planned activity is. Let it run until you see your issue (high CPU utilization, stutter, whatever the problem is). Stop the output session. From the Help menu, upload the Current log without quitting OBS.

I have no idea without logfiles from the relevant sessions what, if anything, was different between the test sessions on the ThinkPad P53s were everything was fine, and the production sessions on the ThinkPad P53s that showed high CPU utilization. You say you were testing simultaneous streaming and recording in 1080 on this equipment, but one logfile shows scaling down to 720 (the first one).

However, for this work in particular, I would say that it's not entirely accurate to say the lower clock speed CPU in the ThinkPad is more robust for use with OBS than the machine you had before, and that a laptop with an Nvidia GPU that supports at least the Pascal or Volta, but preferably the Turing hardware NVENC encoder, would be a better choice to almost any laptop without one of those chips, no matter how much newer or faster the CPU is.

For the older Nvidia GPUs (Volta or Pascal) their encoders are clearly superior when doing local recordings where you can allow for large files, but can fall behind a strong CPU encoder when streaming, especially in low bandwidth situations.

The equipment you're running on has an Nvidia chip, but it does not appear to me that it supports NVENC, or that NVENC support is enabled:

13:39:11.621: LoadLibrary failed for 'nvEncodeAPI64.dll': The specified module could not be found.

It appears that the Nvidia GPU in this laptop does NOT support NVENC, which makes it significantly less desirable for your task than.. well, almost any other Nvidia chipset that does.

Video Encode and Decode GPU Support Matrix

Find the related video encoding and decoding support for all NVIDIA GPU products.

developer.nvidia.com

In fact one of the only reasons to prefer the Quadro line, aimed at enterprise customers, than the GeForce line, aimed at consumers and gamers, is that the Quadro GPUs from Nvidia that DO support NVENC usually support an unlimited number of NVENC sessions, making those cards suitable for running multiple simultaneous encoding sessions, where most, if not all, of the GeForce cards are limited to two simultaneous sessions. However it sounds to me like two sessions would be enough for you, and you only need two if you want to record and stream at two different levels of quality.


For the latest (Turing) encoder in the 1650 Super or 1660Ti, the NVENC encoder is very competitive quality-wise even for streaming applications, and is generally considered as good if not better than the recommended CPU preset for most x264 tasks, which is "veryfast".

The P53 is absolutely a decent performer for general purpose use. It is not particularly well suited for live video encoding tasks. Any laptop with a Turing encoder chip, such as those aimed at gamers, are better suited for live video encoding. Some are cheaper than the P53!

https://www.nvidia.com/en-us/shop/geforce/laptop/?page=1&limit=9&locale=en-us&gpu=GTX%201660%20Ti&category=LAPTOP

Thanks for your help and this info. Attached is a log file taken immediately after a simultaneous streaming/recording session had the CPU start jumping extremely high (or you can view the log here: https://obsproject.com/logs/dBm884_Jkq5-F7Dg). Hopefully this is what you need to see something that could help pinpoint the culprit.

When there was more camera activity happening, or more information from a PowerPoint slide show displayed on the screen, the CPU would begin rising quickly.

You are correct about the difference in the video outputs. With our initial tests on the trial laptops we used several months ago we recorded and streamed the video at 1080, and that's how we initially configured our new laptops as well. But in trying to figure out what is causing the anomaly with the CPU, we changed that so it would record at 1080 but stream at 720. However, I changed it back to both at 1080 for this test, hopefully that shows up properly in the log.

And for what it's worth, my coworker brought in his personal laptop this morning and we installed OBS on it and ran the same streaming/recording type test that I just ran here. His laptop has almost identical components as our work laptop. His laptop stayed a cool 10 to 15 percent CPU usage for over an hour (and that's exactly what we experienced in our testing with the trial laptops a few months ago). And just to be sure we weren't running into some strange fluke, we immediately took the USB video input from his laptop and put it into our work laptop and started streaming/recording to the same YouTube session. And within 5 minutes it ran up to 80% CPU. We unplugged the video input from our work laptop and back into my coworkers laptop and, again, his laptop streamed/recorded at only 10 to 15 percent.

Every test we run seems to point to something not being set correctly in the two new work laptops. But I'm not savvy enough to know what I should have our IT folks look for to solve the problem. Hopefully your skills and expertise might point us in the right direction.

Again, thanks so much for you invaluable help!

 

[RudyWisDOT]

Thanks for your help and this info. Attached is a log file taken immediately after a simultaneous streaming/recording session had the CPU start jumping extremely high (or you can view the log here: https://obsproject.com/logs/dBm884_Jkq5-F7Dg). Hopefully this is what you need to see something that could help pinpoint the culprit.

When there was more camera activity happening, or more information from a PowerPoint slide show displayed on the screen, the CPU would begin rising quickly.

You are correct about the difference in the video outputs. With our initial tests on the trial laptops we used several months ago we recorded and streamed the video at 1080, and that's how we initially configured our new laptops as well. But in trying to figure out what is causing the anomaly with the CPU, we changed that so it would record at 1080 but stream at 720. However, I changed it back to both at 1080 for this test, hopefully that shows up properly in the log.

And for what it's worth, my coworker brought in his personal laptop this morning and we installed OBS on it and ran the same streaming/recording type test that I just ran here. His laptop has almost identical components as our work laptop. His laptop stayed a cool 10 to 15 percent CPU usage for over an hour (and that's exactly what we experienced in our testing with the trial laptops a few months ago). And just to be sure we weren't running into some strange fluke, we immediately took the USB video input from his laptop and put it into our work laptop and started streaming/recording to the same YouTube session. And within 5 minutes it ran up to 80% CPU. We unplugged the video input from our work laptop and back into my coworkers laptop and, again, his laptop streamed/recorded at only 10 to 15 percent.

Every test we run seems to point to something not being set correctly in the two new work laptops. But I'm not savvy enough to know what I should have our IT folks look for to solve the problem. Hopefully your skills and expertise might point us in the right direction.

Again, thanks so much for you invaluable help!

Also, my coworker's laptop does have a different video chipset. His uses the NVIDIA GeForce MX150.

 

[Narcogen]

Also, my coworker's laptop does have a different video chipset. His uses the NVIDIA GeForce MX150.

The MX150 and the Quadro P520 use the same Nvidia chipset, the GP108. Neither support NVENC.

The Nvidia models with this feature most commonly begin with the designation GTX or RTX.

Quadro models that include the newest Turing encoder have a chipset designation that begins with TU. (Volta is GV, Pascal, the next oldest generation, is GP. GP108 is the only variation of the Pascal chipset that does not include NVENC, and it is usually the least expensive variation available.

 

[Narcogen]

Thanks for your help and this info. Attached is a log file taken immediately after a simultaneous streaming/recording session had the CPU start jumping extremely high (or you can view the log here: https://obsproject.com/logs/dBm884_Jkq5-F7Dg). Hopefully this is what you need to see something that could help pinpoint the culprit.

OK, here we go:

14:42:09.219: Windows Version: 10.0 Build 17134 (revision: 1246; 64-bit)

To start, this version of Windows is very old (more than 2 years) and this specific version has long been known to have performance issues with OBS. If you are unable to upgrade to at least build 1809 (build 17763), then you need to go into Windows display settings and turn Game Mode off. This feature is supposed to allow GPU-hungry apps to prioritize resources, but exclude OBS from doing so. It was fixed in later builds. So you can either update, or just turn the feature off. Either is better than leaving it on. Updating and turning it on is better than not updating and turning it off.

15:00:21.258: Output 'simple_file_output': Number of lagged frames due to rendering lag/stalls: 50 (0.2%)
15:00:21.260: ==== Recording Stop ================================================
15:00:21.269: Video stopped, number of skipped frames due to encoding lag: 425/32008 (1.3%)

The above lines describe OBS' performance during the encoder session. The top line, rendering lag, is the number of frames "dropped" or lost by OBS during the rendering phase. OBS is a compositor and video switcher. Since it can combine multiple sources in layers, it "renders" a frame before it is encoded. This task requires the GPU, and a stronger GPU will do a better job at it. The frame is rendered at the base or canvas resolution specified in the video settings. .2% is not much, so you don't appear to have an issue here, but if you did, here would be the suggestions. Keep in mind that a lot of the information on the site and in the forum ends up pertaining to game capture because lots of users do that, but that won't be relevant to you-- you're basically just capturing a video source and rendering + encoding it.

If you were having a problem here, this page would suggest how to resolve it:

GPU Overload Issues

The second line, encoding lag, is relevant to the work OBS is giving your CPU to encode the stream before sending it over the network. The settings that affect this are your output resolution, your framerate, the rate control, and the CPU preset.

You've selected the right rate control for video streaming, which is CBR. Most platforms require this. The bitrate you've selected, though, is fairly low for 1080p30 video. Between 3000-6000 Kbps would be better. If you run the Auto-Configuration Wizard from the Tools menu it will attempt to test your network connection and suggest a bitrate, but it will use Twitch for this test, so the result may not be relevant for you as you are streaming to YouTube.

Choose live encoder settings, bitrates, and resolutions - YouTube Help

Choose a quality that will result in a reliable stream based on your internet connection. Read this article to learn how.

support.google.com

You've selected the "veryfast" CPU preset, which is usually a sensible default, and going for better quality than that by selecting a slower preset usually increases CPU load significantly without a justifiable improvement in image quality. This is where special hardware encoders like the NVENC chips in Nvidia cards come in, because they do this job because they are specially made for it, and so they incur *no* increase of load on your CPU.

I believe your laptop should also support QuickSync (QSV) encoding, which should be as less load and almost as good as x264 encoding, so you can also experiment with that.

You've got a small amount there, but it's probably just enough to be noticeable. If this is only happening with both canvas and output set to 1080, it should go away almost if not entirely if you scale output to 720p. If you had a hardware encoder, though, you wouldn't need to do this. Also your selected bitrate is more appropriate for 720p30 than 1080p30.

And since this means that your CPU is maxing out, at least some threads, some of the time, it may mean you're having heat issues, and they may get worse the longer the session goes on. This page is for general suggestions on resolving this issue:

General Performance and Encoding Issues

14:54:56.642: adding 21 milliseconds of audio buffering, total audio buffering is now 21 milliseconds (source: Video Capture Device 2)
14:54:56.684: adding 64 milliseconds of audio buffering, total audio buffering is now 85 milliseconds (source: Video Capture Device 2)
14:57:02.277: adding 170 milliseconds of audio buffering, total audio buffering is now 256 milliseconds (source: Video Capture Device 2)

The above log lines occur just as you start your streaming, and indicates your laptop is falling behind in capturing audio from your video capture device. This usually indicates either CPU overload, as the CPU is used to decode the video stream from a USB capture device, or the USB controller responsible for the port your video capture device is plugged into is overloaded. This can be the case if your port is insufficient speed (USB2 when you need USB3 for HD video) or has too many other devices plugged into it.

256ms isn't massive, but it's going to be noticeable, and if it gets too high it can indicate a performance problem that may cause dropped frames and desynchronized audio.

 

[RudyWisDOT]

OK, here we go:

14:42:09.219: Windows Version: 10.0 Build 17134 (revision: 1246; 64-bit)

To start, this version of Windows is very old (more than 2 years) and this specific version has long been known to have performance issues with OBS. If you are unable to upgrade to at least build 1809 (build 17763), then you need to go into Windows display settings and turn Game Mode off. This feature is supposed to allow GPU-hungry apps to prioritize resources, but exclude OBS from doing so. It was fixed in later builds. So you can either update, or just turn the feature off. Either is better than leaving it on. Updating and turning it on is better than not updating and turning it off.

15:00:21.258: Output 'simple_file_output': Number of lagged frames due to rendering lag/stalls: 50 (0.2%)
15:00:21.260: ==== Recording Stop ================================================
15:00:21.269: Video stopped, number of skipped frames due to encoding lag: 425/32008 (1.3%)

The above lines describe OBS' performance during the encoder session. The top line, rendering lag, is the number of frames "dropped" or lost by OBS during the rendering phase. OBS is a compositor and video switcher. Since it can combine multiple sources in layers, it "renders" a frame before it is encoded. This task requires the GPU, and a stronger GPU will do a better job at it. The frame is rendered at the base or canvas resolution specified in the video settings. .2% is not much, so you don't appear to have an issue here, but if you did, here would be the suggestions. Keep in mind that a lot of the information on the site and in the forum ends up pertaining to game capture because lots of users do that, but that won't be relevant to you-- you're basically just capturing a video source and rendering + encoding it.

If you were having a problem here, this page would suggest how to resolve it:

GPU Overload Issues

The second line, encoding lag, is relevant to the work OBS is giving your CPU to encode the stream before sending it over the network. The settings that affect this are your output resolution, your framerate, the rate control, and the CPU preset.

You've selected the right rate control for video streaming, which is CBR. Most platforms require this. The bitrate you've selected, though, is fairly low for 1080p30 video. Between 3000-6000 Kbps would be better. If you run the Auto-Configuration Wizard from the Tools menu it will attempt to test your network connection and suggest a bitrate, but it will use Twitch for this test, so the result may not be relevant for you as you are streaming to YouTube.

Choose live encoder settings, bitrates, and resolutions - YouTube Help

Choose a quality that will result in a reliable stream based on your internet connection. Read this article to learn how.

support.google.com

You've selected the "veryfast" CPU preset, which is usually a sensible default, and going for better quality than that by selecting a slower preset usually increases CPU load significantly without a justifiable improvement in image quality. This is where special hardware encoders like the NVENC chips in Nvidia cards come in, because they do this job because they are specially made for it, and so they incur *no* increase of load on your CPU.

I believe your laptop should also support QuickSync (QSV) encoding, which should be as less load and almost as good as x264 encoding, so you can also experiment with that.

You've got a small amount there, but it's probably just enough to be noticeable. If this is only happening with both canvas and output set to 1080, it should go away almost if not entirely if you scale output to 720p. If you had a hardware encoder, though, you wouldn't need to do this. Also your selected bitrate is more appropriate for 720p30 than 1080p30.

And since this means that your CPU is maxing out, at least some threads, some of the time, it may mean you're having heat issues, and they may get worse the longer the session goes on. This page is for general suggestions on resolving this issue:

General Performance and Encoding Issues

14:54:56.642: adding 21 milliseconds of audio buffering, total audio buffering is now 21 milliseconds (source: Video Capture Device 2)
14:54:56.684: adding 64 milliseconds of audio buffering, total audio buffering is now 85 milliseconds (source: Video Capture Device 2)
14:57:02.277: adding 170 milliseconds of audio buffering, total audio buffering is now 256 milliseconds (source: Video Capture Device 2)

The above log lines occur just as you start your streaming, and indicates your laptop is falling behind in capturing audio from your video capture device. This usually indicates either CPU overload, as the CPU is used to decode the video stream from a USB capture device, or the USB controller responsible for the port your video capture device is plugged into is overloaded. This can be the case if your port is insufficient speed (USB2 when you need USB3 for HD video) or has too many other devices plugged into it.

256ms isn't massive, but it's going to be noticeable, and if it gets too high it can indicate a performance problem that may cause dropped frames and desynchronized audio.

Thanks for the extensive information, it's greatly appreciated.

Yes, that particular OS build is old. Government agencies tend to lag behind the rest of the world while we wait for the IT staff to test things to death before they issue a release. Plus, since our budget is very tight, we make due with the smallest staff and purchase equipment and software in longer cycles than what the private sector might do. Nonetheless, we are planning on moving to Build 1909, and one of the two webcasting laptops already has that installed for us to test ahead of the rest of the department. But that one fails, too, same as the older version. The attached log file (https://obsproject.com/logs/bV5Wnod5S7Kex950) was taken from a stream/recording done today on that newer OS. Within 4 minutes of the start, it had climbed up to 60% and 70%.

Oddly enough, when we did some more tests earlier this morning, both laptops (1909 and 1803 Builds) behaved themselves. They worked just like our tests did months ago, staying under 15% CPU usage for a long time. We were totally baffled. Then, before lunch, I set up another live stream and, as you may see in the log, shortly after it was started, the CPU when crazy.

To answer a couple more of your questions/concerns: The values we've plugged in for streaming are those recommended by YouTube. We can certainly experiment with them, but I'm not expecting subtle changes in audio bitrate would cause a 60% upswing in the CPU usage. And the only USB devices being used during these webcasts are one coming from the Roland VR-50HD switcher/mixer and a standard mouse. Again, we could disconnect the mouse, but I can't see how that device, which isn't used once the stream or recording has begun, would put that much stress on the CPU.

So, I know that we may not have the coolest gear around, and these items aren't designed to work in this capacity. But all I can tell you is that we tested this exact model laptop with the same OS Build for several months - running multiple hours-long streams/recordings - and never did the CPU go above 20%. Most of the work is being done on the Roland switcher device. The only thing the laptop has to do is encode and upload the processed video coming into it. So from our angle, we're pretty sure this does work, as we have dozens of hours under our belt proving it already has. Since these laptops are configured exactly the same way as our test laptop was, and since we're running the very same input signal from the Roland, we fully expected the output to be the same. It's a mystery to us why these newer laptops are running so very different than the test model.

I know without having hands on the actual gear and watching what's happening in person, it's difficult to figure out what's going on. And we're probably more befuddled than anyone. But I do appreciate any advice or suggestions. Thanks.

 

[Narcogen]

To answer a couple more of your questions/concerns: The values we've plugged in for streaming are those recommended by YouTube. We can certainly experiment with them, but I'm not expecting subtle changes in audio bitrate would cause a 60% upswing in the CPU usage. And the only USB devices being used during these webcasts are one coming from the Roland VR-50HD switcher/mixer and a standard mouse. Again, we could disconnect the mouse, but I can't see how that device, which isn't used once the stream or recording has begun, would put that much stress on the CPU.

Will read the new log shortly but wanted to get this out first. These are your encoder settings, from the log:

14:42:32.965: [x264 encoder: 'simple_h264_stream'] preset: veryfast
14:42:32.965: [x264 encoder: 'simple_h264_stream'] settings:
14:42:32.965: rate_control: CBR
14:42:32.965: bitrate: 2500
14:42:32.965: buffer size: 2500
14:42:32.965: crf: 0
14:42:32.965: fps_num: 30000
14:42:32.965: fps_den: 1001
14:42:32.965: width: 1920
14:42:32.965: height: 1080
14:42:32.965: keyint: 59

These are YouTube's live encoder suggestions from their site (not to be confused with the specs for uploading. Live specs are here:

1080p

• Resolution: 1920x1080
• Video Bitrate Range: 3,000-6,000 Kbps

Choose live encoder settings, bitrates, and resolutions - YouTube Help

Choose a quality that will result in a reliable stream based on your internet connection. Read this article to learn how.

support.google.com

Above you've specified 1920x1080 bit a bitrate of 2500. This is 500 Kbps below the minimum suggested by YouTube for 1920x1080 of 3000 Kbps, , and I would consider their suggestions here low. Note that this is the *video* bitrate, not the audio bitrate, and the bitrate specified in OBS is the *total* bitrate. The audio bitrate in OBS is set separately. The 2500 figure is only "ok" for 720p30, as YouTube's suggestion for that is a bitrate of 1500-4000:

720p

• Resolution: 1280x720
• Video Bitrate Range: 1,500-4,000 Kbps

The other values are fine.

 

[Narcogen]

Most of the work is being done on the Roland switcher device.

This is not entirely true, but a lot of people believe it. A lot of people believe that using a capture device reduces load on a PC. This is not really true.

What the Roland is doing for you is handling the video switching-- you can have multiple video inputs into the device, but the computer only has to decode one at a time. But it still has to decode it. The Roland does not and cannot send an uncompressed video signal over USB3, so the PC still has to decode it, then it has to render that source, it has to composite that source along with any other sources you might add in OBS, and THEN it has to encode. The reason why GPUs with hardware encoders are so valuable for this is because it means that OBS only has to use the CPU for audio and source inputs, the GPU's general capacity for rendering, and the GPU's specific hardware encoders for encoding. That Roland is a great device, and it's super to have, but it's performing a necessary task of getting video into the PC-- it's not taking load OFF the PC. This is a common misconception.

What *would* be more load on your PC is if you had to input ALL your video sources to it, and have OBS operate as a switcher. That WOULD be more load, but only because you'd have the current amount of load multiplied by each of your video sources. (And you'd need either three separate capture devices, or a PCI device with multiple HDMI or SDI inputs.) Using the Roland in this manner is broadly similar to the task that gaming streamers are doing when they capture console footage with a device that takes a single HDMI signal and sends it to OBS through USB3.

 

[Narcogen]

Also, there's no output session in that latest log-- just OBS starting up and shutting down.

For the performance information to register, you need to open OBS, start a session, wait till the problem is observed (high CPU load in your case) then stop the output session and upload the Current log from the Help menu before quitting OBS. (If you quit OBS by mistake, you can reopen it, but then you have to upload the Last log instead of the Current log.)

 

[Narcogen]

Were the long, successful test sessions on this hardware representative of typical use? Any change in content compared to those tests-- amount of on-screen motion, lighting, anything like that?

 

[RudyWisDOT]

Hey there. Thanks, again, for looking at all this. Sorry that all the data wasn't in the latest log file. I was pretty sure I selected to upload the current log, and I had not shut down the session yet. Regardless, here is a new one taken this morning: https://obsproject.com/logs/U7RT6X0L8yB7cbSz.

I want to be sure I mention here that this was a RECORDING session only. I was NOT streaming this test. I know some of the items you mention above are dealing with settings optimized for a stream to YouTube, but in this case (and other tests we've done in the past) I wasn't asking OBS to perform a livestream, simply record the incoming video/audio signal to the hard drive, and it still sent the CPU into cycles of 10% to 80%. So I would think that even if we don't have some of the streaming settings in the sweet spot, that shouldn't have an impact on the CPU in this case, correct?

At any rate, to answer your other questions about the type of tests we're performing: We're doing sessions that are very, very indicative of a real production webcast for us. In most cases we set up a PowerPoint slide show that has transitions happening every 30 seconds or so and loops continuously (to run unattended as long as our webcast session test). That is composited in the Roland device as a window that takes up the majority of the frame. Then we have a video camera either pointed out a window or at the data being displayed in the lower right-hand corner of OBS (to have a record of the CPU usage), which is composited as a much smaller window in the same frame - kind of like a picture-in-picture type thing. And we have some elevator music pumping through the PPT to simulate an audio signal. This is all very common for us. And as a matter of fact, a real production probably has more activity happening on the video camera and/or slides than what we're doing in these tests. Sometimes during a live recording or broadcast we'll switch over to full screen of the video camera when the no slides are being shown. But it's close enough that we felt very confident we're putting it through its paces.

These tests on the new laptops are using the same video and audio inputs as we did before. And for the log you're seeing now, that was just a single camera full screen, but it was zoomed in on the data corner of the OBS software, so very, very little was happening on screen. Once in a while I'd wave my hand in front of it to show some movement. That will cause an uptick in CPU usage of a few percentage points, which is to be expected. But then it goes back down again.

But like in this case, all I was doing was recording a low-activity video camera from the Roland device to save on our laptop computer, and about 15 minutes into the recording, without anything changing with the camera, the CPU started climbing. It did that a few times, then I stopped recording, sent the log file and shut it all down.

So, streaming or just recording only, we're still having problems with the CPU running away for no apparent reason that we can find.

 

[Narcogen]

Ok, from the logfile:

10:27:00.388: Output 'simple_file_output': Number of lagged frames due to rendering lag/stalls: 30 (0.1%)
10:27:00.389: Video stopped, number of skipped frames due to encoding lag: 458/36065 (1.3%)

Those figures are exactly as from before.

I want to be sure I mention here that this was a RECORDING session only. I was NOT streaming this test. I know some of the items you mention above are dealing with settings optimized for a stream to YouTube, but in this case (and other tests we've done in the past) I wasn't asking OBS to perform a livestream, simply record the incoming video/audio signal to the hard drive, and it still sent the CPU into cycles of 10% to 80%. So I would think that even if we don't have some of the streaming settings in the sweet spot, that shouldn't have an impact on the CPU in this case, correct?

No. That is not how anything works. A recording session is an encoding session. It may have different parameters than a streaming session, but it is still an encoding session. Your GPU is incapable of doing the encoding, so the job falls on the CPU along with everything else.

Simultaneous sessions would be more load, but the encoding lag line indicates that *even with recording only* you are overloading your CPU 1% of the time. That's not much, but that is absolutely not inconsistent with seeing load up to 80%. The idea that a 1.8ghz laptop could do this job and be UNDER 10% is probably not realistic unless you're looking at a static frame.

At any rate, to answer your other questions about the type of tests we're performing: We're doing sessions that are very, very indicative of a real production webcast for us. In most cases we set up a PowerPoint slide show that has transitions happening every 30 seconds or so and loops continuously (to run unattended as long as our webcast session test). That is composited in the Roland device as a window that takes up the majority of the frame.

Are you... are you sending powerpoint output from the laptop running OBS out to the Roland... and then back again? Is this just for testing purposes, or is that the actual production setup?

And as a matter of fact, a real production probably has more activity happening on the video camera and/or slides than what we're doing in these tests. Sometimes during a live recording or broadcast we'll switch over to full screen of the video camera when the no slides are being shown. But it's close enough that we felt very confident we're putting it through its paces.

That's kind of what I'm getting at. 1% encoding lag isn't much, but if the test is less demanding than the actual production, then you are further under the required spec than you think you are.

I can't just from the logfile either what else is going on the with the computer, or how much load your content is really putting on OBS.

OBS is accurately reporting the number of frames dropped because of CPU overload. That doesn't mean OBS' encoding requirements are the cause of the overload, it just means OBS wanted CPU cycles it could not get.

When CPU usage cycles, does Task Manager identify OBS as the process using the extra cycles? And this is separate from any change in content in OBS that would be associated with that uptick?

The normal response for someone in this situation would be to update Windows, at least on the theory that interaction between a new version of OBS and an old version of Win10 might be less than optimal (this is known to happen). The other would be that it would be much less relevant what's going on with the CPU load if it wasn't being used for encoding.

 

[RudyWisDOT]

I'm attaching a photo of what we have going on in our tests - and this is very similar to the tests we did during our trials in the fall of last year, and very much a real-world scenario for our webcasts and recordings.

The computer on the left is playing a YouTube video, which is output into the Roland device (item in the center). The camera on the right (pointed at the OBS information area in the lower-right hand corner) also has its output going into the Roland device. The two video signals and audio are mixed, composited and ported out through the USB 3.0 cable into our new laptop (on the right) running OBS Studio. I've placed the recording that the computer made on YouTube if you want to see how it actually looks in real life and how the laptop performed: https://www.youtube.com/watch?v=tP5uH09mgOU&

As you'll see from the video in the upper right-hand corner, throughout the entire session the CPU never went above 13% as far as I can see, and that was what we experienced with all of our test trials done last year. Why it's working beautifully today is a mystery.

The only difference between our tests and real life is that we normally have a PowerPoint slideshow in the larger window instead of a YouTube video. And the camera is normally focused on the presenter, not the computer screen. Still, the amount of video and audio signal being captured and processed in these tests is very, very common to the real thing. Occasionally we have sessions when it's just a presenter (no PowerPoint or other visual material) in 1920 x 1080 resolution, or just audio and a PowerPoint presentation or screen capture using a software program, etc. But in all our tests and in all real-world scenarios, all media inputs go into the Roland device first and a single video/audio data stream is sent to the OBS laptop via the USB 3.0.

For what it's worth, I'm including the log file from the recording published on the aforementioned YouTube address.

 

[Narcogen]

Just trying to build a catalog so I can try and trace performance over time, but it's a bit difficult.

From the thread, first log:

https://obsproject.com/logs/gPYiIBdOLfL-X10n

Shows your video hardware, your video settings (starts with 1080p canvas and 720p output, then changes to 1080p canvas ,1080p output). There's no output session, so no record of performance.

Second log:

https://obsproject.com/logs/dBm884_Jkq5-F7Dg

1080p canvas, 1080p output. CBR stream using 2500 Kbps bitrate and veryfast CPU preset. Minor rendering lag, 1.3% encoding lag. Encoding lag would probably be eliminated either by a drop in resolution (to, say, 900p or 720p) or going from veryfast to superfast preset at a cost of quality.

Third log:

https://obsproject.com/logs/bV5Wnod5S7Kex950

1080p canvas, 720p output. No output session, no performance data.

Fourth log:

https://obsproject.com/logs/U7RT6X0L8yB7cbSz

1080p canvas, 720p output. CBR stream using 4000 Kbps bitrate, almost identical figures for both rendering lag and encoding lag. Indicates that change to output resolution alone may be insufficient to cover all possibilities for CPU overload during encoding, and change to faster preset (with quality tradeoff) may be necessary to reduce CPU load.

I have to admit I'm sort of confused by the need to have the Roland, which does no encoding, but not a GPU with hardware encoding capabilities. Is the entire setup 1) presentation and 2) one camera? Are there uses that have different setups than this?

I can't explain the disparity in performance you describe-- the only logs you've got with output sessions both show similar performance, which is a small drop in frames-- and while such a low percentage does not mean you can't do what you're trying with these laptops, it's certainly not compatible with the idea of doing it at only 13% CPU load-- especially not where you're running and rendering powerpoint, sending that feed to the Roland, *recapturing* that same video frame, putting it in OBS, *rendering it again* and then encoding it, all on a machine without a hardware video encoder. The problem is that the Roland is designed to do with special hardware everything that OBS is designed to do, *except encode*. And the hardware you're running OBS on lacks the one piece of hardware that OBS would use to ensure that the job of encoding would not affect the PC's performance.

I think if you switch to superfast and can accept the quality it gives you, that would probably eliminate your issue, and if you can't change your hardware setup because you're committed to it/don't control it, that may be your best way through.

 

[RudyWisDOT]

I'm not sure I know what you mean by "recapturing" and "rendering again" the PowerPoint slides (or other visual media) that may be displayed during a conference or meeting. And it sounds as if you're questioning why we're using the Roland device when OBS is capable of doing the same thing. But I'm pretty sure the OBS interface is not capable of handling the AV demands we will place on it under normal working conditions.

It's very common for us to have at least 3 audio inputs (sometimes more than that). With the Roland, we can run up to 4 microphones plus a couple of other audio inputs into it with full control over all aspects of each audio source. It's also not uncommon for us to have a couple of cameras (one on the presenter and another on a sign language interpreter). Again, the Roland can handle that with no problem, from several different video connection types. And, on the fly, we can rearrange the position of each video input and/or switch to full screen of one of those cameras.

Another thing we run into quite often is that we'll have multiple presenters with different laptop/computers as their device for showing a PowerPoint presentation on a large monitor or screen. Sometimes those slide shows are in the 4:3 aspect ratio, other times they're in 16:9. With the Roland, we can adjust to whatever dimension they give us and re-composite the frame to hold all that material on the fly. And, just to really make it exciting, it's not uncommon for us to have a mix of either HDMI or VGA outputs coming into the Roland. Again, it's no problem to make those quick changes with just the flick of a few buttons and and adjustment or two.

So, without know what we'll have coming to us when we start a session, we may have multiple changes in the number of presenters, a change in the type of video connection coming to us, and different audio signals, yet in under a minute (usually in just few seconds), we've restructured the Roland to accommodate all of it; never having had to stop the recording/webcast session.

If the OBS is truly capable of doing that, then we'll certainly entertain that thought. But I don't see how it could handle that without having a separate audio mixer and separate video switcher/mixer to provide those AV input signals.

And just so you don't think I'm nuts, yesterday I recorded a day-long conference. I had multiple presenters with 8 different PowerPoint presentations. Some were 16:9 and several were 4:3 aspect ratio. I also had one HD camera on the presenter at all times. On a few occasions, the PowerPoint was no longer displayed and then I immediately switched over to full screen of the video camera. I had 3 separate microphones; one at a podium and two handheld that were used to capture comments/questions around the room (needing to control the volume each time a different person used a mic).

I was using our older webcast tower computer (with Build 1803) and recorded 4 separate OBS sessions at 1080 canvas, 1080 output. They ranged anywhere from 30 minutes to 2 hours long. And during all those recordings, the CPU never went above 20% when a PPT presentation and smaller video window of the presenter were being captured; and it never went above 34% when I switched to full 1920 x 1080 from just the video camera. Unfortunately I didn't have the ability to save a log file of one of those sessions.

So I don't know what I can say except, I know we can consistently get those kinds of results using our older computer. Every time I use it, those are typical readings I see. And we had readings that were at least that or better during the several months we tested the trial laptops. I just wish I knew more about all the intricacies of these computers to find out what's different now on the laptops than what we had for testing purposes.

If there are any specific tests/parameters you'd like me to do so that you have a better base from which to build on, I'm happy to do that. Just let me know exactly what you need of me and I'll give it my best shot.

In the meantime, we have our IT folks looking into this situation to be sure that all drivers, BIOS configurations and other hardware/firmware settings are the same as those used in the test laptops. I hope we can find something: I have a live broadcast scheduled on March 4th in a location 50 miles away. I'd really like to take the laptop for ease of transport and setup.

Nonetheless, again I thank you, thank you, thank you! for taking the time to help with this. Anything you can do to help track down a fix is greatly appreciated.

 

[Narcogen]

If you have that many extra hardware inputs (cameras or microphones) then yes the Roland is great for that, because you'd need to add audio interfaces to the laptop in order to have OBS do that job. It's just that for the desktop/powerpoint content, your pipeline is convoluted-- OBS could capture that directly, instead you're having powerpoint send that outside the machine, into the Roland, and then brought back in from the Roland to OBS. That's why I asked whether the typical setup was one microphone, one camera, and one powerpoint-- because the Roland is absolutely overkill for that, and OBS could pretty much handle that on its own. But the additional inputs would require additional hardware, so for that flexibility, yeah, something like the Roland is preferable for lots of reasons.

Just in the interest of clarity:

Sometimes those slide shows are in the 4:3 aspect ratio, other times they're in 16:9. With the Roland, we can adjust to whatever dimension they give us and re-composite the frame to hold all that material on the fly.

That's pretty trivial to do in OBS. It is a video compositor. If you capture its display of a powerpoint against a 1080p canvas, you'll get 4:3 or 16:9 depending on what the slideshow is; there's no reason to do anything.

But I don't see how it could handle that without having a separate audio mixer and separate video switcher/mixer to provide those AV input signals.

OBS is a software switcher. What it would need would be the hardware inputs.

I have absolute faith in the results you got on your desktop computer; they fall completely in line from what I expect OBS could do under those conditions, with setups like that.

Looking at synthetic benchmarks the laptop CPU could be perceived as a slight step upwards... but its base clock speed is significantly lower, the number of cores is the same, and I could easily imagine a situation where thermal throttling comes into play, and the device comes down off of its turbo boost speed and starts giving significantly poorer performance. Since encoding is almost certainly going to be the hardest job you're asking the laptop to do during one of these sessions, that's where a hardware encoder as part of a GPU would be of the most value. I don't know if that's what is causing your issue, but I wouldn't be surprised if it was. It might be a good idea to track temperatures during a session and see if the spikes in CPU usage correspond with higher temps.

How to Monitor Your Computer’s CPU Temperature

There are two groups of users worried about the temperature of their computer: overclockers… and pretty much anybody with a powerful laptop. Those things just cook you! So have you ever wondered exactly what temperature your CPU is running at?

www.howtogeek.com