Decoding Acceleration in SRTMiniServer 2.6.6

In version 2.6.6, we optimized the incoming stream decoding chain. In practice, this provides a gain of about 200 ms at the decoding stage — and, accordingly, glass-to-glass (g2g) latency at the client side can be reduced by roughly the same 200 ms.

Baseline measurement: direct SDI connection

When talking about g2g latency, it’s important to first understand what baseline we’re starting from. Even in an ideal scenario, glass-to-glass is not zero: the camera itself, the SDI path, and the monitor all introduce latency.

So first, we made a separate baseline measurement: SDI camera directly outputting signal to an SDI monitor, without any encoding/decoding or network delivery.

With this direct SDI connection, we measured approximately 170 ms glass-to-glass. Obviously, adding an encoding/decoding cycle and network delivery will only increase this number.

Moving to the tests

We decided not to measure in a local network but over a real remote route — through our public proxy in Amsterdam.

The setup looks like this:

Camera (SRT) → proxy (Amsterdam) → SRTMiniServer → SDI monitor

1. An SRT-streaming camera streamed directly to the proxy in Amsterdam.
2. The proxy forwarded the stream to SRTMiniServer.
3. From SRTMiniServer, the signal was output via SDI through a Decklink SDI card to an SDI monitor.

This allowed us to conduct measurements under real-world conditions: network, geographical distance, and a proxy in the chain.

Measurement results

We then performed two measurements under identical conditions — only the version of SRTMiniServer differed:

version 2.6.5:

version 2.6.6:

Conclusion

If glass-to-glass latency is critical in your production workflow, updating from 2.6.5 to 2.6.6 can provide a noticeable improvement. Just download it and try it out!