Skip to content

Retransmissão (push)

Sapsan pode enviar um stream de maneira ativa: para as CDNs e plataformas de streaming por RTMP, para outro servidor por SRT ou RIST, ou para a rede por UDP (multicast/unicast). Um stream pode ter vários pushes ao mesmo tempo.

Configuração

Os pushes de um stream formam um mapa de «nome do push — configuração», não uma lista. O nome é único dentro do stream e serve de chave: é por ele que o push é encontrado na configuração, nas estatísticas e nas métricas. Um push tem exatamente um protocolo.

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
Protocolo Parâmetros
rtmp url, connect_timeout_ms
srt host, port, passphrase, stream_id, tempos limite
rist host, port, cache_ms, retransmit_rate_percent, ttl, multicast_interface
udp host, port — MPEG-TS para multicast ou unicast

O nome é a identidade do push. Renomeá-lo não leva nem a configuração nem os contadores acumulados: o push antigo desaparece e o novo começa do zero.

Um push por UDP, SRT ou RIST pode levar a sua própria seção mpegts — número de programa, PID das pistas e SDT próprios, só para esse push: configuração da saída MPEG-TS.

Capacidades e comportamento

  • O push RTMP suporta H264+AAC, HEVC e AV1 (enhanced RTMP), além de streams só de áudio; as marcas de tempo no push começam de zero, como as CDNs esperam.
  • Os erros do push são distinguidos e ficam visíveis no status: conexão recusada, tempo limite de conexão, recusa de publicação (NetStream.Publish.BadName — chave ocupada ou errada), servidor travado (tempo limite de escrita de quadros).
  • Um push SRT com uma passphrase divergente recebe uma recusa no handshake; um receptor silencioso (sem ACKs) é registrado como peer timeout.

Reconexão

O pusher não tem política de novas tentativas própria — quem o levanta de novo é o stream. A cada cinco segundos o stream coteja os pushes em execução com a configuração e substitui um pusher morto por um novo; o contador reconnects conta exatamente essas substituições. Por isso o envio para um destino inalcançável nunca «desiste» nem precisa de reinício manual: ele continuará sendo levantado enquanto o push estiver ativado.

O que não conta como reconexão:

  • editar a configuração de um push — o pusher também é reiniciado, mas é uma decisão do operador, não uma falha do canal;
  • desligar e ligar (enabled: false) — desligar não é excluir: a configuração e os contadores acumulados permanecem, só o envio cessa.

Desativação e exclusão

Um push desativado permanece na configuração com o seu nome: as estatísticas o mostram como desativado, seus contadores ficam congelados nos últimos valores, e ao ligá-lo a contagem continua dali. Excluir a chave exclui também as estatísticas: os contadores pertencem ao nome.

Note

TODO: seleção de pistas para um push (qual qualidade sai).

Monitoramento

Cada push tem estatísticas próprias — destino, status, causa da falha, taxa, bytes, erros, reconexões. A referência de campos, as séries do Prometheus e as receitas de alerta estão na página Estatísticas.

O que vem a seguir