BI 100% CPU running in Parallels VM

[105437]

I need help getting BI to run under my Parallels Windows 7 VM. I have two cameras and right now the app is showing 100%. What can I do to help reduce the CPU utilization? Thanks!

 

[fenderman]

I need help getting BI to run under my Parallels Windows 7 VM. I have two cameras and right now the app is showing 100%. What can I do to help reduce the CPU utilization? Thanks!

record direct to disc..

 

[105437]

record direct to disc..

Yes, I already have that set. Right now it's pretty stable at 80% - 85%.

 

[fenderman]

Yes, I already have that set. Right now it's pretty stable at 80% - 85%.

What is your cpu? what is the camera resolution?

 

[105437]

CPU is 2.3 Ghz i7 on the Macbook running Parallels. Cameras are running 2048 x 1536 @ 15 fps.

 

[fenderman]

From the help file:

If ever you see the CPU usage reach 100% and stay there for any extended period of time, that means that your CPU does not have power to do all that you are asking of it in real time. And, since video capture is more or less a real time application, a maxed-out CPU means that Blue Iris performance will suffer as a result. Here are some things to look at in order to attempt to minimize CPU utilization:​

• What other software is running on the same PC? Can any of that be eliminated?​
• Can you lower the capture frame rate on one or more of your cameras? For an IP camera, this also must be done from within the camera's own browser interface--ideally the framerate that the IP camera is sending should match the value you specify in Blue Iris.​
• Can you lower the resolution on one or more of your cameras?​
• Can you remove one or more video overlay graphics or text? Transparent items use the most CPU.​
• Can you switch to the BVR recording format? This is more efficient than either MP4 or WMV.​
• If you are running multiple cameras, can one of them be eliminated?​
• Can you minimize the Blue Iris window? When it is minimized, no CPU time is used to draw to the screen.​
• If you are running as a service, do not leave the console instance running when unnecessary​
• Turn off Windows Aero (switch to Windows Vista or 7 "basic" display mode). It is pretty, but it uses more CPU cycles to draw to the screen in this mode.​
• Are you using the pre-trigger frames option on the Record tab? This will use more CPU.​
• If you switch from H.264 to XVID codec recording, this will save CPU time on slower processors. Install that from XVID.org. When installed, it will become an option on the Record/Format page in camera properties.​
• For an IP camera, you can eliminate re-encoding video altogether during recording by using the Direct-To-Disc option on the Recording format page.​

 

[105437]

Thanks @fenderman... I minimized the GUI and that seemed to help a good bit. It's now running around 65% - 75%.

 

[panhead]

If you have the ability to replace the HD with an SSD, this will also decrease the amount of CPU you are using. I am running BI in a Parallels VM with 12 cameras, and my CPU usage is 20-30% with no GUI and 60-70% with GUI. I upgraded the primary HD to an SSD and run the instance from there with an attached virtual HD on regular HD for storage. I am recording in H.264 with BI as the DVR for viewing while writing.

 

[105437]

If you have the ability to replace the HD with an SSD, this will also decrease the amount of CPU you are using. I am running BI in a Parallels VM with 12 cameras, and my CPU usage is 20-30% with no GUI and 60-70% with GUI. I upgraded the primary HD to an SSD and run the instance from there with an attached virtual HD on regular HD for storage. I am recording in H.264 with BI as the DVR for viewing while writing.

Thanks @panhead... I do have an SSD in the MacBook Pro that is hosting the VM. I have attached my record settings... maybe you'll spot something.

 

[panhead]

Sorry for the late reply...long holiday weekend. I think the reason you are seeing the high CPU is because of the pre-trigger buffer size. While it is nice to have the frames before the trigger, this will cause additional CPU usage. The only other difference I see between you settings and mine is the direct-to-disc vs mine being re-encode. I would think your setting would have less overhead than the re-encoding.

 

[fenderman]

Sorry for the late reply...long holiday weekend. I think the reason you are seeing the high CPU is because of the pre-trigger buffer size. While it is nice to have the frames before the trigger, this will cause additional CPU usage. The only other difference I see between you settings and mine is the direct-to-disc vs mine being re-encode. I would think your setting would have less overhead than the re-encoding.

You are likely running low resolution cameras and that explains the low cpu consumption...

Sent via Taptalk

 

[ruppmeister]

Sorry for the late reply...long holiday weekend. I think the reason you are seeing the high CPU is because of the pre-trigger buffer size. While it is nice to have the frames before the trigger, this will cause additional CPU usage. The only other difference I see between you settings and mine is the direct-to-disc vs mine being re-encode. I would think your setting would have less overhead than the re-encoding.

You have to keep in mind that the pre-trigger frame buffer is measured by frames and not seconds. In this case, if for instance the OP is running their cams at 15 fps, then you are only looking at 3 seconds pre-trigger, which is not that much in reality.

 

[nejakejnick]

You could try to set Variable bitrate on your camera, it can save a lot of bandwidth and also CPU (~15%).
Not sure in which case pre-buffer consumes CPU, but I have not measured any additional usage even with 150 frames.

The problem with BlueIris is that it consumes so much CPU even when it does absolutelly nothing with the stream, in my case 53% cpu time (usage of one core) (2048 x 1536 @ 15 fps, 500kB/s, on Pentium E5200@2.5Ghz), in comparison iVMS-4200 PCNVR from Hikvision can record the stream with 0%

 

[fenderman]

You could try to set Variable bitrate on your camera, it can save a lot of bandwidth and also CPU (~15%).
Not sure in which case pre-buffer consumes CPU, but I have not measured any additional usage even with 150 frames.

The problem with BlueIris is that it consumes so much CPU even when it does absolutelly nothing with the stream, in my case 53% cpu time (usage of one core) (2048 x 1536 @ 15 fps, 500kB/s, on Pentium E5200@2.5Ghz), in comparison iVMS-4200 PCNVR from Hikvision can record the stream with 0%

Its not doing nothing with the stream. Its analyzing the stream for motion detection - if you have it enabled. Additionally, ivms displays the substream in matrix view unlike blue iris that is displaying the full stream. CPU consumption has always been the Achilles heel of Blue Iris, however, new power efficient pc's are cheaper than 100 per camera licenses.

 

[nejakejnick]

Its not doing nothing with the stream. Its analyzing the stream for motion detection - if you have it enabled. Additionally, ivms displays the substream in matrix view unlike blue iris that is displaying the full stream. CPU consumption has always been the Achilles heel of Blue Iris, however, new power efficient pc's are cheaper than 100 per camera licenses.

You could display the substream in BlueIris as well, and use motion detection on it, and trigger alarms on the main stream which would be saved to disk. But the problem is that it would not help you much exactly because of that inefficiency I described. It is clearly possible to implement a direct record without use of CPU, I don't know why BlueIris does not have it.

 

[fenderman]

It is not as simple as you make it seem... the reason your method of displaying the substream and recording the main is in efficient is because the software still has to process both streams in some fashion. With ivms, the software is simply pulling the substream until you go full screen or the camera triggers a recording. Blue iris is always pulling the main stream and recording it (if you are using pretrigger frames)....it can be done as others have done it, exacq, for example, but it takes lots of work and needs to be specific for each camera to work properly.

 

[nejakejnick]

It is not as simple as you make it seem... the reason your method of displaying the substream and recording the main is in efficient is because the software still has to process both streams in some fashion. With ivms, the software is simply pulling the substream until you go full screen or the camera triggers a recording. Blue iris is always pulling the main stream and recording it (if you are using pretrigger frames)....it can be done as others have done it, exacq, for example, but it takes lots of work and needs to be specific for each camera to work properly.

The only reason why it is inefficient is because it was implemented inefficiently.

iVMS is pulling whatever it needs, it may be only substream, or only mainstream or both, depending on your settings and camera view.

You can configure iVMS to always record the main stream, that takes ~0,03% of CPU time.
If you do the same with BlueIris, it will take ~53%.
If you use ffmpeg from command line, it will take ~0.5% (ffmpeg.exe -i rtsp://admin:12345@192.168.2.38:554/Streaming/Channels/1 -acodec copy -vcodec copy D:/abc.mp4)

The thing is, you may not need motion detection or any other processing of the main stream in BlueIris, you may want to only record it and get alarms triggered externally, or from the substream processing.

 

[fenderman]

The only reason why it is inefficient is because it was implemented inefficiently.

iVMS is pulling whatever it needs, it may be only substream, or only mainstream or both, depending on your settings and camera view.

You can configure iVMS to always record the main stream, that takes ~0,03% of CPU time.
If you do the same with BlueIris, it will take ~53%.
If you use ffmpeg from command line, it will take ~0.5% (ffmpeg.exe -i rtsp://admin:12345@192.168.2.38:554/Streaming/Channels/1 -acodec copy -vcodec copy D:/abc.mp4)

The thing is, you may not need motion detection or any other processing of the main stream in BlueIris, you may want to only record it and get alarms triggered externally, or from the substream processing.

Well if you know how to implement it more efficiently then provide the developer with instructions...if it were that easy he would have already done it..Its more complex then it looks like on the surface.

 

[nejakejnick]

Well if you know how to implement it more efficiently then provide the developer with instructions...if it were that easy he would have already done it..Its more complex then it looks like on the surface.

I am not saying that it is easy, it could be, but if not enough people want more effective direct record, then it will not be done no matter how easy it is, new fancy features will get implemented instead, you can always buy a better PC or lower fps anyway, right?

 

[fenderman]

I am not saying that it is easy, it could be, but if not enough people want more effective direct record, then it will not be done no matter how easy it is, new fancy features will get implemented instead, you can always buy a better PC or lower fps anyway, right?

That is exactly the case. Based on some email communication in the past, I know the developer is working on some optimization but I doubt it will ever be as efficient as ivms or exacq...but yes, the "fancy features" are exactly what brings most users to blue iris. If we simply wanted to record video 24/7 any old NVR or ivms would suit the need. Powerful Pc's are cheap at least here in the US. As an example I just picked up an hp business elitedesk 800 g1 i5-4590 for 317. This machine had an in service date of August 2015 so its a less than a month old and will have a next business day warranty until august 2018.....