Skip to content

Quality

media.source.quality

Dead and degraded rules

Every input has a Source settings plaque; empty fields inherit the stream's common rules from the Input timeouts block. That way the thresholds are set once per stream and overridden one by one, while a collapsed plaque shows with chips what exactly is set.

The fields are grouped in three, by what the station does when a rule is broken.

  • When the source is dead — hard failures, switch immediately: Source timeout (s) (no frames at all), Video timeout (no video), Max bitrate (bitrate above the ceiling — protection against garbage on the input).
  • When the source is degraded — soft failures, switch only if there is a better source: Audio timeout (audio gone while video lives), Min bitrate (bitrate below the floor), CC error limit (MPEG-TS continuity violations within the clean window; the field exists only for transport protocols — UDP, HTTP MPEGTS, SRT, RIST).
  • Return and priority — Clean window (s) and Priority.

Degradation is about the quality of the signal, and leaving a degraded input for a dead one makes no sense. So a soft rule does not drop the air, it only lowers the input in the queue. The station names the reason for a mark directly: "more CC errors than the limit", "bitrate below the floor", "no audio", "no frames".

The clean window

The clean window (return_alive_secs, 15 seconds by default) is a period without rule violations. After a quality violation, an input must hold this window to recover its working status. Background probes of inputs opened by Sapsan hold the window before failback or a quality-driven switch without a fresh working verdict. Emergency failover after a hard failure can switch at the first suitable start point (keyframe, audio frame or fragment boundary) without waiting for this window.

This is the protection against a pendulum: a source that comes up for ten seconds and falls again no longer disturbs the air. The flip side is honest and predictable — return to a primary input opened by Sapsan waits for this window. Incoming publications follow different rules; see LSI source management.

What to look at afterwards

Read the detailed input section from the hosting streamer using /streamer/api-v4/streams/stats/{name}; central does not return these detailed counters. Per stream you can see how many seconds it lived on the primary input and how many on the backups, how long it had no data at all, how many switches and retries there were. A growing share of time on the backup means the primary input is systematically bad, even if the air was never interrupted.

Errors broken down by cause are on the Input errors page.