Skip to content

Retransmisión (push)

Sapsan puede enviar un stream de manera activa: a las CDN y plataformas de streaming por RTMP, a otro servidor por SRT o RIST, o a la red por UDP (multicast/unicast). Un stream puede tener varios pushes a la vez.

Configuración

Los pushes de un stream son un mapa de «nombre del push — configuración», no una lista. El nombre es único dentro del stream y sirve de clave: por él se encuentra el push en la configuración, en las estadísticas y en las métricas. Un push tiene exactamente un 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, tiempos de espera
rist host, port, cache_ms, retransmit_rate_percent, ttl, multicast_interface
udp host, port — MPEG-TS a multicast o unicast

El nombre es la identidad del push. Renombrarlo no traslada ni la configuración ni los contadores acumulados: el push antiguo desaparece y el nuevo empieza de cero.

Un push por UDP, SRT o RIST puede llevar su propia sección mpegts — número de programa, PID de las pistas y SDT propios, solo para ese push: configuración de la salida MPEG-TS.

Capacidades y comportamiento

  • El push RTMP soporta H264+AAC, HEVC y AV1 (enhanced RTMP), así como streams de solo audio; las marcas de tiempo en el push empiezan de cero, como esperan las CDN.
  • Los errores del push se distinguen y quedan visibles en el estado: conexión rechazada, tiempo de espera de conexión, rechazo de publicación (NetStream.Publish.BadName — clave ocupada o incorrecta), servidor colgado (tiempo de espera de escritura de fotogramas).
  • Un push SRT con una passphrase que no coincide recibe un rechazo en el handshake; un receptor silencioso (sin ACK) se registra como peer timeout.

Reconexión

El pusher no tiene política de reintentos propia — lo vuelve a levantar el stream. Cada cinco segundos el stream coteja los pushes en marcha con la configuración y reemplaza un pusher muerto por uno nuevo; el contador reconnects cuenta exactamente esos reemplazos. Por eso el envío a un destino inalcanzable nunca «se rinde» ni necesita reinicio manual: se seguirá levantando mientras el push esté activado.

Lo que no cuenta como reconexión:

  • editar la configuración de un push — el pusher también se reinicia, pero es una decisión del operador, no un fallo del canal;
  • desactivar y activar (enabled: false) — desactivar no es eliminar: la configuración y los contadores acumulados se quedan, solo se detiene el envío.

Desactivación y eliminación

Un push desactivado permanece en la configuración con su nombre: las estadísticas lo muestran como desactivado, sus contadores quedan congelados en los últimos valores, y al activarlo el conteo continúa desde ellos. Eliminar la clave elimina también las estadísticas: los contadores pertenecen al nombre.

Note

TODO: selección de pistas para un push (qué calidad sale).

Monitorización

Cada push tiene estadísticas propias — destino, estado, causa del fallo, velocidad, bytes, errores, reconexiones. La referencia de campos, las series de Prometheus y las recetas de alertas están en la página Estadísticas.

Qué viene después