Problems with sd59225u-hni-ptz

looney2ns

IPCT Contributor
Sep 25, 2016
16,267
24,149
Evansville, In. USA
This is related to this: I'll be the guinea pig for the new SD59225U-HNI PTZ.

Had the cam installed on the roof now for a few weeks. And I gotta say, I'm disappointed in this cam.
I understand it could be user error, but that's why I'm asking here.

I'm still running the original firmware on it from July 2016, I shy away updating firmware for the obvious reasons. Mono price STP cat5e used, monoprice Rj45's, powered by included power brick via 14awg.
I've messed with the settings daily, and don't seem to have improved on it much.

For one, the picture flickers at 1 second intervals, in certain daytime lighting conditions. I've tried the different flicker settings, makes no change. I've set to defaults no change. The flicker is visible directly viewing the cam, from recordings to the SD card, and it's worse, when viewed in Blue Iris either live or recorded and in the substreams. Doesn't flicker at night.

Sample video below was exported from BI to mp4. It seems whatever Youtube does, has reduced the flickering some in sample video. Cam is set to 15FPS @ 6144 bitrate, CBR, Iframe 15. H.264H encoding.

Here is an example video, any suggestions greatly appreciated. Thanks.

 
If the "flicker" is the change in detail on the grass to the right of the cement path, I notice that with my cams when there is fine detail like that. I believe it is related to the GOP and the big change every 1 second is a new I-Frame. Kick the I-Frame up to 50 or something and see if it changes.
Of course I could be full of shit. I think it is artifact in the h264 MPEG stuff.
 
  • Like
Reactions: looney2ns
Well if what you are seeing is that change on the grass then:
I played with one of my Hiks and it did seem to change with I-Frame interval. But it was also possible to reduce the artifact by going to VBR and increasing the data rate. See if yours does that too. It makes sense as the I-Frames are the largest payload and if you are CBR with one a second (15 for 15fps), they get a limited amout of bandwidth for a whole frame of picture. MPEG likes to have a bigger GOP or a higher data rate it seems.

I know the I-Frame rate matching the frame rate is recommended to reduce the "ghosting" effect in recording, but you have to make some trade offs it seems.

OR I could be full of shit. Hoping somebody smart chimes in!
 
I am not seeing that in mine which is a HN model, but you might try what I use and see if it still flickers. I always dbl my Iframe to what I have the frame rate set. Also when I export I use avi with NO re-encoding, then upload that to youtube.

Capturev.JPG

 
This is related to this: I'll be the guinea pig for the new SD59225U-HNI PTZ.

Had the cam installed on the roof now for a few weeks. And I gotta say, I'm disappointed in this cam.
I understand it could be user error, but that's why I'm asking here.

I'm still running the original firmware on it from July 2016, I shy away updating firmware for the obvious reasons. Mono price STP cat5e used, monoprice Rj45's, powered by included power brick via 14awg.
I've messed with the settings daily, and don't seem to have improved on it much.

For one, the picture flickers at 1 second intervals, in certain daytime lighting conditions. I've tried the different flicker settings, makes no change. I've set to defaults no change. The flicker is visible directly viewing the cam, from recordings to the SD card, and it's worse, when viewed in Blue Iris either live or recorded and in the substreams. Doesn't flicker at night.

Sample video below was exported from BI to mp4. It seems whatever Youtube does, has reduced the flickering some in sample video. Cam is set to 15FPS @ 6144 bitrate, CBR, Iframe 15. H.264H encoding.

Here is an example video, any suggestions greatly appreciated. Thanks.



Which Default button did you push? The one under system? If so try hitting the default button under conditions. The one under System did not reset all of the condition settings for me. Once I did that I got much clearer video, faster PTZ and focus.
 
This is related to this: I'll be the guinea pig for the new SD59225U-HNI PTZ.

Had the cam installed on the roof now for a few weeks. And I gotta say, I'm disappointed in this cam.
I understand it could be user error, but that's why I'm asking here.

I'm still running the original firmware on it from July 2016, I shy away updating firmware for the obvious reasons. Mono price STP cat5e used, monoprice Rj45's, powered by included power brick via 14awg.
I've messed with the settings daily, and don't seem to have improved on it much.

For one, the picture flickers at 1 second intervals, in certain daytime lighting conditions. I've tried the different flicker settings, makes no change. I've set to defaults no change. The flicker is visible directly viewing the cam, from recordings to the SD card, and it's worse, when viewed in Blue Iris either live or recorded and in the substreams. Doesn't flicker at night.

Sample video below was exported from BI to mp4. It seems whatever Youtube does, has reduced the flickering some in sample video. Cam is set to 15FPS @ 6144 bitrate, CBR, Iframe 15. H.264H encoding.

Here is an example video, any suggestions greatly appreciated. Thanks.



I'd run my bitrate maxed out, especially with lots of color and all, would make sense since it doesn't do it at night when you don't need as much bitrate, I'd certainly max out all of the settings before calling the camera crap. I run 8192 cbr and have not noticed anything, I didn't notice much in your video either I mean 15fps light isn't going to be all super smooth, try extreme like 30fps and see if it looks the same.
 
  • Like
Reactions: looney2ns
Like NoloC Ive experienced that on a number of cams and agree it seems to be caused by Iframe and bitrate settings. For me it was more pronounced in low light.

On one camera, a Dahua 5231 bullet, it was noticeably worse using VBR and went away for the most part when I went to CBR 15/15 and 8192 bitrate. On another cheap Dahua CVI camera, I simply raised the DNR a bit and it went away enough to no longer be noticeable.
 
  • Like
Reactions: looney2ns and NoloC
Well if what you are seeing is that change on the grass then:
I played with one of my Hiks and it did seem to change with I-Frame interval. But it was also possible to reduce the artifact by going to VBR and increasing the data rate. See if yours does that too. It makes sense as the I-Frames are the largest payload and if you are CBR with one a second (15 for 15fps), they get a limited amout of bandwidth for a whole frame of picture. MPEG likes to have a bigger GOP or a higher data rate it seems.

I know the I-Frame rate matching the frame rate is recommended to reduce the "ghosting" effect in recording, but you have to make some trade offs it seems.
OR I could be full of shit. Hoping somebody smart chimes in!

Yes, the grass is where it is noticeable the most, but without Youtube processing, it can be seen in the entire picture.
@tdwilli1 I've used every default button I could find.

@NoloC what is GOP you mention?

So the other cause could be me being too OCD about it.
Thanks all, I'll play around some more with it.
 
Yes, the grass is where it is noticeable the most, but without Youtube processing, it can be seen in the entire picture.
@tdwilli1 I've used every default button I could find.

@NoloC what is GOP you mention?

So the other cause could be me being too OCD about it.
Thanks all, I'll play around some more with it.

GOP is iframes I believe, did you max out the bitrate?
 
GOP is iframes I believe, did you max out the bitrate?

I maxed out the bitrate, it helped some, but it was still obvious.
For the umptenth time I set back to default on the video tab, that puts it back at 25fps, 4096, and low and behold, it looks a 100% better.
I now put it back to 15/15 and 6144 bit rate, and the flickering is gone.
Now it looks like I expected it to look, when I max out the bit rate it does improve some more.

I also noticed that my time setup had reverted to default by itself, 24hr time, and M/D/YR. and it took me a couple of tries to get it to go back the I wanted it. All seems much better.

You know when you mess with something so much that you don't remember what you have or have not tried. ARRGGGHH!

All's right with the cctv world once again I believe.
Thanks for the replies.
 
So GOP is "Group Of Pictures", or I-Frames, more or less. h264 and other discrete cosign transform based compression schemes (MPEG), use a GOP to reduce bandwidth of a video stream. There are 3 types of frames. I,B, & P. The I being the only one to contain the entire picture as the rest are just differences or changes. So that let's the codec suck out information to make the stream smaller. So a group of pictures might look like
" IBBPBBPBBPIetc" where the next GOP is started by a new I-Frame. So the longer the GOP, distance between I-Frames, the less bandwidth required. Any members of the ITU-T or MPEG please forgive this attempt at explaining.

So when we lower the I-Frame interval we are not allowing the compression to be as efficient. We are forcing the higher bandwidth I-Frames more frequently. So either we need a higher bit rate or we will lose some detail in the decoded picture. I would think this would be worse in cbr since the codec can be opportunistic and use more bits where needed like the I-Frames if using vbr.

So I think the relevant stuff to mess with is the I-Frame interval, Bit rate, vbr-cbr (picture quality). Did you set the I-Frame interval up to 100 or 50 and see what you get? If it comes back.:)

There also seems to be some changes due to clouds and the iris maybe breathing a bit there to compensate. So maybe depth of field increased and more noticeable. Anyway Glad it is better!
 
While I thought I understood that a little, you helped make it more understandable, thanks!
 
  • Like
Reactions: NoloC
New firmware:

10-31-2017 4-18-07 PM.png 10-31-2017 4-18-37 PM.png 10-31-2017 4-27-07 PM.png
 
Last edited: