ugh. ok but not yet
It is running as a service
Yes they are all matching sticks...
Video stuttering, hardware probably underpowered but want to confirm configuration is fine
- Thread starter seth-feinberg
- Start date
ugh. ok but not yet
It is running as a service
Yes they are all matching sticks...
But if I have 1 camera enabled and that is H.264H, should I still suffer the issue? And I'm sorry but I dunno how to confirm if the BI Executables and storage folders are excluded from the virus... with some direction i'd be happy to provide that info (i'm sorry i don't deal with it ever)
Like just the injector into a cheaper switch? the one it's plugged into is a 1000 dollar switch, not super easy to just try another. However, i totally agree: that was the thing i messed with the most, i feel like it's gotta be firewall related. should I post some rules et al for the VLAN? feels outside the scope of the forum. Could we narrow it down somehow to definitely network?
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
This is a setting in windows defender, a quick google search will walk you through it.
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
Its really easy to try a cheap 50 dollar switch. it could be firewall related but in your setup the traffic should not be passing the firewall..an easy way to test is to simply disconnect from the firewall completely and see what happens. But excluding from av is critical and should be your first step. This is outlined in the help file.
Flintstone61
Known around here
Why is his Camera IP showing that funny string after the IP address? realmonitor... is he running an NVR as well with the 10.10. addresses?
Flintstone61
Known around here
an i7 4770 would play back better if the video writes were split across 2 drives with all those 8 MP cams. .... and if the frames were dropped to 10 were you can get away with it........like any garage cam or well lit area cam. MY LPR cams are running 12 FPS...
A lot going on here, some of it incorrect as others have already pointed out.
The OP is using 15 FPS in the camera GUI. The 30FPS in the BI screen is not used and irrelevant. That is for USB cameras as stated in the help file.
On the contrary, I do not think he is pushing it with an i7 4770. He is not maxing out the CPU. I suspect there are some other things he can do as well to bring CPU down. I have a 4th gen with double the cameras at a third of his CPU%.
A 4th gen can absolutely support hardware acceleration of H264 video. It is H265 it cannot support. But with substreams now a feature, many have found that the CPU% to offload to HA is more than the savings obtained. Plus he has all 8MP cams, so HA would probably get overloaded anyway on a 4th gen.
He has budget cameras that threw 8MP on a sensor designed for 2MP, so it is underpowered. Using H265 requires more camera processor power and we have seen some budget cams struggle if too many features are being used. H264 is the safe one. Plus his computer cannot use HA with H265 so if a camera accidentally was trying to use HA in BI it could throw issues.
Maybe with your old eyes you don't see a difference with H265 and VBR versus CBR LOL or maybe you have an ideal field of view that you can get by with it. There are tons of posts here where people post problems with their video without motion and once they change it to CBR is all clears up.
And we have seen people get crappy motion captures because the camera couldn't up the bitrate fast enough from VBR to CBR. I had cameras that under VBR would drop into the low 100s bitrate and then with motion jump up to 8,000 bitrate but not do it fast enough to get clean captures.
Storage is cheap - we don't want to chimp out on picture quality by lowering the opportunity to get clean images with VBR. I'd rather lose a week of storage but have good video than go back one extra week but the quality be poor.
H265 in theory provides more storage as it compresses differently, but part of that compression means it macro blocks big areas of the image that it thinks isn't moving. However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera in other areas like FPS and then it stutters.
In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My storage savings were less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.
The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution yet increases the camera CPU demand to develop these larger blocks.
In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess until the codec catches up to the motion. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is zero. Storage is computed based on multiplying bitrate, FPS, and resolution.
In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.
In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.
Digital zooming is never really good and not something we recommend, but you stand a better chance of some digital zoom with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.
H265 is one of those theory things that sounds good, but reality use is much different for many people.
For my use, it was literally only a few minutes difference for the same storage requirement, so I went with which one looked better.
Some people have a field of view or goals that allow H265 to be sufficient for their needs.
As always, YMMV.
Other than knowing if BI is excluded from the anti-virus software, everything else checked out so at this point as pointed out, this is a hardware or driver limitation somewhere in his system. Normally that is where I would have gone first but he outlined in his first post the expensive gear he has so we knew it wasn't the off-name cheapo stuff that has shown to cause problems.
The Amazon description is irrelevant as it relates here. You should leave the max rate alone in BI on this screen or have it be just a few FPS higher than what you run the cameras at. But if you set it lower, BI will up it. It doesn't have a big impact as this is more for USB cameras, but many have seen if the FPS here is closer to the camera FPS that RAM usage will go down a little bit.
Maybe you haven't realized that H265+ isn't working well. Post a screenshot from the BI camera status page - is your KEY value 1.00? I suspect it is lower in which case if you are using BI motion, you could miss motion.
Or one day you will wake up to a green screen caused by using the + codec that looks like this:
orPer the help file:
For the best chance at
compatibility, you should ensure that the stream is encoded as “simple” as possible via
direct camera settings. H.264 “main” profile without manufacturer-specific add-ons such as
+ or “smart” modes is most likely to be compatible.
One can use H265 if their testing shows for their field of view and situation it is better than H264. But keep in mind for a 4th gen that the OP has, HA cannot be used as it isn't supported on that processor.
Flintstone61
Known around here
Yep I woke up one day to a screen like that and it was one of my cheapo cams that only had H265+. It worked for almost a year and then one day bam the green screen.
Well I thought it worked until I added another camera that oversaw basically the same field of view and realized how much motion the H265+ camera was missing due to the dynamic iframe intervals @fenderman mentioned.
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
You don't need cat 6 for a camera, cat 5e is way more than needed.
Flintstone61
Known around here
Yep, I was there once too LOL. I believed all the hype and set mine to H265 and after being here awhile and learning from others, I did the test I mentioned above and similar to what you just did and was like yep going back to H264. The storage savings isn't worth the degradation.
I do have one camera though that just works better with H265 and fortunately the field of view and purpose is such that it isn't an issue like some of my other field of views.
Boy this thread really escalated while I was AFK. Let me try to address everything I missed:
I did a bunch of googling with the terms you said but mostly it seemed to be steering me to remote set up. I did do this though:
I'm also fine disabling the Wndows Firewall for testing purposes. which I did and the stuttering continued on the single camera I have enabled in BI. I think i should point out that there are TWO firewalls at play. The default included Windows Defender on the Blue Iris PC and the pfsense firewall which acts as my router. My network is AT&T Fiber ONT -> pfsense (running on a Dell 210) -> Unifi Switches -> Cameras/Blue Iris (same switch)
I'm a little fuzzy on the mechanics of this test. just plug the Blue Iris PC and a single camera with a POE injector into a cheapo switch? Directly from the pfsense router/firewall? plugging directly from the ONT into a cheapo switch would mean I didn't have DNS or Wifi or ....well anything.
Great question! I'm not sure. I checked all my cameras and they all have it. I think I was having some issues 3 years ago with the autodiscovery so I just figured out the string for the stream and put it in there. I don't have another NVR. 10.10.10.0/24 is my LAN, 10.10.30.0/24 is my cam vlan (that can only access clients in the same VLAN, no internet except for the Blue Iris PC). Do you think this an issue? It seems like the same string as the substream lower in that config:
So i have a 6tb hdd and a 240gb ssd in this blue iris machine. That IS one other thing that I changed since last set up. What type of activities should be on the ssd and which on the hdd? E is the 6tb hdd and C is the ssd
I tried to create new folders when I started back from scratch, but maybe leaving the old defined folders is what's causing the issues? Is there a trace dependents? where I can view which of these folders are used where?
Is this page the only place where these folders are used:
Please let me know if I've satisfied this check on the PC side. I still feel like I'd like to be more confident on the pfsense side....
What exactly do you mean re: the SSD drive. What about the SSD drives? just that BI machine has an SSD Drive? that the database is on an SSD Drive? anything else?
I did a bunch of googling with the terms you said but mostly it seemed to be steering me to remote set up. I did do this though:
I'm also fine disabling the Wndows Firewall for testing purposes. which I did and the stuttering continued on the single camera I have enabled in BI. I think i should point out that there are TWO firewalls at play. The default included Windows Defender on the Blue Iris PC and the pfsense firewall which acts as my router. My network is AT&T Fiber ONT -> pfsense (running on a Dell 210) -> Unifi Switches -> Cameras/Blue Iris (same switch)
I'm a little fuzzy on the mechanics of this test. just plug the Blue Iris PC and a single camera with a POE injector into a cheapo switch? Directly from the pfsense router/firewall? plugging directly from the ONT into a cheapo switch would mean I didn't have DNS or Wifi or ....well anything.
Great question! I'm not sure. I checked all my cameras and they all have it. I think I was having some issues 3 years ago with the autodiscovery so I just figured out the string for the stream and put it in there. I don't have another NVR. 10.10.10.0/24 is my LAN, 10.10.30.0/24 is my cam vlan (that can only access clients in the same VLAN, no internet except for the Blue Iris PC). Do you think this an issue? It seems like the same string as the substream lower in that config:
So i have a 6tb hdd and a 240gb ssd in this blue iris machine. That IS one other thing that I changed since last set up. What type of activities should be on the ssd and which on the hdd? E is the 6tb hdd and C is the ssd
I tried to create new folders when I started back from scratch, but maybe leaving the old defined folders is what's causing the issues? Is there a trace dependents? where I can view which of these folders are used where?
Is this page the only place where these folders are used:
Please let me know if I've satisfied this check on the PC side. I still feel like I'd like to be more confident on the pfsense side....
What exactly do you mean re: the SSD drive. What about the SSD drives? just that BI machine has an SSD Drive? that the database is on an SSD Drive? anything else?
Everything is Cat6a cable from Monoprice run fresh when I moved in in 2019. I don't know the gauge sorry...
Attachments
Oh that could be it.
You broke the number 1 rule of renaming the New, Alerts, and Stored folders and now it could be all effed up.
From the help file:
By default, there are four folders configured to store recordings—Database, New, Stored, and
Alerts. More precisely, only New and Stored are used to store video files; the Database folder
hosts a series of .dat files which are used by the software to keep track of the other folders,
and the Alerts folder will remain empty unless you have asked for hi-res alert images on the
Record tab in camera settings. These folders should not be renamed. The Alerts folder may
not be used otherwise for direct recording, even if you rename it.
So there are 3 folders you cannot rename - Alerts, New, and Stored - According to your screenshots you renamed the folders they go to - they need to be Alerts, New, and Stored. It are the Aux that you can do renaming. Even though you renamed them, internally they are still Alerts, New, Stored and now they have nowhere to go or are going to wrong places.
Also, you should have the database on the fastest drive. For most is it c:\blueiris\db - You could potentially be having issues.
Further, is your stored on the same drive as new? If so, it makes zero since to move files - wearing out the drive faster and using up CPU?
You only move from NEW to STORED if it is going to a NAS. If it is the same drive or drives within the computer, it is best to split cameras across the drives
You broke the number 1 rule of renaming the New, Alerts, and Stored folders and now it could be all effed up.
From the help file:
By default, there are four folders configured to store recordings—Database, New, Stored, and
Alerts. More precisely, only New and Stored are used to store video files; the Database folder
hosts a series of .dat files which are used by the software to keep track of the other folders,
and the Alerts folder will remain empty unless you have asked for hi-res alert images on the
Record tab in camera settings. These folders should not be renamed. The Alerts folder may
not be used otherwise for direct recording, even if you rename it.
So there are 3 folders you cannot rename - Alerts, New, and Stored - According to your screenshots you renamed the folders they go to - they need to be Alerts, New, and Stored. It are the Aux that you can do renaming. Even though you renamed them, internally they are still Alerts, New, Stored and now they have nowhere to go or are going to wrong places.
Also, you should have the database on the fastest drive. For most is it c:\blueiris\db - You could potentially be having issues.
Further, is your stored on the same drive as new? If so, it makes zero since to move files - wearing out the drive faster and using up CPU?
You only move from NEW to STORED if it is going to a NAS. If it is the same drive or drives within the computer, it is best to split cameras across the drives
Flintstone61
Known around here
IAmATeaf
Known around here
OakleyFreak
Getting the hang of it
- Jun 2, 2016
- 57
- 43
Just an observation.
Your bit rate is way low for the mpeg level you chose
Low bit rate will cause the jitter you described.
Remember H264 requires more bitrate the H265 on the same mpeg settings.
I would raise the level to at least match this guide.
Most often you will need to bump it up some.
Also view the vof in a browser and look for the jitter. Adjust the bit rate and monitor the live view .
You may find that a higher bit rate eliminates the jitter.
Your bit rate is way low for the mpeg level you chose
Low bit rate will cause the jitter you described.
Remember H264 requires more bitrate the H265 on the same mpeg settings.
I would raise the level to at least match this guide.
Most often you will need to bump it up some.
Also view the vof in a browser and look for the jitter. Adjust the bit rate and monitor the live view .
You may find that a higher bit rate eliminates the jitter.