5.2.7.0 - RTSP sub-streams for high-MP cameras

kklee

Pulling my weight
Joined
May 9, 2020
Messages
187
Reaction score
201
Location
Vancouver, BC
One other issue I've been seeing is a random crash when a motion trigger occurs. It' been happening for the last few versions, but every time I'm about to report it, a new version is released and I upgrade to it in the hopes that it's been fixed.

I've reconfigured all the camera streams for matching fps and iframes as well as upgraded to the just released 5.2.9.6. Hopefully that'll help.
 

beepsilver

Getting comfortable
Joined
Mar 9, 2014
Messages
863
Reaction score
982
Location
Nebraska
I just tried matching FPS & iframe (on main stream and substream) on one camera and did not see any difference, so am leaving the others as they are (low FPS on substream).... happy with the trade-off and don't use autocycle
I'll stick with Ken's recommendation which adds a point or two of CPU usage, but I did notice with 5.2.9.6 the stuttering no longer occurs (for me) even if main and sub fps/iframe don't match.
 

HineySmack

n3wb
Joined
Oct 18, 2017
Messages
7
Reaction score
4
I also have the issue where the clips show 42, 44, or 46 days. For example, one 8 hour clip shows 48d14h17m48s. And the long clip timestamps are also highlighted in green. Also, the time stamp in the lower right of the playback window when playing clips shows the wrong date and time. Sometimes that timestamp is a week or two older than the correct timestamp. I tried 5.2.9.7 and went back to 5.2.7.12. Tried DB repair as well.

Main and Sub stream configurations are working great, though.
 

Millstone

Getting the hang of it
Joined
Dec 22, 2014
Messages
105
Reaction score
25
I also have the issue where the clips show 42, 44, or 46 days. For example, one 8 hour clip shows 48d14h17m48s. And the long clip timestamps are also highlighted in green. Also, the time stamp in the lower right of the playback window when playing clips shows the wrong date and time. Sometimes that timestamp is a week or two older than the correct timestamp. I tried 5.2.9.7 and went back to 5.2.7.12. Tried DB repair as well.

Main and Sub stream configurations are working great, though.
What type of cameras do you have, what are their video settings
 

HineySmack

n3wb
Joined
Oct 18, 2017
Messages
7
Reaction score
4
What type of cameras do you have, what are their video settings
I have 6 Lorex LNB8005-C, 5 different Hikvision, and an Reolink. Lorex doesn't have frame interval settings. HIkvisions are set to H264, 15 fps, 15 frame interval. All cameras set to Intel hardware decode in BI.

Here's a screenshot of my Lorex config.
 

Attachments

Millstone

Getting the hang of it
Joined
Dec 22, 2014
Messages
105
Reaction score
25
I have 6 Lorex LNB8005-C, 5 different Hikvision, and an Reolink. Lorex doesn't have frame interval settings. HIkvisions are set to H264, 15 fps, 15 frame interval. All cameras set to Intel hardware decode in BI.

Here's a screenshot of my Lorex config.
Do the wacky clips only happen on the Lorex (Dahua) hardware?
 

HineySmack

n3wb
Joined
Oct 18, 2017
Messages
7
Reaction score
4
One other issue I've been seeing is a random crash when a motion trigger occurs. It' been happening for the last few versions, but every time I'm about to report it, a new version is released and I upgrade to it in the hopes that it's been fixed.

I've reconfigured all the camera streams for matching fps and iframes as well as upgraded to the just released 5.2.9.6. Hopefully that'll help.
I was having alot of crashes with BI5 (upgraded from BI4). The crashes started after trying to configure cameras and BI to improve CPU usage. The last entry in the BI log was MOTION before the crash. There were many configuration changes at play, and I couldn't figure out the cause, so I ended up reinstalling windows 10, and setting up BI as new without importing any BI or camera exports, and it stopped crashing. BI doesn't seem to like my Lorex (Dahua) cameras set to H265 either.
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,897
Reaction score
21,250
I was having alot of crashes with BI5 (upgraded from BI4). The crashes started after trying to configure cameras and BI to improve CPU usage. The last entry in the BI log was MOTION before the crash. There were many configuration changes at play, and I couldn't figure out the cause, so I ended up reinstalling windows 10, and setting up BI as new without importing any BI or camera exports, and it stopped crashing. BI doesn't seem to like my Lorex (Dahua) cameras set to H265 either.
You need to revert back to 5.2.6.5, that is the last known stable version. These new substream features are new and should not yet be used on a primary system.
 

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,432
Reaction score
47,555
Location
USA
I love the substream reduction it does to CPU!

This is probably a limitation of the program and maybe it will be a feature in a future update, but I was wondering if there is a way to get the alert JPEG snapshot that shows up in the all clips folder from the mainstream instead of substream?

The substream snapshot is fine for most of my cameras, but for the one with LPR, the snapshot from the mainstream is sufficient enough to read the plate without having to go to the video. When I turn the substream on for that camera, the snapshot is to pixelated.

I tried the store alert image as hi-res files, but that didn't do it.

1591415972339.png
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
I was wondering if there is a way to get the alert JPEG snapshot that shows up in the all clips folder from the mainstream instead of substream?
That would require quite a bit of work on Blue Iris's part. It is already decoding the sub stream so when the trigger happens it can easily just take one of the decoded frames and compress it as jpeg. In order to save a main stream frame as a jpeg, Blue Iris would need to seek back to the previous i-frame in the main stream, decode that, and then decode all the frames from there until the trigger point. This would add a significant resource usage spike at the least (possibly also a lot of new bugs).

I would recommend not configuring the sub stream for any cam where it is going to affect your usability, and in the case of your LPR cam it clearly does.
 

wittaj

IPCT Contributor
Joined
Apr 28, 2019
Messages
24,432
Reaction score
47,555
Location
USA
Thanks for the quick response!

I assumed that was the case and have kept that camera as a mainstream one. I guess I know not to expect that option in the near future.

So I guess that would impact the "Store alert images as high res files" then as well if substream was running?
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
I'm sure that setting just means it will save a native resolution snapshot to disk instead of just saving a thumbnail-size one in the clip database. If you had the sub stream running then the native resolution as far as it is concerned would be the sub stream's resolution.
 

tech101

Known around here
Joined
Mar 30, 2015
Messages
1,472
Reaction score
2,125
Location
SF BayArea, USA
I just started switching some of the camera to h265 from h264 any reason I should not do this and stick to h264 with the latest blueiris ? I know in the past we could only use h264. let me know if that is still the case thank you !
 

tech101

Known around here
Joined
Mar 30, 2015
Messages
1,472
Reaction score
2,125
Location
SF BayArea, USA
I think I am talking myself out of h265. .Since my pc is old for now. I did do h265 codec for one of the higher cameras.. 8mp one and that one struggles.. the main stream recording is sluggish.. with h265.. h264 no issues at all. Probably because of my slow / old pc ?
 

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,666
Reaction score
14,005
Location
USA
H.265 is more resource-intensive to decode, as you've noticed. Even on more recent computers it can be a challenge to decode a 4K @ 30 FPS H.265 stream without hardware acceleration.
 

tech101

Known around here
Joined
Mar 30, 2015
Messages
1,472
Reaction score
2,125
Location
SF BayArea, USA
H.265 is more resource-intensive to decode, as you've noticed. Even on more recent computers it can be a challenge to decode a 4K @ 30 FPS H.265 stream without hardware acceleration.
Thank you, Yes. Indeed it seems to take lot more resources than h264. I will stick with H264. I think only reason to do it will be to save disk space but again I think disk are so cheap if that ever even become a concern I will just add another disk. :) I am so happy though with the Sub Stream it is day an night now.. From 90 % down to 9 % :) When pc is sitting on the lock screen :) That too running everything on high res :D
 

IAmATeaf

Known around here
Joined
Jan 13, 2019
Messages
3,287
Reaction score
3,252
Location
United Kingdom
I’ve read the using H265 can halve the disk space usage, is that what people who use it have found? If that is the case then it could be worth having if you’re hardware supports it and has the required acceleration capabilities but then again storage is cheap.
 

biggen

Known around here
Joined
May 6, 2018
Messages
2,539
Reaction score
2,765
I use H265 on both my cameras at home running at 1080. Running BI in a VM with 4 cores puts the system at around 15% CPU usage on average for an old 3rd Gen Ivy Bridge CPU.

It is nice to save disk space gain long retention times.
 

IAmATeaf

Known around here
Joined
Jan 13, 2019
Messages
3,287
Reaction score
3,252
Location
United Kingdom
I use H265 on both my cameras at home running at 1080. Running BI in a VM with 4 cores puts the system at around 15% CPU usage on average for an old 3rd Gen Ivy Bridge CPU.

It is nice to save disk space gain long retention times.
So run it even though you have no hardware support for it?
 
Top