New user four questions

[Ferguson]

I have been experimenting and reading and experimenting some more but would like to cheat a bit and ask some questions, if I may.

For perspective I have six 4K cameras around the house, and am interested in 24x7 recording, with a priority toward easy search/scrub if I want to see what happened at some point, and also would like to get reasonably reliable motion detection working on a couple of the cameras. Most of this seems to be working fine in testing. I am coming from Luxriot by the way. The cameras are running at 4fps.

The questions:

1) I think I get how to manage space. My goal is easy/fast scrubbing through continuous recording for whatever storage space I have (about 7.5TB). I think I've determined from reading that if you do not need multiple storage locations you need not configure them, only one (right?). But how about clip size. I have read various sizing recommendations from 1 hour to size based some quite large. Recognizing a priority is smooth scrubbing by timeline through history, what recommendation is there for clip size?

2) I hoped to use BlueIris as a media server, so that my Home Assistant could display camera views, and potentially cast them to cast devices. This works, sort of. I have experimented with encoding settings without a lot of success. As an example, this stream definition (http://server:81/h264/camFrontdoor/temp.m3u8 ) will display in Home Assistant, but my impression is that the data rate is far higher than I expect. If I try to play it in VLC (to look at codec properties) it will not play, just a single frame shows. Frame rate shows 1000. All I really want is to play back exactly as received (I am recording direct to disk). Is there some way to just have BlueIris stream out exactly as it recorded? If not, is the frame rate always identical to the original? Wireshark sniffing shows almost double the bandwidth from BlueIris as going into it from that camera. (Current settings are quality=50%, no bitrate limit, keyframe 300, profile main, superfast, HLS 3, not-zero latency, not-resize. Inbound data is I think 8 for keyframe interval by the way, at 4fps. Maybe I should ask this way: What format (URL) is best if I want it to be used for casting?

3) I periodically have false negatives, places where I really think I should get motion detected and do not. There are a lot of settings to experiment with. Is there any form of debugging available, e.g. where I can change settings and run the same clip perhaps and see what happens? Or a way to look at metrics or debugging from the selected settings? On a related note -- is 4fps (i.e. too slow) handicapping motion detection?

4) I am doing a recording direct to disk, but... again, my priority is primarily to be able to quickly move around on a timeline, scrub back and forth, and get fast screen updates. Is there better encoding, even if it initially takes more CPU? Currently the cameras are H264, though they will do H265 and I have not tried it with BlueIris yet as Luxriot did not work well with it (or maybe it was Milestone which i tried before, I forget now).

I think those are the top ones. Everything else is working well. I had tried Blue Iris long ago, it appears to be substantially improved now, and is working pretty nicely. I just need to get a few things cleared up.

Linwood

[HeneryH]

1) one impact of clip-size is that when exporting a snippet of video I have not found a way to export a snippet that crosses clip boundaries. You'd have to export your snippet in at least as many clips that contain your content. The larger the clip the more likely your entire snippet would be in that clip.

3/4) Do you really see that much difference in user noticeable performance in scrubbing based on the encryption? Frankly I rarely need to trick-play the video so I never really noticed much one way or the other. The deciding factor for me is a] higher CPU usage and more compact disk storage (h265) vs b] less CPU usage for less compact storage (h264)

[Thixotropic]

Is there any form of debugging available, e.g. where I can change settings and run the same clip perhaps and see what happens?

Yes, there is a way to run a recorded clip through the motion detection algorithm and have it show what did and didn't trigger. From the main GUI, open a video and right click on it to "Test run video through motion detector".

H265 compresses better and that should, in theory, should result in snappier clip viewing/scrubbing etc since it's supposedly going to be storing/handling less data overall. I don't know for sure if this actually translates into faster/snappier real-world usage but it might be worth trying.

[HeneryH]

H265 compresses better and that should, in theory, should result in snappier clip viewing/scrubbing etc since it's supposedly going to be storing/handling less data overall.

I'm not sure about this (in theory). My understanding is that most modern Intel CPUs with QuickSync can decode compressed video equally well and the throughputs we are talking about here are no where near any kind of capacity. IF and a huge IF BI could take advantage of hardware accelerated processing then I think this would be a no brainer with more compression for zero added cost. But alas, it doesn't and h265 acceleration does not work yet so we need to discuss the CPU overhead of non-accelerated decoding to gain the added compression.

[Ferguson]

Is there any form of debugging available, e.g. where I can change settings and run the same clip perhaps and see what happens?

Yes, there is a way to run a recorded clip through the motion detection algorithm and have it show what did and didn't trigger. From the main GUI, open a video and right click on it to "Test run video through motion detector".

Thank you. I think I am doing it. I can see the rest of the frame (except the two zones) blacked out, and if (with that set) I do a play, I can see motion occurring, and visually see if an object crosses between zones (my criteria). But how do I know what the motion detecting algorithm is doing? Or maybe I should be saying what the trigger algorithm is doing?

[Ferguson]

1) one impact of clip-size is that when exporting a snippet of video I have not found a way to export a snippet that crosses clip boundaries. You'd have to export your snippet in at least as many clips that contain your content. The larger the clip the more likely your entire snippet would be in that clip.

OK. Good to know. Not a big deal (I expect if history predicts the future here) I expect to rarely export clips.

3/4) Do you really see that much difference in user noticeable performance in scrubbing based on the encryption? Frankly I rarely need to trick-play the video so I never really noticed much one way or the other. The deciding factor for me is a] higher CPU usage and more compact disk storage (h265) vs b] less CPU usage for less compact storage (h264)

I am not quite sure what I said to imply I am seeing a difference in performance based on anything -- I have yet to try much. And I'm not using encryption (did you mean encoding?).

CPU during recording is certainly relevant, but at present is perfectly adequate. What is a bit slow is scrubbing. My question (and I confuse I have not done much experimentation) is whether scrubbing can be improved by other recording options - hoping for hints rather than me just trying options blindly in the camera and Blue Iris.

Sorry if I'm being obtuse.

[HeneryH]

Yes, I meant encoding, not encryption. Others may comment differently but I suspect not much change in playback performance due to encoding. But I could certainly be wrong on that one.