Sizing latency, buffer and max bitrate

Two settings decide whether a Zixi stream can recover lost packets: latency and Max Bitrate. Loss that looks like a network fault often comes from one of them being set too tight.

A lost packet can be replaced only if the resend arrives before the latency runs out. A longer latency survives longer drops and longer round-trip times, at the cost of delay. Set it to at least 4 times the round-trip time between the two ends.

On a Zixi input, the Broadcaster keeps enough packets to cover the latency, or 1 second if the latency is shorter, at the Max Bitrate. It does not cap the stream. If Max Bitrate is close to the feed rate, bursts and resent packets overflow the buffer and count as not recovered.

Set it to about 1.5 times the feed's average rate: for a 20 Mbps feed, 30 Mbps. At 0, the Broadcaster uses the rate the sender reports. Max Bitrate is in the input's advanced settings: add ?advanced=1 to the Broadcaster URL. In the API the parameter is maxbr.

A value above 65,535 ms does not work as entered. HLS inputs accept at most 60,000 ms.

SRT latency defaults to 1000 ms. The Broadcaster uses the value as entered and does not adjust it to the round-trip time, so set it to at least 4 times the round-trip time yourself.

A UDP output sends packets as they arrive and has no recovery. It never connects, so it never needs to reconnect after a network drop: packets lost on the way are simply lost. If a UDP output goes offline, look at its input, the destination address, the network interface or the license.

This error means the recovery buffer would need more than 524,288 packets. That is about 5.5 Gbps for each second of latency. Lower one of the two.