Skip to content

Vinculación con la hora real

media.source.realtime_aligner

Para un live stream, no basta con conocer el orden de los fotogramas y la velocidad de reproducción. El streamer necesita saber a qué fecha y hora corresponde cada fotograma: así puede grabarlo en DVR y encontrar después el momento necesario por fecha y hora.

Las fuentes ofrecen distintas bases para esta decisión. Algunas solo tienen una escala relativa; otras disponen de relojes propios que no siempre son fiables. La red puede entregar en ráfagas un flujo uniforme en tiempo multimedia. Sapsan vincula estas escalas con la hora real, conservando los intervalos entre fotogramas, y revisa la vinculación cuando cambia el comportamiento de la fuente.

Tiempo multimedia, reloj de la fuente y hora de llegada

Un fotograma tiene marcas de tiempo: DTS indica el momento de decodificación y PTS el de presentación. Determinan su posición en la escala multimedia, pero no siempre contienen una fecha y hora del día.

Fuente de tiempo Qué sabe el streamer Tarea
DTS/PTS relativos, por ejemplo en MPEG-TS Orden de los fotogramas e intervalos entre ellos Situar esta escala en el calendario del streamer.
Marcas de calendario, por ejemplo tras vincular RTP mediante un RTCP Sender Report Hora absoluta según el reloj del emisor Determinar si ese reloj es fiable.
Hora real de llegada Cuándo estuvo disponible el fotograma para el pipeline del servidor Tener en cuenta los retrasos de red y la entrega en ráfagas sin distorsionar la escala multimedia.

Esta información puede aparecer en distintos momentos dentro de un mismo stream. Por ejemplo, una entrada RTSP recibe primero fotogramas con marcas RTP relativas y después obtiene de RTCP la correspondencia con la hora absoluta. Reconectar la cámara o cambiar de fuente puede volver a modificar la base de la escala.

MPEG-TS sin fecha y hora

Las marcas de tiempo MPEG-TS permiten reproducir vídeo y audio al ritmo correcto, pero no indican que un fotograma corresponde, por ejemplo, a las 14:00:00 de hoy. El contador puede comenzar en un valor arbitrario y dar la vuelta al alcanzar el límite de su rango.

Sapsan elige un desfase entre la escala multimedia y el reloj del streamer. Después lo aplica a DTS y PTS, conservando las distancias entre marcas:

calendar_time = source_time + offset

Por ejemplo, un fotograma con DTS relativo de 42,000 s se vincula a las 14:00:00. El siguiente fotograma, con DTS de 42,040 s, recibe la hora 14:00:00,040. Su tiempo no se sustituye por el momento de la siguiente lectura del socket.

Así, el archivo obtiene una escala de calendario basada en la llegada del stream a Sapsan. Para una fuente sin marcas absolutas, es una vinculación del servidor: no permite recuperar la hora original de captura ni el retraso hasta el streamer, que se desconocen. Con el búfer de entrada activado, la vinculación se realiza después de que este entregue los fotogramas, por lo que su retraso también influye en la posición de la escala.

RTSP y WebRTC: la hora absoluta necesita validación

Las entradas basadas en RTP, incluidas RTSP y WebRTC, pueden obtener la hora absoluta mediante RTCP Sender Report. Pero una marca de calendario no garantiza un reloj correcto: la cámara puede haber perdido su configuración horaria, funcionar sin sincronización o indicar una hora muy alejada en el pasado o el futuro.

En el trayecto normal de alineación, Sapsan distingue las marcas de calendario de las relativas. Se considera de calendario una escala de tiempo Unix no anterior al año 2000. Si una marca de este tipo difiere del reloj del streamer en no más de 60 segundos, se conserva: el intervalo de entrega no se convierte en un motivo para reasignar la hora de la fuente.

Si la diferencia supera la ventana de confianza, la marca se trata como una escala que requiere vinculación al servidor. La comprobación es simétrica para el pasado y el futuro. Esto evita grabar la emisión actual con un calendario de cámara claramente incorrecto.

La ventana de confianza no garantiza una sincronización precisa: los errores de reloj dentro de ella pueden mantenerse. Sigue siendo necesario sincronizar la hora de la fuente y del servidor para que la grabación del archivo corresponda con precisión al evento real.

La decisión también se aplica a pistas individuales. Una pista con una hora de calendario fiable no recibe de nuevo el desfase elegido para una escala relativa: de lo contrario, el servidor podría sumar la época Unix a una marca que ya es absoluta.

Entrega en ráfagas: HLS → HTTP MPEG-TS

Un servidor intermedio puede recibir varios segundos de HLS, analizar el segmento y enviar su contenido por HTTP MPEG-TS casi en una sola ráfaga. Después hay una pausa hasta el siguiente segmento. El tiempo multimedia avanza de forma uniforme dentro de cada ráfaga, mientras que la hora de llegada de los fotogramas varía bruscamente.

Si se asignara a cada fotograma la hora de su llegada, varios segundos de vídeo se comprimirían en una breve ráfaga de red y la pausa entre segmentos se convertiría en un hueco en la escala. Cambiar continuamente el desfase con cada fluctuación produciría discontinuidades y nuevas vinculaciones repetidas.

Sapsan procesa esta entrada por etapas:

  1. El búfer de entrada acumula fotogramas y los entrega al ritmo de DTS. La temporización del flujo determina los intervalos de entrega, mientras la cola absorbe las ráfagas de red.
  2. El alineador vincula la escala multimedia resultante con la fecha y hora. Mantiene el desfase elegido mientras la diferencia siga siendo aceptable.
  3. Los componentes posteriores reciben marcas vinculadas para transcodificar, empaquetar y grabar.

En una entrada tshttp, la profundidad predeterminada del búfer es de 30 000 ms. La configuración se envía mediante la API de central:

streams:
  - name: tv1
    inputs:
      - tshttp:
          url: http://origin.example/live/tv1.ts
        source_options:
          buffer_ms: 30000

buffer_ms se establece en source_options de la entrada concreta. Es una profundidad objetivo en tiempo multimedia, no un número de bytes. Un 0 explícito desactiva el búfer; un valor positivo también lo activa para otros tipos de entrada. En los demás tipos está desactivado de forma predeterminada. Aumentar la profundidad permite cubrir pausas más largas a costa de latencia y memoria.

El búfer no puede compensar una parada indefinida de la fuente. Cuando se agotan los fotogramas acumulados, la entrega se detiene. Si se acumula demasiado material, puede descartarse contenido antiguo para reducir el retraso respecto al directo; estos eventos están disponibles en las estadísticas.

Cuándo cambia la vinculación

Para una escala que requiere un desfase del servidor, el alineador comprueba la diferencia entre el reloj actual y el DTS ya desplazado. Si el valor absoluto de la diferencia se hace mayor de 5 segundos, se elige un nuevo desfase. Esto permite reaccionar a reinicios de marcas, diferencias de ritmo acumuladas y cambios de escala tras una reconexión.

La decisión se basa en una pista principal de audio o vídeo. El vídeo tiene prioridad sobre el audio. Las demás pistas con tiempo relativo reciben el desfase común: sus diferencias no deben hacer que reconstruyan por turnos la escala de todo el stream. Si la pista principal no llega durante más de 5 segundos, otra pista de audio o vídeo que siga llegando puede asumir ese papel.

El desfase se aplica tanto a DTS como a PTS. El alineador conserva su posición relativa; no corrige una desincronización de audio y vídeo ya existente en la fuente.

Una nueva vinculación envía al pipeline multimedia un evento de cambio de escala. El empaquetado posterior puede cerrar los fragmentos actuales e iniciar otros. La nueva vinculación puede desplazar el tiempo hacia delante o hacia atrás: el mecanismo restablece la correspondencia con la hora real, sin prometer ocultar cualquier salto de la fuente sin discontinuidad.

Las fuentes con una escala de calendario ya preparada utilizan un modo independiente de conservación del tiempo. Las entradas directas HLS y DASH pasan sin esta corrección; su retraso normal de varios segmentos no provoca nuevas vinculaciones constantes. Por eso, la captura directa de HLS y la captura de HTTP MPEG-TS generado a partir de HLS por un servidor intermedio requieren comportamientos distintos. La conservación del tiempo también se aplica a los trayectos internos que transportan fotogramas ya vinculados, para no volver a modificar la escala en cada etapa.

La alineación está integrada en el pipeline en directo. Los umbrales de 5 y 60 segundos describen la implementación actual; la configuración del stream no ofrece parámetros YAML independientes para ellos.

Qué supervisar

Solicite estadísticas al streamer que captura la fuente:

curl -fsS -u "$ADMIN_USER:$ADMIN_PASSWORD" \
  http://streamer:8080/streamer/api-v4/streams/stats/tv1 \
  | jq '{name, dts_source, source_timing_offset_ms,
         source_timing_offset_min_ms, source_timing_offset_max_ms,
         source_timing_jitter_ms, source_timing_input,
         source_timing_window_started_at, input}'

El campo dts_source indica la base de la escala:

  • realtime — el tiempo se mantiene mediante un desfase respecto al reloj del streamer.
  • input — se conservan las marcas de la fuente: han superado la validación de hora de calendario o la entrada utiliza un modo de conservación de la escala.

El campo puede no aparecer antes de recibir fotogramas y después de un silencio prolongado. En la exportación de métricas, stream_dts_source utiliza 1 para realtime y 2 para input.

source_timing_offset_ms muestra el desfase actual medido por el monitor temporal. Los límites source_timing_offset_min_ms / source_timing_offset_max_ms y source_timing_jitter_ms 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. Para una escala relativa, el monitor elige su propia referencia, por lo que estos valores no miden el retraso desconocido entre la cámara y el streamer.

El monitor está antes del alineador, pero después del búfer de entrada. Con el búfer activado, sus medidas ya reflejan una entrega suavizada. Para evaluar la irregularidad original, compárelas con el estado del búfer y sus vaciados, no solo con una gráfica de jitter.

La sección input proporciona indicadores del búfer:

Campo Significado
buffer_target_ms Profundidad objetivo en milisegundos de tiempo multimedia.
buffer_depth_ms Profundidad actual.
buffer_underruns Número acumulado de episodios de agotamiento del búfer.
buffer_skips Número acumulado de reducciones de la cola por desbordamiento.
buffer_skipped_ms Tiempo multimedia total descartado, en milisegundos.

Los campos con valor cero pueden omitirse en la respuesta. Compare el incremento de los contadores durante un intervalo; la ausencia de toda la sección de estadísticas no significa que se haya realizado la comprobación sin errores.

Conviene comprobar tres escenarios durante la operación:

  • Flujo relativo uniforme — la escala del archivo sigue el reloj del streamer y se conservan los intervalos entre fotogramas.
  • Fuente con un reloj incorrecto — un calendario claramente no fiable se sustituye por una vinculación al servidor; al recuperarse el reloj, la fuente puede volver a proporcionar su propia hora.
  • Flujo que llega en ráfagas — el búfer suaviza la entrega; las pausas largas y los desbordamientos se ven en las estadísticas y no se ocultan reasignando constantemente el tiempo de cada fotograma.