"Overflow" Error (Output)
ERROR
"Offline - Overflow" error on an output stream
ISSUE
Two different conditions inside the Broadcaster surface as the same "Overflow" error on an output.
1. The output's send queue is full.
This applies to SRT outputs, in both caller (push) and listener (pull) mode. Each SRT output holds a fixed send queue of 10,000 packets. For every packet handed to the output the Broadcaster checks how full that queue is; if it is full, the packet is dropped and the output is flagged Overflow. The flag clears automatically once the queue drains below half full. On its own this condition does not disconnect the target: the output keeps running, and packets are lost for as long as the queue stays saturated.
2. The output has stopped draining and is holding up the source.
Any output type can hit this one. If an output falls almost a full source buffer behind the stream, or the packet it has still not sent is more than 40 seconds old, the Broadcaster treats the output as stuck and disconnects it with reason overflow, so its status goes Offline. A few internal output types are re-added automatically a moment later instead of being disconnected.
For failover and merged inputs, the input itself also raises Overflow for as long as any of its legs reports new overflows.
In both cases the queue or buffer fills because data arrives faster than the output can send it out. The usual causes are:
- Source bitrate spikes or bursts, for example from a VBR encoder on high-motion or cut-heavy content.
- A max bitrate set far above the stream's real bitrate on the source. Max bitrate does not size the output's send queue. What it does is govern how large a burst the Broadcaster will admit and pass downstream, so an inflated value lets bursts through that the target link cannot drain in time.
- Not enough sustained capacity on the path to the target, or, for SRT outputs, an SRT latency setting that is too low for the round trip time to that destination.
Note that "Overflow" is also reported by HLS/DASH and recording outputs for an unrelated reason, where a segment or upload buffer could not take the data. Those cases are not the send queue condition described here.
RESOLUTION
- On the source, set the max bitrate to roughly 1.5 to 2 times the actual bitrate of the stream, measured against the peak rather than the nominal average. A max bitrate set well above the real rate allows bursts the target cannot drain in time, and values outside this range can cause the stream to experience issues.
- Confirm the target's downstream network or link has enough sustained capacity for the stream's peak bitrate.
- For SRT outputs, check the SRT latency against the measured round trip time to that specific destination. A latency below roughly 3 to 4 times the RTT is a frequent cause of overflow on longer paths. For a fuller walkthrough, including how to tell overflow apart from a network timeout, see "SRT Target overflow disconnects Troubleshooting guide".
- To confirm overflow is really the trigger, check the Broadcaster system log around the event. At the default log level you will see the output being dropped for buffer pressure, logged as an on_distributor_sink_stuck entry for the affected output immediately before the reconnect. The raw per-packet overflow events, logged as OnRealData OVERFLOW, are written at debug level only, so raise the log level to debug if you need them.
Related errors, not to be confused with this one:
- "Max bitrate times latency too high" is a separate error, raised at connection setup rather than at runtime, when the max packet rate multiplied by the latency exceeds the internal buffer limit of 524,288 packets. If you see that specific wording, reduce the max bitrate and/or the latency. Note that for Zixi pull and push sources the max packet rate is inherited from the upstream feeder, so the setting that needs changing may be on the feeding object rather than on the one showing the error.
- The ZEN Master "Performance warning" alert, "Performance related overflows detected - Validate Max Bitrate and Latency settings", is raised against the source when its distributor overflow counter increases. It points at the same underlying pressure, but it is a source-side signal and not the output error described on this page.
