--- title: Análisis de flujos url: https://doc.pstreamer.tv/es/manual/stream_analyze.html lang: es product: Perfect Streamer version: 1.13.3.445 --- # Análisis de flujos El analizador de flujos del streamer mide y analiza distintos parámetros del flujo MPEG-TS, lo que permite evaluar su calidad. **Input speed** — tasa (bitrate) del flujo en `kbps`. Se mide tras filtrar por las marcas PCR. Se muestra como un gráfico que también incluye el bitrate de salida tras el sincronizador. **Raw data speed** — la velocidad de recepción de datos por el protocolo elegido. **Overhead** — el porcentaje añadido por la sobrecarga del protocolo. **CC errors** — pérdidas de paquetes (CC, discontinuity). Se muestran contadores por intervalo y un contador acumulado durante el stream uptime. También se presenta un gráfico del historial. **Scrambled** — contadores de paquetes MPEG-TS ES codificados. Si es ≠ 0 hay fallos de descodificación de canales cifrados. **Sync by** — fuente de sincronización — PCR. **PCR interval** — intervalo entre marcas PCR. Recomendado: no superior a 50 ms. **PCR jitter** — caracteriza la precisión de sincronización del flujo de salida; se mide como la diferencia entre el PCR y el tiempo real. **Analyze PCR PMT Gap** — se activa mediante un ajuste específico. Se analiza la dispersión entre PCR y PTS/DTS para cada ES. El historial se muestra como un gráfico. Una dispersión excesiva puede causar problemas en reproductores con un búfer de sincronización pequeño. El análisis se activa mediante el ajuste **Analyze PAT/PMT/KF**. **PAT interval** y **PMT interval** — se mide el intervalo entre tablas PAT (PMT). Recomendado: no superior a 500 ms. El análisis se activa con el ajuste **Analyze PAT/PMT/KF**. **Key Frame interval** (intervalo GOP) — el intervalo entre fotogramas clave (inicios de GOP). Para reproductores que se conectan al flujo en puntos aleatorios se recomienda no más de 1 s. El análisis se activa mediante el ajuste **Analyze PAT/PMT/KF**. **IDR interval** — el intervalo entre fotogramas IDR, que son verdaderos puntos de acceso aleatorio (*SPS / PPS / IDR*). Se muestra solo si la fuente emite con IDR. Si **IDR interval** coincide aproximadamente con **Key Frame interval**, el flujo tiene *closed-GOP*: cada GOP se abre con un punto de entrada completo y el reproductor puede arrancar desde cualquier segmento. Si la métrica está ausente, el flujo es *open-GOP* sin IDR — hay fotogramas clave, pero no son puntos de entrada completos. Esta relación hace visible de inmediato el tipo de estructura GOP de la fuente. El análisis se habilita con el ajuste **Analyze PAT/PMT/KF**. **PAT/KF interval** — mide el intervalo medio entre el inicio y el fin de la secuencia PAT/PMT/SPS/PPS/KF. De él depende el tiempo de arranque de la reproducción en reproductores que se conectan al flujo en puntos aleatorios. La medición se toma al inicio del KF en el flujo, por lo que el tiempo de arranque real del reproductor será mayor. El análisis se activa mediante el ajuste **Analyze PAT/PMT/KF**. Activar **Analyze PAT/PMT/KF** pone el analizador del flujo en modo permanente, lo que aumenta la carga de CPU. # Control del jitter Para gestionar el jitter existen varios ajustes en el stream: - **Jitter Compensation Delay (ms)** — función de compensación del jitter de red; fija el tamaño del buffer. Descripción ampliada: [https://forum.pstreamer.tv/viewtopic.php?t=25](https://forum.pstreamer.tv/viewtopic.php?t=25) - **Jitter Auto sync** — activa 2000 ms para protocolos basados en TCP (HTTP, HLS); para los UDP el valor sigue siendo 500 ms. - **Limit PCR gap (ms)** — comprueba cuánto puede saltar el PCR; si lo supera, se realiza una resincronización. Si tras el transcoder aparecen errores *PCR Accuracy*, debe establecer un bitrate uniforme mediante *stuffing* para el flujo codificado por la ruta: «**input** — **transcoder** — **Align Total Bitrate**». La velocidad debe fijarse garantizadamente por encima del bitrate de vídeo y audio. # PCR drift La métrica *PCR drift* mide la desviación sistemática de la frecuencia de reloj de la fuente con respecto al tiempo real y se expresa en *ppm* (parts-per-million). A diferencia del *PCR jitter* instantáneo, que capta la oscilación de marcas individuales, *PCR drift* caracteriza precisamente la deriva del cristal del codificador a largo plazo — una desviación estable que se acumula a lo largo de minutos y horas. La medición se realiza mediante regresión lineal sobre pares (tiempo *PCR* acumulado en segundos, tiempo de recepción en segundos). El ruido de medición decrece como `1/T^1.5` con el crecimiento de la ventana, por lo que un veredicto fiable solo es posible en intervalos largos. La ventana se expande automáticamente hasta 300 *segundos* (ventana de aceptación del producto; la norma **TR 101 290** no fija el intervalo de observación), tras lo cual se aplica un re-anclaje deslizante con un límite de 6 *horas* — esto elimina la pérdida de precisión por desbordamiento de la mantisa `float64`. Las estadísticas **XML** del stream exportan: - `pcr-drift-ppm` — veredicto actual de la regresión; - `pcr-drift-window-s` — longitud de la ventana sobre la que se calculó el veredicto; - `pcr-drift-samples` — número de puntos en la regresión. La tolerancia establecida por **ISO/IEC 13818-1** §2.4.2.1 es de ±30 *ppm*. Ante una superación sostenida (véase la sección de alertas más abajo) se establece un atributo independiente `pcr-drift-alert`, y tras 300 *segundos* de violación continua — `pcr-drift-alert-acceptance` (nivel de aceptación; la ventana de 300 segundos es un valor de producto, en el espíritu de las mediciones a largo plazo de **TR 101 290**). Aislar *PCR drift* en un atributo independiente (y no en el `tr101290-alert` común) es intencional: la deriva del cristal es un problema del codificador aguas arriba, no del receptor, y el operador debe verla por separado, sin mezclarla con los errores de integridad del transporte. # PCR accuracy La métrica *PCR accuracy* (sección P2.3 de **TR 101 290**) mide la precisión de la inserción de marcas *PCR* en el flujo de transporte. Según la especificación, el valor de cada *PCR* debe coincidir con el momento efectivo de su paso por el multiplexor con un error no peor que ±500 *ns*. La medición se realiza como señal residual (*residual*) de una regresión lineal en una ventana deslizante de 30 *s*. El tamaño de la ventana se elige para capturar todo el ciclo de repetición de *PCR* (≤40 *ms* según especificación) con amplio margen, manteniendo a la vez una respuesta rápida ante un deterioro de la calidad de inserción. Las estadísticas **XML** del stream exportan `pcr-accuracy-max-ns` — el valor pico del residual en la ventana. Al superar ±500 *ns* se añade el token `pcr-acc` al atributo común `tr101290-alert`. La medición solo tiene sentido para multiplex **CBR**: en **VBR**, los intervalos entre *PCR* pueden divergir de la tendencia lineal estimada sin violar el estándar. El analizador desactiva automáticamente el token `pcr-acc` para flujos clasificados como *vbr* (véase la sección sobre el detector de modo). # Compensador de deriva de PCR Si el *PCR drift* de la fuente se encuentra dentro de la tolerancia de **ISO/IEC 13818-1** pero aún es distinto de cero, el flujo de salida «se aleja» lentamente respecto al tiempo de red del receptor. En un reproductor con búfer pequeño esto se manifiesta como una pérdida acumulativa de sincronización o como saltos periódicos en la reproducción. El compensador elimina la deriva sin resincronización dura: los paquetes salientes reciben un microdesplazamiento de ~11.1 *µs* (duración de un paquete *TS* de 188 bytes a 100 *Mbps*), y la decisión de «si es necesario el desplazamiento» se toma a partir de la diferencia efectiva entre el tiempo de red y el ritmo del *PCR*. El resync duro (`Limit PCR gap`) permanece como respaldo para las rupturas de flujo — el compensador opera a una escala más fina y preserva la continuidad. Ajustes en **stream**: - *Sync Drift Compensation* — activa/desactiva el compensador. Activado por defecto. - *Sync Drift Soft Window* — ventana suave dentro de la cual las correcciones se aplican una a una (1–60000 *ms*, por defecto 500). El límite superior está acotado por `8 × Sync Disc Window`, a partir del cual se considera que toca un resync duro. Las estadísticas **XML** exportan `slew-adjust-count` — el contador de correcciones desde `reset-stat`. Un crecimiento brusco de este contador significa que la fuente o bien ha salido de su tolerancia o bien tiene un cristal inestable. # Analizador de búfer de vídeo T-STD El modelo **T-STD** (*Target Decoder*) está descrito en **ISO/IEC 13818-1** §2.4.2. Es el modelo de referencia del búfer del receptor: si se respeta, se garantiza que el flujo se reproduzca en cualquier decodificador hardware conforme. El analizador modela el búfer `MBn` (multiplex buffer para vídeo) y verifica que: - el búfer no desborda (overflow → el codificador está obligado a descartar fotogramas); - el búfer no se vacía (underflow → el decodificador muestra una pausa o artefactos). Se activa con el ajuste *Analyze T-STD video* (desactivado por defecto — añade carga de CPU en la ruta de procesamiento caliente). Tipos de ES de vídeo admitidos (`stream_type`): - `0x01` / `0x02` — MPEG-2 video, capacidad 750 *KB*; - `0x10` — MPEG-4 part 2, capacidad 750 *KB*; - `0x1B` — H.264 / AVC, capacidad 3 *MB*; - `0x24` / `0x25` — HEVC, capacidad 3.75 *MB*. La velocidad de vaciado (*drain rate*) se ajusta de forma adaptativa a la tasa de bits real del vídeo: se utiliza una media móvil exponencialmente ponderada (EMA) con `α=0.2` sobre una ventana de 5 *s*. Sin adaptación, el modelo produce rápidamente falsos underflows en cualquier vídeo *VBR*. El búfer se vacía siguiendo los pulsos del **PCR** (90 *kHz*), no por el tiempo del sistema host — esto hace que el análisis sea robusto frente a pausas del SO y fluctuaciones de carga de CPU. El reloj real del host se usa únicamente para verificar el funcionamiento del compensador de deriva, nunca para T-STD. Las estadísticas **XML** exportan: - `tstd-video-cap` — capacidad del modelo en bytes; - `tstd-video-drain-bps` — velocidad de vaciado adaptada actual, *bytes/s*; - `tstd-video-overflows` — contador de overflows desde `reset-stat`; - `tstd-video-underflows` — contador de underflows; - `tstd-video-max-fill` — ocupación pico en bytes. Ante cualquier contador no nulo (`overflows > 0` o `underflows > 0`) se añade el token `tstd-video` al `tr101290-alert` común. Al igual que `pcr-acc`, el token se aplica solo a flujos **CBR** — en un multiplex **VBR** los descensos transitorios del búfer son admisibles. # Detector de modo de tasa de bits del multiplexor Una parte de las pruebas de **TR 101 290** solo tiene sentido en modo **CBR** (tasa de bits del multiplex constante). Para no emitir falsas alertas en canales **VBR**, el analizador determina automáticamente el modo de la fuente y exporta el veredicto al atributo `bitrate-mode-detected`. Algoritmo: comparación de las tasas de bits medias en dos ventanas — 5 *s* y 60 *s*. Si la divergencia supera el 20 %, el flujo se marca como `vbr`; si se mantiene dentro, `cbr`. Hasta que se acumule la estadística (~70 *s* desde el inicio o desde `reset-stat`), el veredicto es `unknown` y las pruebas reservadas a **CBR** (`pcr-acc`, `tstd-video`) quedan temporalmente suprimidas. Valores del atributo: - `cbr` — tasa de bits constante, todas las pruebas activas; - `vbr` — tasa de bits variable, `pcr-acc` y `tstd-video` están desactivados; - `unknown` — datos insuficientes, las pruebas exclusivas de **CBR** están suspendidas. # Alertas TR 101 290 El atributo agregado `tr101290-alert` reúne varios detectores de conformidad con **TR 101 290**. Si en el momento actual se dispara al menos uno, el atributo contiene una lista de tokens separados por espacios; si no, el atributo está ausente del **XML**. Tokens posibles y su significado: - `pcr-int` — intervalo entre *PCR* superado (sección 5.2.4 de **TR 101 290**, límite 40 *ms*, recomendación ≤25 *ms*); - `pcr-acc` — precisión de inserción de *PCR* superada (sección 5.2.5, ±500 *ns*, **CBR**-only); - `pcr-disc` — se detectó un resync duro por *PCR* (sección 5.2.4, `PCR_discontinuity_indicator_error`); - `pat-int` — intervalo de *PAT* superado (sección 5.1.3, límite 500 *ms*, requiere *Analyze PAT/PMT/KF*); - `pmt-int` — intervalo de *PMT* superado (sección 5.1.5, límite 500 *ms*, requiere *Analyze PAT/PMT/KF*); - `tstd-video` — se detectó un overflow o underflow del modelo **T-STD** (sección 5.3.16, requiere *Analyze T-STD video*, **CBR**-only). Para evitar el parpadeo del indicador ante ráfagas cortas se aplica una lógica de debounce: un token entra en `tr101290-alert` solo si se ha disparado durante al menos 30 de los últimos 60 segundos. Esto se aplica uniformemente a todos los tokens. Adicionalmente se exporta `tr101290-alert-acceptance` — una copia del atributo en la que un token aparece solo tras 300 *segundos* de violación continua (nivel de aceptación; el intervalo es un valor del producto, el estándar **TR 101 290** no lo normaliza). Es la métrica agregada «final» para la aceptación técnica del canal. El indicador `pcr-drift` se aísla deliberadamente en su propio `pcr-drift-alert` (+ `pcr-drift-alert-acceptance`). La deriva del cristal es un problema del codificador aguas arriba, es independiente de la integridad del transporte y debe clasificarse por separado. # Asistente de IA para reclamaciones Si en un canal se disparan alertas *TR 101 290* o *PCR drift*, el operador puede obtener en una sola petición un prompt en inglés listo para un chat de IA que redacte una carta formal de reclamación al proveedor aguas arriba del flujo. Endpoint: `GET /data/stream//ai-complaint-prompt`. Disponible con el rol *Viewer* (como todas las peticiones GET bajo `/data/*`). Devuelve `text/plain; charset=utf-8`. Para **MPTS** se devuelve 404 — las métricas *T-STD* / *PCR drift* solo son aplicables a **SPTS**. El prompt es compatible con cualquier chat de IA moderno: «ChatGPT», «Claude», «DeepSeek», «Qwen», «Doubao». El tono de la carta es profesional, sin acusaciones; al final del prompt se añade la elección de idioma del documento resultante: inglés, ruso, chino simplificado o cualquier otro a elección del operador. Contenido del prompt: - nombre y parámetros medidos del stream; - la lista de todos los tokens activos de *TR 101 290* y *PCR drift* con la decodificación de la norma; - valores numéricos y umbrales; - el impacto de cada error en el lado del decodificador. Lo que **no** se incluye en el prompt: el nombre del stream, el ID, el URI de la fuente. Estos campos se sustituyen por el marcador `` — el operador los rellena antes de enviar, para que no se filtren a un servicio de IA de terceros.