Skip to content

Supervisión de la fuente SDI

media.probe.sdi

Sapsan supervisa la fuente SDI durante la captura: comprueba el estado de la señal, la secuencia de fotogramas y el código de tiempo, y contabiliza los errores notificados por el controlador de la tarjeta. Esto permite distinguir los problemas de la fuente y del cable, los cambios de estándar de vídeo y las pérdidas entre la tarjeta y el pipeline multimedia.

La captura SDI describe la conexión y la captura. Este artículo se centra en el diagnóstico de una entrada ya configurada. El análisis se realiza en el pipeline activo; no requiere un proceso independiente que abra el mismo puerto de la tarjeta.

Qué se comprueba en cada fotograma

El controlador entrega a Sapsan un fotograma de vídeo y los datos asociados. La entrada los contrasta con el estado de captura:

  • Estado de la línea — si hay señal y si corresponde al formato de captura. Se comprueba el estado actual, por lo que la pérdida de una notificación de recuperación de la señal no debería dejar la entrada en su estado anterior.
  • Secuencia de fotogramas — los saltos en los números de secuencia de los búferes de la tarjeta indican fotogramas perdidos antes de que Sapsan los reciba. El salto también se refleja en las escalas temporales del vídeo y el audio.
  • CRC de las líneas SDI — se acumulan los errores de los metadatos del fotograma si la tarjeta y el controlador ofrecen esta comprobación.
  • Código de tiempo ATC — con timecode activado, se comprueba que la hora del día sea válida y que su avance concuerde con la secuencia de fotogramas.
  • Datos auxiliares — se contabilizan los paquetes VANC reconocidos y los errores de procesamiento de los datos admitidos. Las posibilidades de extracción se describen en la captura SDI.

Recibir búferes de la tarjeta no demuestra por sí solo la presencia de una señal útil. Tras desconectar el cable, el controlador puede seguir entregando fotogramas con una marca de error. Sapsan tiene en cuenta esa marca para que la entrada no parezca correcta solo porque aumenta el número de fotogramas.

Estado de la línea y recuperación

La entrada V4L2 actual informa de tres estados:

  • ok — el fotograma recibido no tiene una marca de error de línea. No es una evaluación del contenido de la imagen o del audio.
  • no_signal — el controlador informa de que no hay señal.
  • wrong_standard — hay señal, pero el fotograma está marcado como erróneo respecto al formato de captura actual.

Para tolerar cambios breves, la entrada espera 500 ms de estado de error continuo antes de dejar de enviar fotogramas al pipeline multimedia. Si wrong_standard persiste, la captura se vuelve a abrir a los 2 segundos. Un evento de cambio de señal del controlador puede provocar un reinicio anterior si el estándar se detecta automáticamente.

Si no llegan fotogramas, la captura se reinicia según peer_timeout_ms. Con la detección automática del formato, la entrada muestra no_signal mientras espera la señal; si esta no aparece dentro de ese tiempo de espera, el intento de apertura falla. Con un standard explícito, se omite esta fase de espera. El valor predeterminado de peer_timeout_ms es 30 000 ms. El mecanismo general de LSI gestiona los reintentos y el paso a la reserva; su tiempo de conmutación no equivale a la espera de 500 ms.

Los cambios de estándar y los reinicios de captura se contabilizan por separado de los fallos de la fuente. Un aumento de reinicios después de conmutar la señal en un router requiere una interpretación distinta de los reinicios por ausencia de fotogramas.

Comprobación de la escala temporal y del código de tiempo

La escala temporal del vídeo se construye a partir de la secuencia de fotogramas y de la frecuencia fraccionaria exacta del formato. La escala del audio tiene en cuenta el número de muestras de audio. Con timecode activado, la entrada analiza ATC y puede vincular ambas escalas a la hora de la fuente. La fecha se obtiene del reloj del servidor, ya que ATC contiene la hora del día.

Ejemplo de configuración mediante la API de central:

streams:
  - name: studio
    inputs:
      - sdi:
          device: /dev/v4l/by-path/pci-0000:5e:00.0-video-index0
          timecode: true
          peer_timeout_ms: 30000

timecode está activado de forma predeterminada. Con false, la captura sigue funcionando, pero ATC no controla la escala temporal y no se realizan estas comprobaciones del código de tiempo.

La vinculación requiere un código de tiempo válido:

  • Hora del día — la diferencia respecto al reloj del servidor no debe superar los 30 segundos. El reloj del servidor debe estar sincronizado; puede rechazarse un contador desde el inicio del material o un código de tiempo de otra zona horaria.
  • Frecuencia fraccionaria — 29,97 y 59,94 requieren drop-frame; el código de tiempo a 23,98 no se utiliza para esta vinculación.
  • Secuencia — el código de tiempo debe avanzar de forma coherente con los fotogramas. Una desviación aislada no cambia la escala; un nuevo desfase estable durante aproximadamente un segundo de fotogramas provoca una nueva vinculación.

Antes de la primera vinculación correcta se utiliza una escala sin ATC, que después se alinea con el reloj del servidor. Tras la vinculación, la ausencia del código de tiempo o el fallo de su comprobación conservan el desfase anterior. Una nueva vinculación notifica al pipeline multimedia una discontinuidad de la escala para que el empaquetado posterior tenga en cuenta el cambio de tiempo.

Contador del código de tiempo Significado
timecode_missing Fotogramas sin ATC después de una vinculación correcta. Antes de la vinculación, la ausencia permanente de ATC no aumenta este contador.
timecode_rejected Código de tiempo no válido o incoherente: valor dañado, modo de frecuencia inadecuado, código detenido o desviación inestable.
timecode_untrusted Código de tiempo fuera de la ventana de confianza respecto al reloj del servidor.
timecode_jumps Nuevas vinculaciones a un desfase estable.

Estadísticas mediante la API

Solicite las estadísticas detalladas al streamer que captura SDI:

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  http://streamer:8080/streamer/api-v4/streams/stats/studio \
  | jq '{name, inputs: [(.inputs // [])[] | select(.protocol == "sdi")], input}'

inputs es la lista de fuentes. Una fuente SDI ofrece la siguiente información:

Campo Cómo interpretarlo
current, status, failure_cause, error Si la fuente está seleccionada, su estado general y la causa del fallo.
sdi_line_state Estado de la línea como cadena; el valor ok puede omitirse en JSON.
sdi_producer_restarts_total Reinicios de captura acumulados. El nombre histórico producer no implica un proceso de captura independiente.
sdi_boundary_loss_total Pérdidas detectadas por saltos en los números de secuencia de los búferes de la tarjeta.
sdi_capture Formato de captura aceptado por el controlador, antes de la transcodificación.

sdi_capture contiene las dimensiones del fotograma, el FourCC numérico pixel_format, los bytes por línea en stride y la frecuencia de fotogramas completos fps_num / fps_den. El campo opcional video_bytes_per_second estima el flujo mínimo de datos de vídeo DMA en bytes por segundo, sin audio ni sobrecarga PCIe.

En la sección input del stream, sdi_datagrams_total cuenta los fotogramas recibidos del dispositivo. Pese a su nombre, no es el número de datagramas de red. Los campos con valor cero pueden omitirse. La ausencia de una sección de estadísticas no debe interpretarse como una medición completada sin errores.

Las estadísticas compactas de central incluyen el estado de las fuentes, pero no sustituyen la respuesta detallada del streamer. CRC y todos los contadores de código de tiempo no se presentan en la API como un único objeto input.sdi; utilice la exportación de métricas para consultarlos.

Métricas y mediciones temporales

La exportación de métricas del streamer está disponible en /streamer/api-v4/live-metrics con autenticación. La disponibilidad y el nivel de detalle dependen de la licencia de contadores.

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  http://streamer:8080/streamer/api-v4/live-metrics \
  | rg '^stream_input_sdi_.*stream="studio"'
Serie de Prometheus Significado
stream_input_sdi_line_state Estado actual: 0 — ok, 1 — no_signal, 2 — wrong_standard.
stream_input_sdi_datagrams_total Fotogramas recibidos del dispositivo.
stream_input_sdi_boundary_loss_total Fotogramas perdidos según los números de secuencia de los búferes.
stream_input_sdi_crc_errors_total Errores CRC de líneas notificados por la tarjeta.
stream_input_sdi_producer_restarts_total Todos los reinicios de captura.
stream_input_sdi_producer_restarts_wrong_standard_total Reinicios por el estándar o un evento de cambio de señal.
stream_input_sdi_producer_restarts_silence_total Reinicios por ausencia de fotogramas del dispositivo.
stream_input_sdi_timecode_missing_total ATC ausente después de la vinculación.
stream_input_sdi_timecode_rejected_total ATC rechazado.
stream_input_sdi_timecode_untrusted_total ATC fuera de la ventana de confianza del reloj.
stream_input_sdi_timecode_jumps_total Nuevas vinculaciones de la escala mediante ATC.

El vocabulario común de estados de línea también incluye late, duplicate e invalid; la entrada V4L2 actual no los detecta como tres defectos independientes de la señal. Para algunos contadores, la serie solo aparece después de un evento, por lo que su ausencia no confirma que la tarjeta admita la comprobación.

Además, el monitor general de la escala temporal compara la hora de llegada de los medios con DTS antes de la alineación de las marcas de tiempo. Las estadísticas del stream contienen source_timing_offset_ms y source_timing_jitter_ms, además de los límites source_timing_offset_min_ms / source_timing_offset_max_ms. source_timing_offset_ms muestra el desfase actual; el jitter y los límites del desfase corresponden a la ventana de un minuto completada. source_timing_input y source_timing_window_started_at indican la fuente y el inicio de la ventana.

Estas mediciones ayudan a detectar cambios de retraso e irregularidades en la llegada de los medios al pipeline de software. No miden el jitter eléctrico de SDI. Comprobar cada fotograma tampoco significa que la API exporte el historial de todas las marcas de tiempo: expone el estado y los resultados agregados.

Cómo interpretar los resultados

Observación Qué comprobar
no_signal La fuente, el cable, el enrutamiento y la entrada seleccionada de la tarjeta.
Aumentan los reinicios por estándar Las conmutaciones de fuente, el formato detectado automáticamente y el standard explícito.
Aumentan los reinicios por ausencia de fotogramas El controlador y el funcionamiento de la captura; contraste los eventos con los logs del servidor.
Aumenta boundary_loss Las pérdidas por números de secuencia de los búferes: la carga del servidor y la capacidad del pipeline para recibir a tiempo los fotogramas de la tarjeta. El contador por sí solo no identifica la causa.
Aumenta crc_errors La integridad de la señal de entrada según los datos de la tarjeta. Cero no confirma la ausencia de errores si la tarjeta no proporciona CRC.
Aumenta timecode_untrusted La sincronización del reloj del servidor y la finalidad del código de tiempo de la fuente.
Aumentan timecode_rejected o timecode_jumps La configuración y estabilidad del generador ATC y las conmutaciones de fuentes.

Compare el incremento de los contadores durante un intervalo, no solo el valor acumulado. Contraste el estado de la línea con la llegada real de fotogramas: cero pérdidas en una entrada detenida no significa que la señal sea correcta.

El diagnóstico depende de los datos que proporciona el controlador. Estos indicadores no miden el jitter eléctrico de SDI, la amplitud ni el diagrama de ojo. Para esas mediciones se necesita un analizador de señal física. La supervisión de ATC tampoco comprueba si la imagen está congelada o si el audio está en silencio.

Para la captura de alta velocidad, tenga en cuenta por separado los requisitos de servidor y memoria de 12G-SDI. Evalúe el formato de captura y las pérdidas en la tarjeta antes de transcodificar: reducir la tasa de bits de salida no reduce el volumen de los fotogramas de entrada sin comprimir.