Video Stutter?

[Rickoo]

I've been searching for tips on reasons why I'm getting video stutter and possible ways to prevent it without much luck. I currently have four cams operational. Two Dahua IPC-T5442T-ZE, one Dahua DH-IPC-HFW2831T-ZAS and a Hikvision DS-2DE4A425IW-DE PTZ. This Hikvision PTZ seems better than the Dahuas. All cams have a some degree of "jerk" or "stutter" to them. The only thing that appears to effect any change at all is when I adjust the span between the frame rate and the Iframe interval. The larger the span between these, the longer the interval between the "stutter" in the video. Viewing live stream on a browser or on Tinycam on a tablet is pretty much the same. The stream will all but stop for a second then speed up and catch up. Watching a recording on BI is definitely better, but still shows some stutter/jerkiness. I'm okay with it if this is normal. If there is a way to get smoother live streaming, that would be great.

Is this typical? Any suggestions on things to try to mitigate the issue?

 

[Mike A.]

How do you have the video settings set up? What are you using for frame rate, bit rate, and I Frame? Capture and post that video tab from the cam's interface.

Try H.264, Smart Codec off, FPS 20, CBR, Bit Rate 8192, I Frame 20. That should be relatively smooth. You can work back from there some.

 

[Rickoo]

Thanks. Here are video and exposure settings. The stutter is pretty much only when live streaming. Again, the stutter gets longer in duration when I extend the gap between frame rate and iframe. With the settings shown, the video pretty much stops every second and then starts again. Bit rate and codec on/off doesn't seem to make any difference. I tried to make a clip showing the issue but recorded video is fairly smooth.

 

[wittaj]

Match iframes and FPS and have codec the same with the main and substream. You have H264 for one and H265 for the other.

How is the camera connected to your system - is the camera connected to the router or is it behind a VLAN, NVR, or dual NIC system?

 

[Old Timer]

Make sure your FPS and I frames are the same for both main stream and sub stream. IE. all 4 at 20.

 

[Rickoo]

Thanks. I set the FPS and Iframes of both main and sub streams at 20. Unfortunately it didn't solve the issue. I feel a little embarrassed I didn't already do that.

The cameras are connected to a poe switch that's connected to an Elitedesk 800 G4 SFF, i5-8500, 128SSD, 16GB. 8tb Purple. Dual NIC. Cameras do not have access to the internet. No wifi cams. I do have a separate wifi router connected to the switch that allows me to connect an android tablet running Tinycam to view the cameras.

For what it's worth, I'm using Chrome for a browser.

One thing I noticed when viewing one cam (that seems the worse for some reason) in live view, after a short time, the video reverts to sub stream. I get a message at the bottom of the video that says "it has auto switched to substream for better video playing experience" . The other 5442 doesn't do this. It will stay on the main stream as long as I'm viewing it.

 

[sebastiantombs]

To me, that's typical of IP cameras, frame rates, iframe rates and bit rates. I see the same thing on all my cameras. Annoying at times, maybe, but nothing to pull hair out about.

That message you're getting seems to be generated either by Chrome or UI3 due to processing capacity limits on your laptop and has nothing to do with BI itself.

How is playback on the BI console?

 

[Rickoo]

I wondered if the message was because of the demand on my laptop as well. The weird thing is it only seems to happen when viewing the one camera. I can't get it to do it on the other. The other cam remains on main stream. And this only happens when viewing in a browser. Not BI.

Interestingly, I just re-opened BI and even viewing playback on the console the stutter was visible.

Honestly, I'm not very good with BI. Really need to invest some time on it.

To me, that's typical of IP cameras, frame rates, iframe rates and bit rates. I see the same thing on all my cameras. Annoying at times, maybe, but nothing to pull hair out about.

That message you're getting seems to be generated either by Chrome or UI3 due to processing capacity limits on your laptop and has nothing to do with BI itself.

How is playback on the BI console?

 

[sebastiantombs]

BI does take time, experimentation and asking questions. Is there anything different about that one camera, like frame/iframe/bit rates and codec. Double check and make sure that both the main and sub streams are set exactly the same way. The best advice is to use plain H264 for your codec and 15/15 for frame and iframe rates. I run 2MP cameras at 2048 bit rates and 4MP cameras at 8192 for a bit rate. They still stutter but that's the nature of the beast.

Again, this is surveillance, not movie making. There will be stutter and, if you look carefully at the high res image, you'll see some pulsing about once per second if the frame and iframe rates are the same. That can be mitigated, but not eliminated, by increasing the bit rate.

 

[Rickoo]

I decided to try VBR 6 (Best). Stutter is pretty much gone. I've read you folks generally suggest CBR. Frame rate 15, Bit Rate 8192. Would I compromise something by leaving it on VBR?

 

[Rickoo]

BI does take time, experimentation and asking questions. Is there anything different about that one camera, like frame/iframe/bit rates and codec. Double check and make sure that both the main and sub streams are set exactly the same way. The best advice is to use plain H264 for your codec and 15/15 for frame and iframe rates. I run 2MP cameras at 2048 bit rates and 4MP cameras at 8192 for a bit rate. They still stutter but that's the nature of the beast.

Again, this is surveillance, not movie making. There will be stutter and, if you look carefully at the high res image, you'll see some pulsing about once per second if the frame and iframe rates are the same. That can be mitigated, but not eliminated, by increasing the bit rate.

And no, I made sure both cams had the exact same settings everywhere in the Browser. There may be differences in BI however.

 

[sebastiantombs]

If VBR works for you, go for it. I saw some motion detection problems, missed events, with VBR so went back to CBR. As with everything, YMMV.

Another thing to look at is hardware versions. I have two 5442T-AS. One is from when they first came out and the other is much newer. There are major differences between the two even though they are the same model camera. The latest firmware, actually a test firmware, has made a difference in that older one though.

 

[Mike A.]

I decided to try VBR 6 (Best). Stutter is pretty much gone. I've read you folks generally suggest CBR. Frame rate 15, Bit Rate 8192. Would I compromise something by leaving it on VBR?

It's OK to leave. You'll at least potentially lose a little video quality since the cam is varying the bit rate based on whatever logic to assess what's required to present the scene at a given time. Probably not noticed much in most cases at most times. Doesn't make a lot of sense that VBR at "Best" would be better since CBR should be at least that quality level at a constant rate, but whatever... these things kind of do what they do sometimes. Maybe just a quirk in the cam or something along the way. Kind of makes me think that something in the chain isn't handling the full stream all that well. I don't see much if any of that effect with mine for people walking. I do see similar with cars driving across the image when set to 15 FPS, less so at 20, but that's kind of expected due to the frame rate and speed.

 

[sebastiantombs]

Do you have a lot of trip lines set up in IVS or are you using SMD in the camera? The camera CPU could be bogging down at that bit rate with IVS or SMD running as well.

 

[CCTVCam]

I decided to try VBR 6 (Best). Stutter is pretty much gone. I've read you folks generally suggest CBR. Frame rate 15, Bit Rate 8192. Would I compromise something by leaving it on VBR?

That says to me it could also be a bandwidth limitation somewhere in the network. The difference between CBR and VBR is obviously that VBR is variable. However that does give it the scope to use LESS bandwidth at any given setting. eg 8000kbs.

Unless I'm mistaken, CBR will always transmit at 8,000Kbs because that's what it's set to compress to. However, with VBR, if the image will be compressed into less space if all the bandwidth isn't needed, so it might only use 3,000Kbs even though 8,000Kbs is selected. 8,000Kbs here is just the UPPER limit. It just depends on how much detail is changing within the picture itself.

The fact therefore the stutter is gone with VBR suggests that maybe your bandwidth constricted somewhere. Have you tried swapping out patch cables?

Also check the settings are identical in both cameras to ensure that a codec issue isn't in play. Codecs can be funny old things and it's always possible your laptop can't cope with some setting.

H265 would alarm me to a red flag on an old laptop as I believe only the latest Intel Processors have decoders for it built in - maybe this is an indication you have hardware acceleration checked on the problematic camera but not the other?

A few possibilities.

 

[Rickoo]

Do you have a lot of trip lines set up in IVS or are you using SMD in the camera? The camera CPU could be bogging down at that bit rate with IVS or SMD running as well.

Nothing. Haven't ventured into those areas yet.

 

[Rickoo]

Thanks for everyone's help. I have about 75 feet of solid copper Monoprice Cat6 ethernet cable between the camera and a patch panel in a media cabinet that has a short (4 inch?) cheapo patch cable between the patch panel and the switch. I'll try swapping that out and see if makes a difference!

The laptop is a Microsoft surface book 1. It is a bit old. i7-6600U CPU @ 2.60GHz

Setting are identical with both cams.

That says to me it could also be a bandwidth limitation somewhere in the network. The difference between CBR and VBR is obviously that VBR is variable. However that does give it the scope to use LESS bandwidth at any given setting. eg 8000kbs.

Unless I'm mistaken, CBR will always transmit at 8,000Kbs because that's what it's set to compress to. However, with VBR, if the image will be compressed into less space if all the bandwidth isn't needed, so it might only use 3,000Kbs even though 8,000Kbs is selected. 8,000Kbs here is just the UPPER limit. It just depends on how much detail is changing within the picture itself.

The fact therefore the stutter is gone with VBR suggests that maybe your bandwidth constricted somewhere. Have you tried swapping out patch cables?

Also check the settings are identical in both cameras to ensure that a codec issue isn't in play. Codecs can be funny old things and it's always possible your laptop can't cope with some setting.

H265 would alarm me to a red flag on an old laptop as I believe only the latest Intel Processors have decoders for it built in - maybe this is an indication you have hardware acceleration checked on the problematic camera but not the other?

A few possibilities.

 

[looney2ns]

Watch the actual frame rate as reported by Bi. If it drops down much, it could be network issues. It should remain fairly steady. This can be caused by bad or iffy crimps on the rj 45s. Or improper punch down on the patch panel or the twist wasn't properly maintained at the punch down.

 

[Rickoo]

Just looked at the frame rate in BI. It's pretty stable at 20fps. Might range from 19.8 to 20. It's dark and there's not much happening in the video now. I'll check in the daylight tomorrow as well. Thanks.

 

[Rickoo]

I don't think it's signal loss. Changed out the cheapo patch cable with no change. Frame rate stays fairly constant in BI. With VBR I notice a significant loss of video quality over CBR. I assume it's because it's dropping the frame rate when there is not a lot of movement? When I raise the iframe interval to 100 or more with a frame rate of 20, it definitely has a direct effect on the stutter. Video still has what I assume is normal stutter when moving vehicles pass by, just the more significant interval of motion stop becomes less frequent with higher iframe rates. The time between motion stop appears directly proportional to the span between FPS an iframe interval.

I'm learning a lot through this exercise. I'm ok with what I have, but does the effect of the relationship between frame rate and iframe tell us anything useful?

What would be the the disadvantage of leaving the iframe at 100 or more?