We are using two IP cameras for webcasting of a small meeting. These are surveillance-type cameras but producing a very good HD picture. But, we're seeing periodic frozen frames on the input to vMix. The freezes last from 2 to 10 seconds, and appear at what seems to be random times. We've adjusted bitrate on the incoming video (1200-8000), resolution (480P-1080P), encoders, quality of video and constant versus variable bit rates. Nothing we've tried seems to fix this problem. The camera connects as an RTSP device as a streaming source.

We believe that it must be a vMix problem because we can connect the RTSP stream to VLC on the same machine with no freezing.

Interestingly, we have a different brand camera that does not have this same problem.

Has anyone else seen this? Are there some settings we may be missing, or perhaps drivers needed? So far, vMix has been bulletproof for us but this is a critical function and we're stymied.

With both cameras running, total CPU usage is right at about 30%. There is no observable change in CPU usage when the freeze happens. This seems like a buffer problem on the vMix input.

With further investigation, we did notice that when we tried this before with the same camera, we never saw a problem like this but were running version 17. We've since upgraded to version 19.

Has there been any work on this version that could have caused the problem?

Just in case, what's the process for moving back to version 17?

Thanks.

We never used version 18, but did just try version 17 with no difference. We're still completely in the dark on why the stream freezes for the short time before resuming and have verified that the stream is still very smooth coming into the system using VLC.

This is sounding more and more like a bug in vMix.

Are you using Low Latency Capture? What is your buffer setting?

Sounds like it could be a buffering issue on vMix's end. Try higher buffer numbers. Try not using LLC.

Also, what's your network traffic/usage?

- Tom

In answer to recent questions:

We are not using LLC, even though we tried it as an option to see if it would improve (it didn't). We've tried all kinds of buffer sizes, from 0 to 3000. The only difference is that a bigger buffer makes the jumps less frequent, but more severe. With very big buffers, a person can appear to teleport across a stage. In addition, with larger buffers, the sound (from a different source) is un-synchronized right after a big jump and slowly gets back to synchronization, usually just before another jump.

What this looks like with a short buffer is a fairly frequent "skip" of the image to a new position. Sometimes this happens along with a frozen image lasting from .5 sec to perhaps 1 sec.

Yes, we're using UDP and have also tried TCP and any other variant we could think of. (We could not figure out how to import MJPEG, though). Network traffic is very low: about 9Mbps with two cameras and a stream operating. We're on a dedicated, private network with just these three devices so we have been able to rule out network issues.

This has all the earmarks of a buffer bug. It almost seems like the software is using dual buffers (one filling while one processes, then switching), but that it's under-running the buffer, and then switching to the other buffer after some delay. Clearly something is wrong in the timing.

I've noticed that others have seen this with a variety of cameras. While it's true that this does not happen with all IP cameras (we have a couple of other less capable ones), vMix is the common denominator. The feature claim is that it will take a stream input, but it's not at sufficient quality right now and it should support all cameras like VLC and ONVIF utilities which do NOT show this problem.

How do we report a bug? Is this forum monitored by anyone at vMix that could do this? I've noted that this is a lingering problem, but I would anticipate it getting a lot more attention given the rapid increase in capabilities of inexpensive IP cameras.

I think he said it was a PTZ Optics PT12x.

- Tom

Tom, my eyesight isn't what it was even with reading glasses, but the only place I see PTZ Optics is in your post:)

Sorry for the delayed response; just got back from the first use of these systems with an HDMI feed as primary due to the stuttering problem on the IP cams.

The unit we're using is a Dahua SD42212T-HN. The same thing seems to have been reported using a Foscam FI9826W.

Checked video drivers as suggested and they are all up to date. But, I don't think it's a configuration problem as we have now seen this same behavior on 3 different systems running vMix independently and on different networks. Systems are all running Win 10 with latest updates (KB3150513).

I'd be ecstatic to find someone who had found a solution to this problem.

There's no option in the controls to change the MTU. Are you thinking that this might be caused by the computer not being able to handle the size of the data block from the camera, or that in an attempt to minimize network traffic that the camera is holding on to data for too long?

That is also an interesting theory, although I'm not sure how it explains the behavior we've seen with various size buffers. Plus, it doesn't explain why other software like VLC doesn't show this same problem.

Man, I really hate shooting in the dark on these things. Does anyone know the mechanism to report a bug to vMix to help figure this out? I'd even lend them the camera.

Very good to know and we'll definitely look at this. Thanks much.