Hi Martin - was wondering if there's still investigation regarding ever-increasing delays in RTSP streams - Cubes specifically?

A few notes about what I'm seeing:

- Running 11.0.0.63 x64
- These are Cube model 220's, hardwired, 1080 @ 30, main profile, various bitrates
- Amount of delay varies between Cube's, and runs about 5% (a few seconds per minute running)
- VLC used as a control test - no delay experienced with VLC

I'm having the issue even with just one Cube, but for fun I wired two Cube's to an HDMI splitter so they were processing the same signal. As expected, they started out in sync with each other, but both began to show noticable drift within 30 seconds or so. IOW, they were both off, but by different amounts. For the VLC control test, I opened a separate instance for each Cube, and they stayed in perfect sync with the input and each other throughout.

I think I saw a post about an experimental fix involving non-standard timing from Cube's - is this the latest news, and would I expect to have that fix in 11.63 with default input settings and/or settings carried over from pre-11 usage?

I've got a decent test setup rigged, so I'm better able to test any ideas you have than a few months ago when we last kicked this around.

Mostly unrelated, but I did have success trying a Ubiquiti airCam using RTSP, and that didn't show any delay. Not the world's greatest camera, but a good value at <$100 and super-easy to rig and manage, especially if already using Ubiquiti links.

Thanks!
David McBride

Martin, I'm experiencing the same issue. Config:

- vMix 11.0.0.66 x64
- Intel i7 3.5GHz, 16gb RAM, Vidia GTX 660 2gb GPU, Win 7 x64
- 10 Axis P3346 cameras, capturing 1920x1080 @ 30fps, outputting h.264 1280x720 @ 30fps
- 10 Stream inputs (RTSP over TCP), one for each camera
- 5 Colour inputs (green) with MultiView for two Stream (camera) inputs, providing 5 single views showing two cameras in each

Started webcast at 8am today, didn't notice any issues during 2.5 hours. Restarted webcast at 12pm, started to see delays in a single Stream input, eventually as long as 1-2 minutes. This meant that one of two cameras in a view was "live", while one was significantly delayed. Rebooted prior to next webcast at 4pm, problem reappeared after an hour or so. Rebooted again prior to 8pm webcast, and problem appeared after just a few minutes of streaming.

Output to the streaming platform provider remains constant at 25-30 fps, but one camera will be "out of sync" by a significant amount. Cameras are also outputting streams via VLC to separate monitors, which do NOT have this issue. Clearly, there's a problem with vMix.

Buffer levels for all the Stream inputs were default: 300ms and Low Latency unchecked. Should I change these, or any other suggestions to solve this problem?

Thanks!

CPU is about 40% and Render is 30-45ms. I've got all Input thumbnails minimized, so the only render impact is the Live Frame. This wasn't happening initially, but seems to be getting worse over time.

Is there a way to tell vMix not to buffer? So that, if it starts to fall behind, it should abandon remaining frames and move to "now"?

It's hard to know without seeing the statistics window when an input starts to fall behind.

vMix does speed up if the buffer starts to grow, but if the CPU is not capable of decoding quick enough
it will not be able to catch up quickly enough.

Regards,

Martin
vMix

More follow up. After a weekend of webcasts, I'm seeing very, very long delays, as much as 15 minutes, on some IP cameras. I've sent screenshots and stats to Martin for review.