5442 S3 series, weird bitrate issue

[1.21 jiggawatts!]

i've noticed a weird issue with some of my 5442 s3 series cams, the ze and fixed focal versions on both latest dahua and andy firmware, in my encode settings, on some cams, using h264, max resolution, 15fps, 15 i-frame, cbr, 8192 bit rate, about every couple of seconds, i get a glitch in the image. it's hard to explain, it's like a pixelation, dropped frame, buffer issue for like a split second. if i set the bitrate to the highest setting of 14336, it goes way. it happens viewing the cam its self directly and viewing it through the nvr. i'd figure if it was a bandwidth issue it would be worst on the highest setting, not better.

i don't seem to notice it on h265 but i'd rather not use h265. having the cams on 14336 bit rate will eat up more hdd space. anyone have any ideas why this is happening?
View attachment Screen_Recording_20241101_170903_1.mp4

 

[bigredfish]

I call it pulsing.

Yes with the newer S3 cams and the 4K-X and T upping bitrate seems to solve it for the most part.

 

[steve1225]

what is value for encode -> smooth stream? did you moved it to smooth side?

are You sure You give proper settings at which this video was recorded?
Put screenshots of all image & encode settings...

normally this is a pulsing (losing sharpness between I-frames), but you video for me is showing something different...
in normal situations, at I-frame (usually every 2 seconds, but with Your settings this should be 1 second) image should recover to sharp one...
I-frame contains FULL FRAME IMAGE... they are like complete jpeg file..

then between I-frames are delta frames, which contains only changes to image..
and normally at delta frames (1-2 seconds long video) image start losing details at uniform textures (compression algorithms try to not use a lot of bandwidth for them)..
at next I-frame image is recovered to complete sharp one..

In You video this is in reverse.. at delta frames is sharp.. and then every a few seconds is losing for one frame sharpness and in next a few it recovers..
like I-frame were not complete... or very small... or something broke data in stream...

ps. how you received data? Dahua NVR or BI?

 

[Keizer]

I bought three of Andy's S3 cams and noticed the same pulsing. If I double the i-frame setting (ex: 15fps, 30 i-frame) the pulsing goes away......even keeping the bitrate low. And like the OP said, running 15fps, 15 i-frame and upping the bitrate seems to stop/slow it down. In my case I only needed to set the bitrate to 8192. Problem is that the pulsing is still present in the substream when viewing all cams in UI3.

 

[Mike A.]

Switching one of mine (SD4A425DB-HNY) that was pulsing to the AI codec seemed to fix it. Haven't noticed any issues with that cam using that vs the General codec.

 

[Keizer]

Switching one of mine (SD4A425DB-HNY) that was pulsing to the AI codec seemed to fix it. Haven't noticed any issues with that cam using that vs the General codec.

Hmmmmm, yeah switching to the AI codec seems to work to.

 

[bigredfish]

I have noticed this on a few cameras. Making Iframe 2X FPS. (which is what they come default set at)

 

[Keizer]

I have noticed this on a few cameras. Making Iframe 2X FPS. (which is what they come default set at)

Are you saying you have seen the pulsing even with the Iframe 2X FPS?

 

[dudemaar]

I have this happening with 8 cams on a 16 ch nvr.

 

[Mike A.]

Also will depend on the scene. If you've got a view with a big area of something consistent like grass or gravel, etc., you'll tend to notice it more. If more varied 'stuff' in the view then it may still be there but won't be as obvious.

 

[bigredfish]

Are you saying you have seen the pulsing even with the Iframe 2X FPS?

No Im saying 2X iframe has helped reduce it on some cameras

 

[steve1225]

If someone is running I-frame at the same level as FPS wastes a lot of bandwidth on full frames (i-frames).
In complex scenes, there may not be enough bandwidth to encode the entire scene into an i-frame.

There is no justification for using i-frames shorter than 2 seconds (2 times of FPS).

The normal CBR algorithm statically divides the bandwidth between i-frames and the remaining difference frames. A fixed separation factor may not work for every scene - that's why there is a Smooth <> Clear slider that allows you to change this factor.

The AI Codec algorithm in the CBR version analyzes the scene and all frames (i-frames, delta frames). As a result of the analysis, it dynamically adjusts the bandwidth division between full frames and difference frames. It notices changes with a delay of several minutes.

An additional feature of the AI Codec algorithm is that it detects people/cars in the scene and informs the video compressor to use higher compression quality for them (than for trees, grass, roads, walls and other elements).

I use AI Codec in different variants (ABR or CBR) on almost all cameras.

 

[wittaj]

If someone is running I-frame at the same level as FPS wastes a lot of bandwidth on full frames (i-frames).
In complex scenes, there may not be enough bandwidth to encode the entire scene into an i-frame.

There is no justification for using i-frames shorter than 2 seconds (2 times of FPS).

The normal CBR algorithm statically divides the bandwidth between i-frames and the remaining difference frames. A fixed separation factor may not work for every scene - that's why there is a Smooth <> Clear slider that allows you to change this factor.

The AI Codec algorithm in the CBR version analyzes the scene and all frames (i-frames, delta frames). As a result of the analysis, it dynamically adjusts the bandwidth division between full frames and difference frames. It notices changes with a delay of several minutes.

An additional feature of the AI Codec algorithm is that it detects people/cars in the scene and informs the video compressor to use higher compression quality for them (than for trees, grass, roads, walls and other elements).

I use AI Codec in different variants (ABR or CBR) on almost all cameras.

Keep in mind for those running BI and using BI motion and especially if then using CodeProject AI, the BI developer says it is best to match FPS and iframes and to not use any special codec based on how BI detects motion.

In fact, if the iframe is 2.5 times or more FPS, it will throw caution triangle errors.

I guess one of the advantages of using an NVR

Now if you do not use BI motion and can get over OCD behavior of the yellow triangle cautions, then BI can work fine with unmatched iframes and AI codec.

 

[steve1225]

Keep in mind for those running BI and using BI motion and especially if then using CodeProject AI, the BI developer says it is best to match FPS and iframes and to not use any special codec based on how BI detects motion.

In fact, if the iframe is 2.5 times or more FPS, it will throw caution triangle errors.

I guess one of the advantages of using an NVR

Now if you do not use BI motion and can get over OCD behavior of the yellow triangle cautions, then BI can work fine with unmatched iframes and AI codec.

OK, but this is some strange BI requirements..
The only thing in REAL USAGE what iframe / FPS ratio changes is how long You wait to display new opened video stream (like clicking in DMSS to show one camera in full resolution).
Displaying can start from next FULL I-frame, so big I-frames (or SmartCodec with VBR coding which can dynamically extend I-frames to 10 or more of seconds) can extend time when You will see video start to show...
Like in digital TV (cable, satellite) when You switch channels, You have audio from beginning but for video You must usually wait 1-2 seconds to next FULL I-frame in video stream.

If BI decodes frame by frame and analysis them then there is no technical need to use short I-frames..
The only situation where BI can ask for short I-frames is when it analyzes only I-frames (don't decode other ones) to save CPU/GPU usage..

can you @wittaj explain to me why you use BI motion analysis at all, if today's cameras do it much better (on every video frame on uncompressed material without any needs how to configure camera encoding/image settings)?
I understand if someone has a stupid cheap camera from 5 years ago, but for 5442-S3? The whole world of professional VMS uses AI / AI IVS motion detection built into cameras. No one is doing SMD/AI IVS on VMS, because this doesn't scale. And if someone needs AI analysis on VMS side, there usually are dedicated AI hardware boxes for that.

ps. AI Codec (CBR, ABR) shouldn't create any problems - it have static I-frames, so You can put 1 or 2 seconds. Only SmartCodec and AI Codec on VBR can create problem, because of dynamic I-frame.
On latest 5442 firmware there is a new feature called Virtual I-frame (visible in Ai Codec on VBR) which from name should solve this problems - but I don't know how this works in real life..

 

[wittaj]

OK, but this is some strange BI requirements..
The only thing in REAL USAGE what iframe / FPS ratio changes is how long You wait to display new opened video stream (like clicking in DMSS to show one camera in full resolution).
Displaying can start from next FULL I-frame, so big I-frames (or SmartCodec with VBR coding which can dynamically extend I-frames to 10 or more of seconds) can extend time when You will see video start to show...
Like in digital TV (cable, satellite) when You switch channels, You have audio from beginning but for video You must usually wait 1-2 seconds to next FULL I-frame in video stream.

If BI decodes frame by frame and analysis them then there is no technical need to use short I-frames..
The only situation where BI can ask for short I-frames is when it analyzes only I-frames (don't decode other ones) to save CPU/GPU usage..

can you @wittaj explain to me why you use BI motion analysis at all, if today's cameras do it much better (on every video frame on uncompressed material without any needs how to configure camera encoding/image settings)?
I understand if someone has a stupid cheap camera from 5 years ago, but for 5442-S3? The whole world of professional VMS uses AI / AI IVS motion detection built into cameras. No one is doing SMD/AI IVS on VMS, because this don't scale.

ps. AI Codec (CBR, ABR) shouldn't create any problems - it have static I-frames, so You can put 1 or 2 seconds. Only SmartCodec and AI Codec on VBR can create problem, because of dynamic I-frame.
On latest 5442 firmware there is a new feature called Virtual I-frame (visible in Ai Codec on ABR and VBR) which from name should solve this problems - but I don't know how this works in real life..

You nailed it - BI analyzes motion on iframes to save CPU usage.

The 180 cameras with AI codec wreaks havoc with "no signal" issues in BI (even though it doesn't actually lose signal).

There are plenty of people that still use BI motion with CodeProject. I didn't say I was one of them LOL.

Although I do use BI motion at night for the LPR cams and for one camera where using IVS results in headlight shine as the alert image and I want the vehicle in the alert image and CodeProject does a good job at that.

 

[steve1225]

You nailed it - BI analyzes motion on iframes to save CPU usage.

The 180 cameras with AI codec wreaks havoc with "no signal" issues in BI (even though it doesn't actually lose signal).

There are plenty of people that still use BI motion with CodeProject. I didn't say I was one of them LOL.

Although I do use BI motion at night for the LPR cams and for one camera where using IVS results in headlight shine as the alert image and I want the vehicle in the alert image and CodeProject does a good job at that.

AI Codec on first gen Full Color cameras were added in middle on camera life cycle. I don't know if the SOC used in those cameras had all features needed to full implement of AI Codec.
Also Dahua 5849-180 cams are very weird ones.. many things on them works very bad (like IVS which have big dead zones on sides or middle of the screen)

I must say that information that BI uses only i-frames for image analysis explains a lot of STRANGE recommendations that have historically circulated on this forum.

The mania of using very high bandwidth for video (8-12 mbit/s for 4Mpx cameras???), only CBR on old static algorithm, low FPS and i-frame (12/15), h.264 - all this is mainly to ensure high quality / detailed i-frame for BI. At the level of individual pixels.

All these recommendations looks like history for NVR users. Where you use full FPS (25/30), 2-4 second i-frames to save bandwidth, you are not afraid of novelties like Ai Codec or Average Bit Rate (ABR) or even h.265 for normal users (they do not see the difference). All Motion / IVS / Face / VMD analysis is done on camera on uncompressed material, the same for all snapshots. So compressed material is only to live view / playing history footage.

The only thing common to BI and NVR users is a total lack of love for SmartCodec / VBR, which also causes a lot of problems in the NVR world. Luckily Dahua has started phasing out SmartCodec from latest cameras/firmware and replacing it with AI Codec/VBR with virtual i-frame support.

I'm a bit surprised that no one in the group has discovered that the Smooth <> Clear slider (towards Clear) can increase the amount of bandwidth and quality for i-frames without need of changing the other parameters. Which can helps with those BI requirements on lower configured bandwidth.

 

[ncpilot]

Now that is some of the most insightful info I've seen in a while... But this statement "All Motion / IVS / Face / VMD analysis is done on camera on uncompressed material, the same for all snapshots. So compressed material is only to live view / playing history footage." makes me wonder then if this implies that recorded video is a lower resolution than when viewed live? What if I record 24/7 and want max usable resolution for history footage? Set parameters for that requirement and not necessarily for saving bandwidth?

I learned early with BI that on camera detection was the way to go...

 

[steve1225]

Now that is some of the most insightful info I've seen in a while... But this statement "All Motion / IVS / Face / VMD analysis is done on camera on uncompressed material, the same for all snapshots. So compressed material is only to live view / playing history footage." makes me wonder then if this implies that recorded video is a lower resolution than when viewed live? What if I record 24/7 and want max usable resolution for history footage? Set parameters for that requirement and not necessarily for saving bandwidth?

I learned early with BI that on camera detection was the way to go...

NO.
it means that image/video which see camera (internally) and can use for AI analysis is better quality (because it wasn't compressed/decompressed).
If the AI is done on NVR/VMS side then AI on NVR/VMS see the same as we see in Live View / recorded view - compressed and decompressed footage, which can be worse quality (how much - depending of encode settings).

 

[Mike A.]

I must say that information that BI uses only i-frames for image analysis explains a lot of STRANGE recommendations that have historically circulated on this forum.

The mania of using very high bandwidth for video (8-12 mbit/s for 4Mpx cameras???), only CBR on old static algorithm, low FPS and i-frame (12/15), h.264 - all this is mainly to ensure high quality / detailed i-frame for BI. At the level of individual pixels.

There are some BI "quirks," but more so than that most of us here are generally optimizing for quality over storage/processing resources so we tend more toward higher bitrates, CBR, h.264. FPS is more easily traded off since we aren't so concerned with smooth video; rather, more to capture just a few frames of a face/plate/other static image. Easy to tell what happened from a marginal capture. Not as easy to see who did it. That varies depending on camera and use-case obviously but that's the general bias for most people's security purposes. For wildlife I like a somewhat higher FPS for more natural movement. Storage is cheap for home users and we typically don't need to keep video for long so that tends to trump efficiency. If I were setting up for a business that needed 12 months of video for liability/theft/whatever purposes or something like that, then I'd set up differently.

 

[steve1225]

There are some BI "quirks," but more so than that most of us here are generally optimizing for quality over storage/processing resources so we tend more toward higher bitrates, CBR, h.264. FPS is more easily traded off since we aren't so concerned with smooth video; rather, more to capture just a few frames of a face/plate/other static image. Easy to tell what happened from a marginal capture. Not as easy to see who did it. That varies depending on camera and use-case obviously but that's the general bias for most people's security purposes. For wildlife I like a somewhat higher FPS for more natural movement. Storage is cheap for home users and we typically don't need to keep video for long so that tends to trump efficiency. If I were setting up for a business that needed 12 months of video for liability/theft/whatever purposes or something like that, then I'd set up differently.

12000 kbit (12 mbit) is 1.5MB/s of written data. In day this is 126,5GB.
Multiple typical 16 cams it's 2TB per day.. Minimum 30 days of storage it's 60TB for 16 cams..
Without snapshots, databases and any copies of footage for AI..

it's not normal for normal installations (bigger houses, some small SMB businesses).
More for this forum and very specific profile of users here...