H.265 Smart Codec, i-frames, and CBR/VBR

[redpoint5]

I'm running a Dahua 5542T-ZE (zoomed to max) and my preference would be to use the more efficient H.265 codec since that reduces network traffic and saves storage space (5TB currently allocated).

In playing with settings, I found that turning on Smart Codec and using VBR produces very good quality footage while really minimizing network/disk consumption during the 99% of the time that there's hardly any motion.





The downside is that i-frame rate is abysmal, and I believe that is what is responsible for the 5 second lag it takes from double clicking a thumbnail, to the clip finally playing. It also seems to be responsible for making it nearly impossible to scrub in reverse. Unfortunately when Smart Codec is enabled, my option to set i-frame goes away. Are there solutions to any of these issues, such as different firmware, or different BI settings?

With H.265 Smart Codec OFF, I can set i-frames and that resolves the delay and reverse scrub issues, but then the moving portion of the image turns to garbage.





With H.265 Smart Codec OFF and CBR, that resolves all issues of image quality, scrubbing, and video delay, but then consumes 4x more network/disk.





That must be why everyone is using H.264 CBR, right? Is H.264 also preferred because it's required for web viewing or using mobile phone apps to review footage? So far I haven't cared about those features since I do all viewing with an RDP session to my PC. At some point I'll want to get more fancy, especially as I share with friends/neighbors who want to check on things.

 

[wittaj]

As you are seeing, and as the Help file indicates, BI and smart codec do not work well together.

When the KEY drops below 1.00 that his how BI will miss motion.

The reason your image looks all pixelated is how H265 macroblocks, which means you will miss motion in some instances and field of views, especially on the edges.

Plus I see that you are not using substreams - once you do that, your concerns about consuming 4x the network will go away. Look at the optimization wiki now and add substreams!


This will explain H264 versus H265 a little better.

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.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. As I mentioned, mine was less than few minutes per day.

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 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. 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 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. That is what you are experiencing with motion.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

H265 is one of those theory things that sounds good, but reality use is much different.

As always, YMMV. But do not use Codec with BI or you will have trouble.