Struggling with Video Streaming Settings after Enabling Sub Streams

patterrr

n3wb
Nov 23, 2017
16
1
I recently added my 24th Dahua camera to my system, and now my Blue Iris PC's CPU always sets at 100% (was in the 90s before). I've only ever used main streams, and all was great besides CPU usage. I read this very helpful guide on sub streams, so took a go and enabled sub streams on all my cameras. Voila! Only 15% CPU usage now! UI3 is snappier than ever. But then I started to notice that the substream quality is nearly unusable and main stream quality is much worse than before. Below are screenshots of my settings, as well as cropped full-resolution images as taken from the camera's web page (this is for my IPC-T5442T-ZE cameras, but I also have IPC-T5442TM-AS, IPC-B54IR-Z4E S3, IPC-T5442TM-AS-3.6mm, IPC-T54IR-ZE, which appear to behave similarly):

Original settings before turning on sub streams:
1745294584874.png
1745295916176.png

Now my new settings enabling sub streams, and then associated snippets of main stream and sub stream with these settings. One bummer is that total stream rate to Blue Iris is now 3x what it was before, and 1/3 the storage history will be unacceptable, so I'll need to triple my hard drive size if I stick with these.
1745296025713.png
Main stream (so much worse without Smart Codec enabled)!
1745296261406.png
Substream
1745296355889.png

Playing around a lot with it, I found the video was acceptable if I set the encoding strategy back to Smart Codec, and the sub stream from VBR to CBR.
1745296466464.png

1745296626268.png
1745296702691.png

I figured I was golden with these settings (even though the Sub Stream Guide said to turn off Smart CODEC due to long i-frame intervals)... Until I opened a video fullscreen in Blue Iris UI3, and found that it looks like this for a good 15-30 seconds before it comes through good quality as shown above, so long i-frame interval indeed:
1745297011113.png

So what settings have good luck with on Dahua cameras? At the moment, it appears that my options are short i-frame intervals by not using Smart CODEC for faster loading of main frame, or great quality by enabling Smart CODEC, but super long load time for main stream. I also played with H.264, but had worse luck there. Apologies if this has already been discussed, I couldn't find such a thread though.
 
If you use BI motion detection, you will find that using Smart Codec will result in missed motion.

Most using BI use the following for the 5442/54IR camera:

H264H
15FPS
15 iframes
General Codec
8192 bitrate mainstream, D1 substream with bitrate to your liking but 512 is sufficient for most.
CBR

You have what 24 cameras, so the size of the camera in multi-screen view doesn't need a high resolution, so give it a few days and you will probably be ok with it.
 
Not a BI guy but anyone using Dahua's H.265 and Smart Codec deserves what they get.

Marketing bullshit both of them
 
Last edited:
Thanks for your responses.
If you use BI motion detection, you will find that using Smart Codec will result in missed motion.
That must explain why I occasionally miss a motion. I had no idea the I-Frame rate was so absurdly long with Smart CODEC until now.

H264H
15FPS
15 iframes
General Codec
8192 bitrate mainstream
Do you typically use VBR or CBR with these settings for mainstream? Also, why use H.264 rather than H.265 since its compression ratio is only half as good? In general with video editing I always encode as H.265 with fantastic results. My guess is perhaps the compression algorithm or compute resources for these cameras aren't all that good so the H.265 compression results aren't very good? One other thing, when I change to H.264, an option called "SVC" shows up and values of 1, 2, or 3 can be selected; I think this is for Scalable Video Coding, but no idea what it should be set to, does anybody have suggestions? Also, H.264B or H.264H are options in addition to H.264. I'd expect H.264B is worse, but on paper H.264H should be better, but would this cause issues with Blue Iris, or similar to H.265 is the camera not very good at compressing to H.265H?

You have what 24 cameras, so the size of the camera in multi-screen view doesn't need a high resolution
This is correct, not a big deal on multi-screen view, but doesn't BI also use the substream for motion detection, and that's why I'd want reasonable quality / resolution for my substream? Speaking of which, I've never tried using my cameras for motion detection (I think they can do that right?) instead of BI, should I consider doing that? Do many of you out there use BI for motion detection, or your camera? If camera, if anybody has a link to a guide for how to configure that, I'd be very appreciative.

Regarding VBR versus CBR for the main stream, I find that VBR quality is fine when there isn't much motion, but not very good when there is any motion, even when the quality is set to 6(Best) with 8192Kbps max. It seems that it isn't adequately stepping up the bitrate when motion occurs. Have others experienced this? My concern is that going to CBR for my full system would be 8192 Kb/S * 24 cameras * 3600 sec/hr * 24 hrs / day * 0.125 Bytes / bit = 2.074TB per day! With our previous settings we had about 30 days of storage, which was desirable, and that would lead to needing 60TB of storage, 10x what we have now. So if somebody has found a good way to get good results out of VBR, it would help reduce storage requirements. Thanks!
 
Last edited:
Regarding VBR versus CBR, you are seeing the problem and mention it - HTF cares if the quality is fine when their isn't motion? We care about capturing a perp in motion. In many instances or specific cameras, VBR can't scale up fast enough.

Regarding storage - that is the beauty of the substreams - now you change recording from continuous to continuous + triggers. This way it records the substream until motion and then the mainstream. It cuts down on the storage requirements. You may actually get longer retention with substreams.

While having lots of days/months sounds great, the reality of it is unless it was something catastrophic (which you would have known about sooner anyway), most are not going to start scrubbing video for something that may have happened a few weeks or months ago.

By spending time to dial in the alerts and a frequent peek at what is going on, you would have noticed something around your property within days. I literally every morning in under 30 seconds can scrub what happened the night before and see if anything happened I need to look at further. This is for things off my property. I will know immediately with an alert of a person or car is on my property.

If a neighbor comes up to me and says "sometime around 2 weeks ago someone backed into my car, can you see if you caught it?" You will find that even with the best scrubbing this is a monumental task. Unless they can narrow down the day/time window or you can visually see the damage on your video that you can start looking at the same time everyday until you see the damage and then do an iterative process to narrow down when it was, most of us are not going to scour it.

There are some other considerations or law reasons for businesses that may need longer, but for the average homeowner, the reality that we are going to scrub thru months of video is slim. I would rather have higher quality and 24/7 for a shorter duration than longer duration but lower quality and potentially missed video. But that doesn't mean I run continuous mainstream either. I run substream until triggered and then mainstream. Anything of interest I export out.

Quality is a function of bitrate and resolution. The lower the two, the more storage you can get. But too low and then the quality suffers.

As always YMMV.


If you have cameras with AI, then it is better to use that than BI motion. If your cameras do not have AI, then BI motion provides more granular control over motion detection. So do you have cameras with AI?


I assure you if BI missed motion because of using substreams nobody would use it. But like I said if your cameras have AI, then it is a moot point.


GETTING CAMERA TRIGGERS INTO BI

Go into the camera GUI and set up smart plan with IVS, then go to the IVS screen and draw IVS rules (tripwire or intrusion box) and then select the AI you want it to trigger on (human or vehicle).

Make sure MD and SMD are turned OFF in the camera.

Then in BI, there are a few places you need to set this up in BI (assuming you already set up the IVS rules in the camera GUI):

In Camera configure setting check the box "Get ONVIF triggers".

1729872550455.png




Hit Find/Inspect on the camera setting to pull the coding for the triggers.

Go into Motion Setting and select the "Cameras digital input" box OR "ONVIF/CAMERA EVENTS" based on which BI version you have. Turn off BI Motion Detection if you don't want to use it:

1729872617699.png


On the Alerts tab uncheck the Motions Zones tab (those are alerting you to any BI motion in those areas in Zones A thru H) and select ONVIF and External check boxes.

1729872667440.png


On the "On alert..." actions, select how you want to be alerted (email, push, SMS, etc.)


Most of us have found H265 in these cameras suck.

H265 in theory provides more storage as it compresses differently, but part of that compression means it "macro blocks" (technically coding tree units) big areas of the image that it thinks isn't moving. That can be problematic for digital zooming with H265.

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.

Further some cameras can handle H265 better than others, even if the camera "claims" to support it, it may actually do a very poor job with it.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My 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 in those larger blocks yet increases the camera CPU demand to develop these larger blocks. For some cameras that then becomes problematic to do other functions as the little processor is now maxed out.

1667974399793.png



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. 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 essentially zero.


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.

Some people have a field of view or goals that allow H265 to be sufficient for their needs.

BI does better with H264. That is the tried and true standard. H264H is ok with BI as well. If using CBR and your camera allows SVC, just keep it on the default number.

As always, YMMV.
 
@wittaj Thank you for the thorough response!

Regarding the first whole section, our use case is not just for security. The reason my wife loves the camera system is say she finds a big poop outside, she'll go back and find what kind of animal left it (even though an alert probably wasn't triggered). Or if we lose something, we'll go back and look at the footage of when we last had it and figure out where we placed it (half dozen of our cameras are inside). Or if the cat goes missing, she'll track all its moves with the cameras to see which side of the property it exited from. Or one of my favorites, I noticed one of our bushes in the back was destroyed so I checked the cameras to see what kind of wildlife could do that - turns out three weeks earlier my dad decided to take my new 360 mower for a test drive at full speed, lost control, and went right over the bush. Or I find a big oil spot in my driveway, so look back to see how it got left.

Some of these events cause alerts, but also many don't, so we need to record main stream all the time rather than sub stream. I think my solution is just to throw $$ at the problem - I ordered a 20 TB hard drive last night which combined with the current drive will get us almost 2 weeks.

I think some of my cameras have AI, not sure how to know for sure. I logged into the camera and looked at the Event tab, and it isn't very intuitive. To make things worse, the IPC-T5442T-ZE and the IPC-T54IR-ZE cameras have totally different options in the Event tab. I'm going to have to play with this for a bit to better understand it. I really appreciate your instructions on getting the events into Blue Iris, I really look forward to giving this a try! I'll follow up once I can try it with any questions.

Thanks also for your explanation on why H.265 isn't great with these cameras. Today I took dozens of still images of both no motion and very high motion with both H.264 and H.264H, at various bitrates. In general H.264H was just a hair better for the bitrates being the same. I tried bitrates ranging from 2560 up to 12888 Kbps. 2560 Kbps was pretty bad, with serious improvement up to 4864 Kbps (the camera defaults to this when set to H.264). Above 4864 Kbps, improvement diminishes greatly. There is extremely minor, but barely noticeable improvement going to 8192 Kbps, and then I couldn't find any improvement at all going on to 12888 Kbps. I think the few cameras I care the most about I'll set to 8192 Kbps, and the rest to 4864 Kbps. These comparisons were done at a resolution of 2688 x 1520, 15 FPS, I-Frame set to 15, and CBR. I'm sure changing any of these would change the point in the quality versus bitrate curve where it flattens out on quality.

Thanks again!