We have some connections that have some poor network characteristics and in order to be able to stream across them reliably we need to use larger than usual latency buffers in SRT - sometimes as much as 20,000ms. So far we've been using some home-grown scripts that use ffmpeg and stransmit to ship the streams around and then playout into vmix input via SDI. With vmix 23 we're super excited to be able to cut those out of the loop and go direct from the srt source into vmix.

At the moment, the maximum value that can be specified for srt latency in vmix is 1999ms. It is possible to set a larger value on the non-vmix end and the protocol will negotiate both ends to the larger value, but when we use values >1999, in most cases we just get a black screen instead of the actual transmission on the vmix input. Unfortunately a latency setting of 1999 is not enough to buffer through the network conditions that a larger setting will survive.

Is it possible to allow the latency value for SRT to be configured for values much larger than 1999ms (perhaps up to 30,000)?

In our scripts, in order to support a larger latency value, we also needed to increase the "rcvbuf" and "fc" params in the url used on stransmit listener (in our current iteration, fc is set to 5x the latency in milliseconds, and rcvbuf is set to 1500x the fc value).

Also, is there any SRT debug logging or otherwise that might help us diagnose issues with srt, either input or output from vmix?

Thanks!

Thanks for the quick reply - this is great news, we'll give it a spin when it's updated and let you know how things look.


Mainly what we're dealing with are networks that have been set up for a particular event/venue that have good, but limited, bandwidth available (~100mbit or so, typically) and OK latency. The network is typically shared with other users that have usage patterns which overwhelm the network on occasion, resulting in bursts of increased latency and sometimes minor packet loss.

So basically most of the time the network is great, maybe with higher-than-ideal latency (~100ms or so) but with occasional relatively short periods of higher latency or mild packet loss if someone else on the line decides to upload a large file or something like that. We're not too worried about delay in the stream, so having an increased buffer can allow us to weather through the periods of link congestion or loss that pop up. When possible we like to send a pretty high quality stream (up to 20mbit, when possible).

We've been using vmix since we discovered it in 2018 and it continually impresses, thanks for such a great software!

Cheers,
Simon.