Fuentes de live stream y LSI¶

media.live.inputs

LSI (Live Source Input) gestiona las entradas de un live stream. Captura los medios de la fuente seleccionada, supervisa su estado y gestiona la recuperación cuando surgen problemas. Si el stream tiene entradas de reserva, LSI evalúa si son adecuadas y elige desde dónde continuar la captura.

Para emitir las 24 horas no basta con abrir una dirección de entrada una sola vez. Una fuente puede mantener la conexión, pero dejar de enviar vídeo. La ruta principal puede recuperarse solo durante unos segundos. La reserva puede no estar disponible justo cuando se necesita. LSI observa las fuentes durante toda la vida del stream y toma decisiones a partir de los datos multimedia.

La gestión de fuentes está integrada en el pipeline de Sapsan:

• Supervisión de la captura detecta la ausencia de fotogramas y los problemas de pistas individuales.
• Evaluación de calidad permite detectar daños en el flujo antes de que la captura se detenga por completo.
• Comprobación de reservas proporciona información sobre su funcionamiento antes de que falle la entrada principal.
• Conmutación coordinada prepara una nueva fuente y envía sus medios a las siguientes etapas del pipeline.
• Observabilidad muestra la entrada seleccionada y los motivos de las decisiones, y permite medir el tiempo de funcionamiento con entradas de reserva.

Qué significa que una fuente funciona¶

Una conexión de red establecida correctamente no significa todavía que la fuente esté lista para emitir. LSI tiene en cuenta la llegada de datos multimedia y la existencia de un punto desde el que iniciar su procesamiento. Para una entrada de vídeo basada en fotogramas, ese punto es un fotograma clave; para una fuente solo de audio, un fotograma de audio. Cuando la captura conserva fragmentos existentes, se utiliza el límite de un fragmento.

El estado de una fuente depende de las observaciones disponibles para su protocolo y de las reglas configuradas:

LSI distingue entre fallo y degradación de calidad. Ante un fallo, no se puede continuar la captura desde esa entrada: por ejemplo, ha vencido el tiempo de espera por ausencia de fotogramas o el tiempo de espera de vídeo configurado. La entrada se cierra y comienza la búsqueda de una alternativa.

Con una degradación de calidad, los medios siguen llegando. Por ejemplo, desaparece el audio o el número de errores de continuidad supera el umbral permitido. LSI busca una fuente más adecuada mientras mantiene la captura actual. Si no hay una reserva en buen estado, sigue utilizando la fuente degradada: la parte de la emisión que aún se conserva sigue disponible.

Este control evalúa el estado técnico de los medios. Los fotogramas que llegan a tiempo con una imagen fija no implican por sí solos que haya vencido el tiempo de espera de vídeo. Las reglas de degradación se describen en el control de calidad de las fuentes.

Cómo elige LSI una fuente¶

Varias entradas en inputs describen fuentes alternativas de un mismo stream. Durante el funcionamiento normal, los medios de la entrada seleccionada se envían a las siguientes etapas del pipeline. De forma predeterminada, la prioridad sigue el orden de la lista; source_options.priority permite cambiarla explícitamente. Un número menor indica una prioridad mayor.

Una ventana limpia es un intervalo sin infracciones de las reglas de calidad. Su duración se establece con return_alive_secs, con un valor predeterminado de 15 segundos. Para volver a una fuente de mayor prioridad, no basta con establecer la conexión: LSI debe observar una captura estable. Esto protege la emisión frente a conmutaciones repetidas a una fuente que se recupera solo brevemente.

La conmutación de emergencia tras el fallo de la entrada actual no espera esa ventana completa: la captura se reanuda en cuanto la candidata está lista. Si aún hay que abrir la reserva, el tiempo de recuperación incluye el establecimiento de la conexión y la espera de un punto de inicio adecuado.

Las conexiones fallidas se reintentan con un retraso creciente. Por tanto, una dirección no disponible no provoca un ciclo continuo de intentos inmediatos. Los parámetros detallados se describen en la redundancia de fuentes.

Cómo se comprueba la reserva¶

LSI puede comprobar una reserva mientras la fuente principal sigue funcionando. La comprobación recibe datos multimedia reales y evalúa su calidad. El resultado incluye el estado de la fuente y la hora de observación; está disponible a través de la API junto con la información de las pistas.

La comprobación periódica se configura con recheck_secondary_inputs_interval: el valor predeterminado es 900 segundos, y 0 la desactiva. Es un intervalo de planificación de comprobaciones en segundo plano, no una garantía de abrir cada reserva exactamente una vez cada 900 segundos. La actividad actual de LSI y los retrasos de reconexión afectan al momento de la comprobación.

Una comprobación en segundo plano correcta termina con el cierre de la entrada de reserva. Por tanto, el estado working de una fuente no seleccionada indica que funcionaba correctamente en la última observación. La antigüedad del resultado se evalúa mediante checked_at. Esto no implica una captura paralela permanente de todas las reservas.

El método de comprobación depende de la entrada. Una fuente a la que Sapsan se conecta puede abrirse temporalmente. En una publicación, el emisor inicia la conexión: LSI observa la publicación entrante, pero no puede abrirla en nombre del emisor. La ventana limpia de retorno descrita se aplica a las entradas que pueden comprobarse; una publicación entrante aceptada puede seleccionarse ya en su primer fotograma de inicio adecuado.

Conmutación y continuidad de la emisión¶

En una conmutación preparada, LSI mantiene la captura actual hasta que la sustituta está lista. Por ejemplo, el stream utiliza una entrada de reserva y la principal se ha recuperado:

1. LSI abre la entrada principal; los consumidores siguen recibiendo los medios de la reserva.
2. La principal supera la ventana limpia.
3. En un fotograma clave adecuado o en el límite de un fragmento, LSI selecciona la entrada principal.
4. El pipeline recibe una notificación del cambio de fuente y los nuevos parámetros multimedia antes de los fotogramas de la nueva entrada.

Así, la espera de la comprobación de la fuente principal no se convierte en una pausa de emisión. La conmutación se realiza dentro del mismo stream con nombre; el operador no necesita detenerlo y crearlo de nuevo.

El procesamiento del tiempo también tiene en cuenta el cambio de fuente. Para las entradas que necesitan alinearse con la hora del servidor, el componente correspondiente del pipeline establece de nuevo esa alineación. Los protocolos con una escala temporal de calendario fiable y los modos que conservan fragmentos siguen sus propias reglas de conservación de marcas de tiempo.

Estos mecanismos permiten organizar una conmutación sin interrupciones con fuentes preparadas y compatibles. El resultado para el espectador depende de toda la cadena:

• Compatibilidad multimedia. Alinee los códecs y la composición de las pistas. Compruebe también los parámetros de vídeo y audio: un cambio de formato puede requerir la reconfiguración del decodificador.
• Sincronización del contenido. Dos fuentes del mismo canal de televisión pueden tener retrasos distintos. Sin alinear el contenido, la conmutación puede repetir u omitir una parte del programa.
• Disponibilidad del punto de inicio. Un GOP largo aumenta la espera de un fotograma clave. Las entradas con fragmentos existentes conmutan en el límite de un fragmento.
• Tipo de fallo. Si la fuente actual desaparece de repente, la conmutación por sí sola no puede recuperar los fotogramas ya perdidos. El tiempo de detección y la disponibilidad de la reserva influyen en la pausa.
• Trayecto de salida. Pruebe la conmutación con los protocolos de entrega y reproductores reales y, si hay transcodificación, con la configuración de transcodificador elegida.

LSI no comprueba la equivalencia completa de los parámetros de codificación antes de cada conmutación. Tener dos direcciones en inputs no garantiza por sí solo una transición imperceptible. Al diseñar el sistema, prepare las fuentes y compruebe la reproducción final. Si ninguna entrada está disponible, la función independiente de cortinilla permite reproducir un archivo preparado.

Ejemplo de configuración¶

Sapsan recibe la configuración a través de la API de central. El siguiente fragmento YAML define dos fuentes UDP alternativas. Los ajustes de lsi establecen la política general del stream, mientras que source_options precisa los parámetros compatibles de una entrada individual.

streams:
  - name: tv1
    inputs:
      - udp:
          host: 239.0.0.1
          port: 5000
        source_options:
          priority: 1
      - udp:
          host: 239.0.0.2
          port: 5000
        source_options:
          priority: 2
    lsi:
      source_timeout: 5
      video_timeout: 3
      audio_timeout: 3
      cc_errors_limit: 10
      return_alive_secs: 15
      recheck_secondary_inputs_interval: 900
      reconnect_initial_delay: 1500
      reconnect_delay_step: 5000
      reconnect_max_delay: 60000

En este ejemplo, no recibir ningún fotograma durante 5 segundos o ningún vídeo durante 3 segundos constituye un fallo de la entrada. La ausencia de audio durante 3 segundos constituye una degradación de calidad. El límite de errores de continuidad es 10 por ventana de evaluación; superarlo degrada el estado de la fuente. Se requiere una ventana limpia de 15 segundos para comprobar el retorno a la principal.

Los tiempos de espera e intervalos de observación del ejemplo se indican en segundos. Los parámetros reconnect_* se indican en milisegundos: retraso inicial de 1500 ms, incremento de 5000 ms y límite de 60000 ms. Estos parámetros de reconexión se establecen en lsi.

Los valores de tiempo de espera son ejemplos. Ajústelos según el comportamiento de la fuente y la interrupción de emisión aceptable. De forma predeterminada, source_timeout es de 60 segundos y los tiempos de espera independientes de vídeo y audio están desactivados.

Qué supervisar¶

La API de central permite consultar el estado de las entradas del stream:

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  http://central:8080/central/api-v4/streams/stats/tv1 \
  | jq '{name, inputs: [.inputs[] | {
      url, current, status,
      problems: (.problems // []),
      checked_at, error, failure_cause
    }]}'

El campo current identifica la entrada seleccionada, mientras que status describe su estado. Son características independientes: la entrada actual puede estar degraded y una reserva, working. Durante una búsqueda de emergencia, current todavía no confirma que se haya reanudado la captura: tenga también en cuenta status y la reproducción real.

• unchecked — todavía no hay un resultado de observación.
• starting — la entrada está abierta, pero aún no ha llegado un punto de inicio adecuado.
• working — la fuente funciona correctamente según las observaciones disponibles.
• degraded — llegan medios con infracciones de las reglas de calidad.
• dead — la fuente no está disponible o se ha declarado fallida.

problems informa de las infracciones detectadas, mientras que error y failure_cause ayudan a diagnosticar los errores. checked_at contiene la hora de observación en UTC, en formato RFC 3339; puede no estar presente en una fuente que aún no se haya comprobado. Solicitar estadísticas no inicia por sí solo una comprobación de la reserva.

Las siguientes señales son útiles para la supervisión operativa:

• Degradación de la entrada actual — current: true junto con degraded o un fallo.
• Pérdida de la reserva — una entrada de reserva ha fallado o lleva mucho tiempo sin una confirmación reciente de buen estado, aunque la entrega actual siga funcionando.
• Conmutaciones frecuentes — aumenta input_switches; compruebe la estabilidad de las fuentes y los ajustes de retorno.
• Funcionamiento prolongado con la reserva — aumenta num_sec_on_secondary_input; la recuperación de la principal requiere atención.
• Ausencia de medios — aumenta num_sec_no_data.

Los contadores detallados de .input están disponibles solicitando las estadísticas de un stream al streamer que realiza la captura: /streamer/api-v4/streams/stats/tv1. El estado compacto de central no sustituye esta sección. En la medición del tiempo en las entradas se proporciona un ejemplo de consulta y las reglas de cálculo de intervalos.

input_switches cuenta las transiciones entre distintas entradas configuradas; reconectarse a la misma entrada no constituye por sí solo una conmutación. Los contadores de tiempo distinguen la primera entrada de la lista de las demás, aunque se hayan cambiado las prioridades. Son valores acumulados: para evaluar un periodo, compare observaciones sucesivas y tenga en cuenta que las estadísticas se reinician al volver a arrancar.

Cómo verificar la redundancia antes de la puesta en servicio¶

1. Confirme que se ha seleccionado la entrada principal esperada. Obtenga un resultado reciente de la comprobación de la reserva y compare inputs[].media_info: los parámetros de las entradas deben ajustarse al diseño del sistema.
2. Interrumpa la fuente principal de forma controlada. Compruebe el cambio de current y el aumento de input_switches mientras observa la reproducción real.
3. Restablezca la fuente principal. En las entradas a las que Sapsan se conecta, confirme que la reserva sigue funcionando durante la comprobación y que el retorno se produce después de la ventana limpia.
4. Pruebe por separado la degradación de calidad sin interrumpir la conexión, por ejemplo la pérdida de la pista de audio con audio_timeout activado.
5. Pruebe el fallo de la reserva mientras la principal funciona: la supervisión debe detectar la pérdida de redundancia antes de que falle la entrada principal.

Qué aporta LSI a un servicio de emisión¶

FFmpeg proporciona herramientas de procesamiento multimedia y puede restablecer conexiones; por ejemplo, HTTP dispone de opciones de reconexión. Al construir un servicio en torno a un comando de FFmpeg, la gestión del ciclo de vida de varias fuentes requiere una solución independiente.

En Sapsan, LSI reúne este trabajo. El operador define las fuentes y la política; el streamer supervisa la calidad y prepara las conmutaciones, mientras que la API proporciona el estado para la supervisión. Así, la redundancia se convierte en una parte gestionable de la emisión continua: se puede comprobar una ruta de reserva con antelación, explicar por qué cambió la fuente y confirmar que la principal se ha recuperado de forma estable.