I am assembling a BI server from my older parts stash. I have everything built on a SuperMicro motherboard with Xeon E3-1240 v5 @3.50GHz. The motherboard also supports Core i3-7320 @4.10GHz. The Xeon is twice the cores/threads as the i3 but lacks Intel Quick Sync support. Would it be worth spending $50-75 (still negotiating with another parts hoarder) to get QS support. I am hoping to run up to nine 8MP cameras on it. What else am I missing with the Xeon?
How important is Quick Sync?
- Thread starter gregorio
- Start date
With the use of substreams now, quicksync isn't really needed. It's primary purpose is for Hardware acceleration to take some of the video processing off of the CPU. In many instances now, the CPU demand to offload the graphics to an internal GPU is more than the CPU savings because of the substreams.
Further, many people have had issues with Hardware Acceleration and BI since around 5.4.5.X, so many of us no longer even use hardware acceleration.
Further, many people have had issues with Hardware Acceleration and BI since around 5.4.5.X, so many of us no longer even use hardware acceleration.
Flintstone61
Known around here
Thanks- The Xeon processor is already on the motherboard so I'll start building and see what happens. I can add a half dozen 1MP and maybe four 8MP on my bench to test.
Will the lack of QS support cause problems with H.256 decoding? I am having trouble using that compression scheme on a Lorex branded 8MP bullet. It does not decode. H.264H works fine.
That is probably an issue with the camera and the setup.
I have a 4th gen CPU that doesn't have QS support for H265 and I can run H265 just fine. I just cannot run hardware acceleration for H265.
In fact, if you run headless, you can even completely disable the internal GPU altogether and it still works.
As I said, if you run the substreams, QS is not needed.
I have a 4th gen CPU that doesn't have QS support for H265 and I can run H265 just fine. I just cannot run hardware acceleration for H265.
In fact, if you run headless, you can even completely disable the internal GPU altogether and it still works.
As I said, if you run the substreams, QS is not needed.
Right - I generally follow this for my configs.
ipcamtalk.com
The problem might indeed be the cameras. I have read there is newer firmware that has some H265 improvements. I've looked for the firmware but there is nothing from Lorex and I cannot get them to accept the Dahua version using the instructions here.
Lorex LNB8005B-C and Dahua firmware (Solved with instructions)
Right now, locally I am running low res streams six 1MP Hikvision and two of the 8MP Lorex cams. I also added three low res streams from remote Unifi Protect cameras. Blue Iris says the Xeon CPU is chugging along between 45-60% with all eleven cameras on screen. Switching to one of the 8MP cameras at 15FPS 4K, the CPU load drops to 32-40%.
Optimizing Blue Iris's CPU Usage
Blue Iris uses a lot of CPU time. In most Blue Iris installations, your CPU is the limiting factor which determines how many cameras you can have. As such, it is extremely important to optimize your configuration to ensure you can get the most out of your system while consuming the least...
The problem might indeed be the cameras. I have read there is newer firmware that has some H265 improvements. I've looked for the firmware but there is nothing from Lorex and I cannot get them to accept the Dahua version using the instructions here.
Lorex LNB8005B-C and Dahua firmware (Solved with instructions)
Right now, locally I am running low res streams six 1MP Hikvision and two of the 8MP Lorex cams. I also added three low res streams from remote Unifi Protect cameras. Blue Iris says the Xeon CPU is chugging along between 45-60% with all eleven cameras on screen. Switching to one of the 8MP cameras at 15FPS 4K, the CPU load drops to 32-40%.
SouthernYankee
IPCT Contributor
I have 64GB in the machine but BI is reporting only 1.35GB being used according to the status at the bottom.
Task Manager shows 9% CPU usage with BI minimized. One BI task is 9% and the other is zero until I restore the screen but then I cannot see Task Manager. Only 5 other tasks using no more than 0.1% or 0.2% CPU. Rest are all zero.
SouthernYankee
IPCT Contributor
memory is good. I was just checking as some users only have 8GB in old machinrs, this causes problems.
you need to set the cameras main stream and substream to the same value. Also only use 15 FPS. You are not shooting an auto race. Use a key (iframe)the same as the frame rate
I use a simple h.264 for all my cameras, yes more data but easier (less cpu) to decode.
you need to set the cameras main stream and substream to the same value. Also only use 15 FPS. You are not shooting an auto race. Use a key (iframe)the same as the frame rate
I use a simple h.264 for all my cameras, yes more data but easier (less cpu) to decode.
Flintstone61
Known around here
drop your frame rates. no need for 30FPS. cut them in 1/2 and watch the CPU
Flintstone61
Known around here
match your substream frame rates with the corresoponding Main stream framerates.
check to see if Substreams are running.
check to see if Substreams are running.
Flintstone61
Known around here
shit can h265 and see how that affects the cpu running at 45-60-% or whatever you said.
The three high frame rate cams are on another system not directly managed by me. They have it set up to better read license plates. I am only borrowing the RTSP streams for testing. The one cam that does not have matching FPS on both streams is managed there as well so I have no ability to change that, either.
The 8MP are at 15FPS now and I'll reconfigure the 1MP cams to 15FPS and keep testing. I missed the key frame setting. Thanks.
The 8MP are at 15FPS now and I'll reconfigure the 1MP cams to 15FPS and keep testing. I missed the key frame setting. Thanks.
If you are going to be bringing those cams into your system, inform them that shutter speed is more important than FPS for reading plates. My plate reader is 8FPS for a vehicle that is in the frame less than a second.
At night, we have to run a very fast shutter speed (1/2,000) and in B/W with IR and the image will be black. All you will see are head/tail lights and the plate. Some people can get away with color if they have enough street lights, but most of us cannot. Here is a representative sample of plates I get at night of vehicles traveling about 45MPH at 175 feet from my 2MP camera and 8 FPS:
At night, we have to run a very fast shutter speed (1/2,000) and in B/W with IR and the image will be black. All you will see are head/tail lights and the plate. Some people can get away with color if they have enough street lights, but most of us cannot. Here is a representative sample of plates I get at night of vehicles traveling about 45MPH at 175 feet from my 2MP camera and 8 FPS:
Thanks. I don't have control over that system but they spent a lot of time optimizing it for their needs. I know they are using off some axis illumination to increase shutter speeds at night. No plans to bring them into BI.
I think I have reached the best balance of CPU and image quality with this combination. Anything below 15FPs on the Hik cameras was unacceptable and the CPU savings was not there either. Had a difficult time setting i-frame interval. It either would not take or would always reset to some default. I think I have it stable for now. Might be firmware. Looking into that now.
Overall, for a Frankensystem made from 10 year old parts, this should provide very acceptable performance.
Overall, for a Frankensystem made from 10 year old parts, this should provide very acceptable performance.