Skip to content

Restreaming (push)

Sapsan can actively send a stream onward: to CDNs and streaming platforms over RTMP, to another server over SRT or RIST, or into the network over UDP (multicast/unicast). A stream can have several pushes at once.

Configuration

A stream's pushes are a mapping of push name to setting, not a list. The name is unique within the stream and serves as the key: it is how a push is found in the configuration, in the statistics, and in the metrics. A push has exactly one protocol.

streams:
  - name: tv1
    inputs:
    - udp: {host: 239.0.0.1, port: 5000}
    pushes:
      youtube:
        rtmp:
          url: rtmp://a.rtmp.youtube.com/live2/xxxx-xxxx
      backup-dc:
        srt:
          host: 203.0.113.10
          port: 9000
          passphrase: verysecretpass
      local-multicast:
        udp:
          host: 239.1.1.1
          port: 5500
Protocol Parameters
rtmp url, connect_timeout_ms
srt host, port, passphrase, stream_id, timeouts
rist host, port, cache_ms, retransmit_rate_percent, ttl, multicast_interface
udp host, port — MPEG-TS to multicast or unicast

The name is the push's identity. Renaming carries over neither the setting nor the accumulated counters: the old push disappears and the new one starts from zero.

A push over UDP, SRT, or RIST can carry its own mpegts section — its own program number, track PIDs, and SDT for that push only: MPEG-TS output settings.

Capabilities and behavior

  • RTMP push handles H264+AAC, HEVC, and AV1 (enhanced RTMP), and audio-only streams; timestamps start at zero on push, as CDNs expect.
  • Push errors are distinguished and visible in status: connection refused, connection timeout, publish rejection (NetStream.Publish.BadName — key taken or wrong), a stalled server (frame write timeout).
  • An SRT push with a mismatching passphrase gets a handshake rejection; a silent receiver (no ACKs) is registered as a peer timeout.

Reconnection

A pusher has no retry policy of its own — the stream raises it again. Every five seconds the stream reconciles the running pushes against the configuration and replaces a dead pusher with a new one; the reconnects counter counts exactly those replacements. An unreachable target therefore never "gives up" and needs no manual restart: it keeps being raised for as long as the push is enabled.

What is not counted as a reconnect:

  • editing a push setting — the pusher is restarted too, but that is the operator's decision, not a channel failure;
  • disabling and enabling (enabled: false) — disabling is not deletion: the setting and the accumulated counters stay, only the sending stops.

Disabling and deleting

A disabled push stays in the configuration under its name: the statistics show it as disabled, its counters are frozen at their last values, and enabling continues from those. Deleting the key deletes the statistics too: counters belong to the name.

Note

TODO: track selection for a push (which quality goes out).

Monitoring

Every push has statistics of its own — target, status, failure reason, rate, bytes, errors, reconnects. The field reference, the Prometheus series, and alerting recipes are on the Statistics page.

Next steps