Ghosting..Dahua 5231R-ZE
- Thread starter dastrix
- Start date
Dramus
Pulling my weight
Everybody's saying set iframe = frame rate, yet Dahua's user's manual recommends iframe = 2 x frame rate. Does anybody know why Dahua makes this recommendation and can somebody explain why it's not optimal? TIA!
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
There is not actually any meaningful relationship between iframe interval and framerate that makes matching (or using a multiple) inherently better than an odd value. Assuming a framerate of, say, 15fps, using iframe interval of 16 should work just as well as 15, there would just be an iframe every 1.07s instead of every second. Using the 2x multiplier that Dahua recommends just means there will be an iframe every 2s. Matching them happens to be the lowest iframe interval Dahua will allow, but if a lower value were allowed, some people (quality junkies or those recording on motion only) could choose to go even lower. The encoder doesn't care what interval iframes occur at, or even that they are consistent. If you enabled Smart Codec, iframes would occur at varying intervals as the encoder sees fit based on what's happening in the scene.
Dramus
Pulling my weight
Thanks for the detailed response, @Insecurities. I have another question, but I'll start my own thread, rather than haul the OP's OT.
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
I was speaking generally from a video encoding/decoding standpoint in response to the question of why Dahua would default and recommend 2x framerate when it seems to be widely considered suboptimal around here, but I still have some thoughts around this and BI...
If there's an issue specific to BI that requires a keyframe exactly every second, then I'd like to understand why that would be, as it would actually suggest to me that there's a bug in BI. It makes sense that when doing motion only recording direct to disk it would need to start with a keyframe, but as long as the pre-trigger buffer is large enough that it always contains a keyframe that shouldn't be an issue. So setting iframe interval to fps+1 should solve that nearly as well as setting it to match fps, unless there's some assumption BI is making that there's a keyframe exactly every second (which would make no sense and definitely seem like a bug to me)? That is really what I meant when I said there is no meaningful relationship between iframe interval and framerate that makes matching them ideal; there's no technical requirement or advantage for iframes to have intervals that are exactly 1s or integer values in seconds, and BI shouldn't assume there is either.
In regards to OP's video, the fact that the issue repeats after the first keyframe cleans things up suggests to me there is a stream interruption or again, incorrect direct-to-disk playback/recording (a potential bug). I do believe you when you say matching iframe interval to fps has fixed similar issues in the past, but I'd like to dig into them and see why, because it seems to be creating a data-hogging requirement that I believe should be totally unnecessary from a technical standpoint.
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
My point was that it is mentioned here because the OP is having a problem in blue iris. There is no bug in BI. Blue iris only begins recording on a new keyframe. The smearing occurs well after the recording is triggered so your logic with respect to the iframe+1 is false.
Blue iris does not always require that the iframe matches the fps. This is a solution for specific cases where this symptom is exhibited with some cameras with some settings on some systems.
This issue is not always caused by the iframe interval and this issue is not only present in blue iris. This occurs in various model cameras from hik dahua etc and using their respective NVR's. The fact that you did not see it in your short "test" is irrelevant. Sometimes its the iframe interval setting. Sometimes its dropped frames. Sometimes its something else. Here is an example of it happening in Milestone. Troubleshooting poor image quality - frustrated.
This is a known issue with smart codec, which is essentially is a dynamic adjustment of the iframe interval and sometimes dynamic compression.
There are plenty of examples of this happening in dahua/hik etc nvr's as well. Perhaps you should inform them of this bug.
Last edited:
This seems to be a sensitive subject. I wasn't trying to step on any toes.
I wasn't saying that setting iframe interval to fps+1 would fix OP's issue. I was saying it should be nearly as effective in the case where motion triggered recording required a keyframe, since it would create a new keyframe almost as often as iframe interval=fps.
I acknowledge that different issues occur intermittently on different systems, and that different troubleshooting steps are also intermittently effective. On a system where setting iframe interval = fps resolved an issue, I think it's important to understand why it was effective. Was it just because the interval was shorter, or is there something special about a keyframe exactly every second? I'm not aware of any technical reason that matching them is better. I never suggested that the results of my quick test that I posted in the other thread meant anything more than what they showed, and I never tried to apply that to anything in this thread, so I'm not sure why you're bringing that test up?
Like I said, this seems to be a sensitive subject for whatever reason, and I feel like you're taking some things I said and applying them to a different context than I was. I wasn't trying to say matching iframe interval and fps isn't a good troubleshooting step, it absolutely is. I'm just not the type to see something work and just move on. I always want to fully understand why it works, and I just don't see a technical reason why it would work better. But it's really not a big deal, I know you've been in this game much longer than I have, and I'm not trying to pretend I have some answers that others don't. I was really just sharing thoughts on the technical part of it and the questions that come to my mind when thinking about this stuff. Cheers!
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
Its sensitive when you post misinformation subject to your limited knowledge and experience.
Once again, the tear can occur 30 seconds in the motion event.
My point was that your testing is limited. With one camera and one nvr each with the same or similar firmware. There are lots of variables.
You dont have any clue about the technical part of it. You are limited to your rudimentary of a simply system that you own likely for a very short period of time.
Hello dastrix, having just read your post I think that a solution to your intermittent problem with motion when it's dark has not been found. Did you try reducing the noise reduction as suggested by aristobrat? As a trial, I would try turning it off completely to see if that helps. Although my Dahua cameras cope well with noise reduction, I imagine the processor has to work extra hard to smooth a noisy image if every pixel changes every time it is sampled, perhaps causing a legacy effect overload.
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,408
There is no "intermittent motion problem when its dark" that cannot be solved with the steps outlined. There are thousands of other users with these cameras and BI that dont have this problem.
- Aug 18, 2017
- 188
- 19
I'm not getting the loss of frames now after playing around. Setup bp2008's profile changer & changed the iframe interval to match the FPS. There hasn't been much motion for me to really test it but so far so good.
The washed out faces is another issue, as fenderman suggested I turned off Smart IR so we will see
The washed out faces is another issue, as fenderman suggested I turned off Smart IR so we will see
I have found in certain places, like gravel driveways and grass like settings that smart IR is not so smart, It seems to work better on concrete floors and larger rooms, not sure why(could be a reflection thing) but I usually have to set it to manual and use the slider to adjust it accordingly to conditions.
SCN
n3wb
I have had this same exact problem with other cameras. Typically i see this when the camera itself is malfunctioning or overheating.. but i have seen a few encoding changes that cleared this issue when temp wasnt a problem.. try streaming with ONVIF or even directly with RTSP..
As for the Iframe being 1:1 instead of 2:1 is because on occasion, the iframe needs to be updated more frequently when larger objects more through.. in this cause it is an issue with how the h.264 is displaying the picture changes.. changing the stream type may resolve the issue although a firmware update is the correct solution.
As for the Iframe being 1:1 instead of 2:1 is because on occasion, the iframe needs to be updated more frequently when larger objects more through.. in this cause it is an issue with how the h.264 is displaying the picture changes.. changing the stream type may resolve the issue although a firmware update is the correct solution.
Hello SCN, I wonder what these ‘few encoding changes’ are?
There has been lots of correspondence previously about the iframe rate and wonder if you are speaking from experience or speculation.
Here is an example from me:
Hello Spizz. The guys have some good advice, I record continuously at 1080p and to limit storage space - sd card and BI, with 10 cams I limit the frame rate to a maximum of 10fps. But I would take issue with their recommendation of setting both the frame rate and iframe to the same value. When recording continuously with VBR I find that, when limiting the bitrate to a specific value to maximise recording time (I use 2048kbps), an iframe of 150 delivers the best video quality with complex moving images. In daylight, only bits per frame matter so why waste these precious bits by repeatably sending static data? For example, when using a 59225 PTZ, the blurr when panning clears more quickly with an iframe of 150 and when setting both the frame rate and iframe to 10 at 2048kbps and when there's 'a lot going on in the image', some parts of the image never clear!
This would not be valid when recording only with alert triggers.
It may be a different storey when it's dark when the camera sensor performance and associated settings may dominate.
And another example from bp2008:
Whenever I've seen this effect, the quality "returns to normal" very quickly after each i-frame. So quickly that even very low keyframe intervals like 5 or even 2 have a jarring effect. While it may be a lesser effect with a ridiculously low keyframe interval, the quality suffers so much from having it set this low that it doesn't really matter anymore because the visual artifacts are bad unless your bit rate limit is sky-high.
This issue typically happens when an encoder is tuned to strictly adhere to a bit rate limit. The encoder won't be allowed to create huge i-frames, as those would cause big bit rate spikes (which would make it harder to stream smoothly with very low latency).
This is easy to demonstrate using Blue Iris. I can configure a streaming profile with a bit rate limit that is low enough to be restrictive at the chosen quality level, and presto, each i-frame causes a temporary loss of quality. Lower iframe intervals make the pulsing effect happen more often, but do not make it more subtle. This is a big reason why Blue Iris's default i-frame interval for streaming is 300 frames.
Now presumably most cameras aren't tuned to adhere to a bit rate limit as strictly as Blue Iris is. They should be allowed to make large keyframes and just expect the client to buffer ahead to be able to stream smoothly.
There has been lots of correspondence previously about the iframe rate and wonder if you are speaking from experience or speculation.
Here is an example from me:
Hello Spizz. The guys have some good advice, I record continuously at 1080p and to limit storage space - sd card and BI, with 10 cams I limit the frame rate to a maximum of 10fps. But I would take issue with their recommendation of setting both the frame rate and iframe to the same value. When recording continuously with VBR I find that, when limiting the bitrate to a specific value to maximise recording time (I use 2048kbps), an iframe of 150 delivers the best video quality with complex moving images. In daylight, only bits per frame matter so why waste these precious bits by repeatably sending static data? For example, when using a 59225 PTZ, the blurr when panning clears more quickly with an iframe of 150 and when setting both the frame rate and iframe to 10 at 2048kbps and when there's 'a lot going on in the image', some parts of the image never clear!
This would not be valid when recording only with alert triggers.
It may be a different storey when it's dark when the camera sensor performance and associated settings may dominate.
And another example from bp2008:
Whenever I've seen this effect, the quality "returns to normal" very quickly after each i-frame. So quickly that even very low keyframe intervals like 5 or even 2 have a jarring effect. While it may be a lesser effect with a ridiculously low keyframe interval, the quality suffers so much from having it set this low that it doesn't really matter anymore because the visual artifacts are bad unless your bit rate limit is sky-high.
This issue typically happens when an encoder is tuned to strictly adhere to a bit rate limit. The encoder won't be allowed to create huge i-frames, as those would cause big bit rate spikes (which would make it harder to stream smoothly with very low latency).
This is easy to demonstrate using Blue Iris. I can configure a streaming profile with a bit rate limit that is low enough to be restrictive at the chosen quality level, and presto, each i-frame causes a temporary loss of quality. Lower iframe intervals make the pulsing effect happen more often, but do not make it more subtle. This is a big reason why Blue Iris's default i-frame interval for streaming is 300 frames.
Now presumably most cameras aren't tuned to adhere to a bit rate limit as strictly as Blue Iris is. They should be allowed to make large keyframes and just expect the client to buffer ahead to be able to stream smoothly.