Saltearse al contenido
ARGUS User Manual

Reenvío de streams

ARGUS puede retransmitir cualquier pista TACLINK en directo a un destino externo como RTMP (push) o RTSP (pull). El backend (argus-api) lanza un relay de FFmpeg por reenvío, persiste el estado y las estadísticas en Firestore, y expone la lista activa dentro del tile de streams.

Abrir el diálogo de reenvío

Desde una tarjeta de stream en la cuadrícula TACLINK, haz hover para revelar el menú de opciones (⋯) y elige Forward. El diálogo de reenvío se abre con el stream preseleccionado. El signal fwdDialog guarda { peerId, trackId, streamName } para que el diálogo sepa qué pista está reenviando.

El selector de protocolo

Dos botones toggle en la parte superior del diálogo — RTMP o RTSP.

RTMP — push

Proporcionas la URL de destino. Forma típica:

rtmp://live.example.com/app/stream-key

El relay de FFmpeg empujará la pista allí. La mayoría de servicios de streaming (YouTube Live, Twitch, CDNs de calidad broadcast, Wowza, Ant Media, OvenMediaEngine) aceptan ingesta RTMP.

La URL puede incluir una clave de stream o auth — lo que sea que el destino espere. La URL se trata como sensible y se cifra en reposo con la clave E2E de la operación antes de escribirse en Firestore.

RTSP — pull

Sin entrada de URL. El backend de ARGUS expone un endpoint RTSP; tú haces pull desde él. Al arrancar con éxito, el registro del reenvío se rellena con rtspPullUrl, que el diálogo muestra — cópiala y pégala en tu reproductor / grabador.

Útil para:

  • Alimentar un NVR local que habla RTSP.
  • Alimentar un VMS on-premise que ingesta RTSP.
  • Agencias partner que quieren hacer pull con ffmpeg / vlc / go2rtc sin exponer su propio endpoint push.

Campos comunes a ambos

  • Nombre — obligatorio. Etiqueta corta usada en el panel de reenvíos activos.

Haz clic en Iniciar. El diálogo se cierra y el reenvío aparece en el panel activo (normalmente en menos de un segundo — estado “starting”) y luego transiciona a “active” cuando FFmpeg está produciendo bytes.

El panel de reenvíos activos

Una lista en la parte inferior del tile de streams muestra cada reenvío activo para esta misión. Filas:

  • Punto de estado — verde para active, ámbar para starting, rojo para error, gris para stopping.
  • Nombre (tal como lo introdujiste en el diálogo).
  • Badge de protocolo — RTMP o RTSP.
  • Bitrate (kbps) — actualizado del lado del servidor cada pocos segundos.
  • Frames reenviados / perdidos — haz hover en la fila para el tooltip de detalle.
  • Botón Detener — termina el reenvío.

La lista está filtrada a reenvíos cuyo estado sea starting o active — los reenvíos detenidos y con error salen de la lista pero permanecen en Firestore para el historial.

Qué se guarda en Firestore

Cada reenvío escribe un documento stream_forwards con:

  • id — UUID.
  • operationId — a qué misión pertenece.
  • name — etiqueta introducida por el usuario.
  • protocol — rtmp / rtsp.
  • peerId + trackId — qué pista se está reenviando.
  • destinationUrl — sólo RTMP. Cifrado con clave E2E.
  • rtspPullUrl — sólo RTSP. La URL de pull generada (no sensible — no está cifrada directamente, pero el TLS de tu argus-api detiene el acceso no autorizado).
  • status — starting / active / stopping / stopped / error.
  • bitrateKbps, framesForwarded, droppedFrames — actualizados por el servidor.
  • createdOn, createdBy — rastro de auditoría.

Las consultas del servicio se filtran a la misión actual y se ordenan por createdOn descendente.

Detener un reenvío

Haz clic en Detener en la fila. El servicio envía un POST a /api/stream-forwards/{forwardId}/stop. El reenvío transiciona a stopping, FFmpeg se mata limpiamente, el estado pasa a stopped, y la fila sale de la lista activa.

Si tu navegador se cayó entre iniciar y detener, el reenvío sigue ejecutándose — simplemente vuelve a la consola, inicia sesión y haz clic en Detener. Los reenvíos no están vinculados a tu sesión.

Fallos

Si el destino rechaza la conexión (URL incorrecta, fallo de auth, destino caído), el reenvío transiciona a error con la razón capturada en el registro. Un toast en la UI expone el string de error del servidor.

Causas típicas:

  • Auth RTMP incorrecta — tu clave de stream es incorrecta o ha expirado.
  • Ingesta RTMP caída — el endpoint de ingesta del destino no es alcanzable.
  • Desajuste de codec — ARGUS envía H.264 + AAC. Si tu destino sólo acepta H.265 u Opus, el reenvío dará error.
  • Red bloqueada — los firewalls corporativos en tu servidor pueden bloquear RTMP saliente (puerto 1935) — usa RTMPS o RTSP en su lugar.

Consideraciones de seguridad

  • Las URLs de destino (claves push RTMP) están cifradas en reposo con la clave E2E de la operación. Nunca aparecen en logs.
  • El UID del operador se adjunta a cada registro de reenvío para auditoría.
  • Los reenvíos persisten más allá del fin de la misión por cumplimiento — consulta retención de datos para las reglas de limpieza.

Limitaciones conocidas

  • Sin multi-destino — un reenvío = un destino. Usa múltiples reenvíos en la misma pista si necesitas varias salidas.
  • Sin opciones de transcodificación — obtienes el codec fuente tal cual. Si necesitas re-codificación, ejecuta un transcodificador (Node-Media-Server, Ant Media) en el destino.
  • Sin inicio programado — los reenvíos comienzan inmediatamente al hacer clic en Iniciar; no hay opción “iniciar a las 14:00”.
  • Sólo disparado por cliente — no hay automatización de flujo de trabajo que inicie un reenvío sobre un evento (p. ej. “iniciar reenvío RTMP cuando se active la misión”). Previsto.

Relacionado