Attempting to solve video stuttering, found this tidbit.

looney2ns

IPCT Contributor
Joined
Sep 25, 2016
Messages
15,646
Reaction score
22,917
Location
Evansville, In. USA
I've always had issue's with video stuttering in BI, since the beginning, some cameras are worse than others. One of my worst cams at this is my "2mp boobie cam", clip playback was very jerky at times on both channels.
I could see the FPS bounce all over the place with live or clip playback in UI3. Both channels on this cam had been set to 8fps.

I had some cameras set for 15fps, some set for 10fps, one at 5fps, and one at 8fps. Using substreams on all but one cam.

I had given up hope of solving it, but when I added the latest review cam, Review-EmpireTech IPC-T5442TM-AS-LED S2, 2.8mm 4mp. | IP Cam Talk, things went further south.
I was testing this cam at 30fps, with a bitrate of 10240.
At times, it had bad stuttering, and pausing at times within BI. It was just fine in it's Live web interface, and videos recorded to the SD card.
I noticed that other cameras also had more issues.

I have in the past, I have re-terminated Rj45s, I had replaced a couple of cables (longest cable run is 60ft).
Checked and double checked BI settings. POE swtich.....everything!
I also have had on some cams, chronic audio drops, during live view and clip playback.

These issue's occurred on both the BI console, but was at times much more pronounced when viewing with UI3 or the android app.

I had two cams, both a 5442ze, that you could see it very briefly pause at a regular interval of 2 secs, on both, UI3 and the console, in both clips and live.
The stats for nerds showed the pausing clearly.

I had tried no HA vs using HA. No joy.

Long story short, I had been reading some of Sam's from BI articles about trouble shooting.

I ran across this comment.
"
FPS

Keep settings simple such that all the streams have the same FPS. Choosing between 30 fps or 15 fps is a user preference. For most surveillance situations, 10 - 15 fps is plenty good.
Setting all streams to have the same fps makes time reconciliation easier for BI.
Turns out certain vendors like Hikvision set different fps (10, 15) for different streams. Different fps settings unnecessarily complicate playback synchronization with dual streams."

In this article:
If this is in the help file, I've missed it many times. But it is the first I had heard of this.

So, I went through and changed all cams to 15fps, and I'll be dog gone, after an hour, it appears to have solved this issue. As always, YMMV.
BI is using a little less CPU and smidgen less memory as a bonus.
I'll see if this fix is long term.
 

sebastiantombs

Known around here
Joined
Dec 28, 2019
Messages
11,511
Reaction score
27,696
Location
New Jersey
I've seen that complaint many times and never really experienced it. I always set all my cameras to 15Fps on main and sub streams. There are two that are running at 20Fps because of higher speed traffic views, but even with that I've never had a video stutter problem. That's why I never comment when I see that complaint. Now I can point them to here. Thanks looney!
 
Last edited:

bp2008

Staff member
Joined
Mar 10, 2014
Messages
12,680
Reaction score
14,041
Location
USA
Hmm. I've long since come to the conclusion that I can't expect perfectly smooth video from Blue Iris. Like, a car driving by will often stutter a little. Even if I take out as many variables as possible and just play a 2MP 30 FPS clip that is main stream only, on the local console. I'm pretty sure the camera isn't at fault. It's just that Blue Iris was not engineered for flawless smooth playback (unlike almost every other video player in the world). But I'm not running all my cams at the same frame rate. Some are 30 / 25 / 15 / 10 / 6.

Streaming to UI3 can be especially bad though because BI needs to transcode the video in realtime which is CPU-intensive, and it can yield lots of dropped frames if the CPU isn't able to keep up. Plus UI3 prioritizes minimum latency over precise frame timing. The HTML5 player (which is default) does try to be perfect in the frame timing, but it is still subject to frames being dropped by Blue Iris's encoder, and exhausting its own video buffer which UI3 tries to keep as small as possible to minimize delay.

The new "direct-to-wire" streaming capability should be the best bet for perfectly smooth playback in UI3, but I don't use that feature so I don't have a lot of experience with it and any quirks it may have. And of course it will only work for single-camera streams from cams that are encoding H.264 natively. And it currently doesn't get used for clip playback I think, so it's only for live viewing.

But in theory, direct-to-wire streaming to UI3 could yield smoother video than local console playback, as long as the video player does not stall due to running out of buffered frames. Because when you use the HTML5 player you get more or less the same frame timing code as is used by major companies like Google (YouTube) and Netflix.
 
Last edited:

looney2ns

IPCT Contributor
Joined
Sep 25, 2016
Messages
15,646
Reaction score
22,917
Location
Evansville, In. USA
Hmm. I've long since come to the conclusion that I can't expect perfectly smooth video from Blue Iris. Like, a car driving by will often stutter a little. Even if I take out as many variables as possible and just play a 2MP 30 FPS clip that is main stream only, on the local console. I'm pretty sure the camera isn't at fault. It's just that Blue Iris was not engineered for flawless smooth playback (unlike almost every other video player in the world). But I'm not running all my cams at the same frame rate. Some are 30 / 25 / 15 / 10 / 6.

Streaming to UI3 can be especially bad though because BI needs to transcode the video in realtime which is CPU-intensive, and it can yield lots of dropped frames if the CPU isn't able to keep up. Plus UI3 prioritizes minimum latency over precise frame timing. The HTML5 player (which is default) does try to be perfect in the frame timing, but it is still subject to frames being dropped by Blue Iris's encoder, and exhausting its own video buffer which UI3 tries to keep as small as possible to minimize delay.Yeh,

The new "direct-to-wire" streaming capability should be the best bet for perfectly smooth playback in UI3, but I don't use that feature so I don't have a lot of experience with it and any quirks it may have. And of course it will only work for single-camera streams from cams that are encoding H.264 natively. And it currently doesn't get used for clip playback I think, so it's only for live viewing.

But in theory, direct-to-wire streaming to UI3 could yield smoother video than local console playback, as long as the video player does not stall due to running out of buffered frames. Because when you use the HTML5 player you get more or less the same frame timing code as is used by major companies like Google (YouTube) and Netflix.
Yeah I see the same even now, but it is MUCH improved, before even someone walking down the street would stop completely every 2 seconds in playback, that is now gone.
With Stats for nerds up, you could clearly see this complete pause, that's not there any longer. The bit rate received stays much more steady now.
 
Top