--- title: Análise de fluxos url: https://doc.pstreamer.tv/pt/manual/stream_analyze.html lang: pt-BR product: Perfect Streamer version: 1.13.3.445 --- # Análise de fluxos O analisador de fluxos do streamer mede e analisa diversos parâmetros do fluxo MPEG-TS, permitindo avaliar a qualidade. **Input speed** — taxa (bitrate) do fluxo em `kbps`. Medida após o filtro por marcas de PCR. Exibida como gráfico que também mostra o bitrate de saída após o sincronizador. **Raw data speed** — a taxa de receção de dados pelo protocolo escolhido. **Overhead** — a percentagem acrescentada correspondente à sobrecarga do protocolo. **CC errors** — perdas de pacotes (CC, discontinuity). São apresentados contadores por intervalo e um contador acumulado durante o stream uptime. É também apresentado um gráfico de histórico. **Scrambled** — contadores de pacotes MPEG-TS ES criptografados. Se for ≠ 0, há falhas na decodificação de canais criptografados. **Sync by** — fonte de sincronização — PCR. **PCR interval** — intervalo entre as marcas de PCR. Recomendado: até 50 ms. **PCR jitter** — caracteriza a precisão de sincronização do fluxo de saída; medido como a diferença entre o PCR e o tempo real. **Analyze PCR PMT Gap** — é ativado através de uma definição específica. É analisada a dispersão entre PCR e PTS/DTS para cada ES. O histórico é apresentado em forma de gráfico. Uma dispersão excessiva pode causar problemas em leitores com buffer de sincronização reduzido. A análise é ativada pela definição **Analyze PAT/PMT/KF**. **PAT interval** e **PMT interval** — mede-se o intervalo entre tabelas PAT (PMT). Recomendado: até 500 ms. A análise é ativada pela configuração **Analyze PAT/PMT/KF**. **Key Frame interval** (intervalo GOP) — o intervalo entre fotogramas-chave (inícios de GOP). Para leitores que se ligam ao fluxo em pontos aleatórios, recomenda-se um valor máximo de 1 s. A análise é ativada pela definição **Analyze PAT/PMT/KF**. **IDR interval** — o intervalo entre quadros IDR, que são verdadeiros pontos de acesso aleatório (*SPS / PPS / IDR*). É exibido apenas se a fonte transmitir com IDR. Se **IDR interval** coincidir aproximadamente com **Key Frame interval**, o fluxo tem *closed-GOP*: cada GOP abre com um ponto de entrada completo e o reprodutor pode iniciar a partir de qualquer segmento. Se a métrica estiver ausente, o fluxo é *open-GOP* sem IDR — há quadros-chave, mas eles não são pontos de entrada completos. Essa relação torna imediatamente visível o tipo de estrutura GOP da fonte. A análise é ativada pela configuração **Analyze PAT/PMT/KF**. **PAT/KF interval** — mede o intervalo médio entre o início e o fim da sequência PAT/PMT/SPS/PPS/KF. Dele depende o tempo de arranque da reprodução para leitores que se ligam ao fluxo em pontos aleatórios. A medição é feita no início do KF no fluxo, pelo que o tempo de arranque real do leitor será maior. A análise é ativada pela definição **Analyze PAT/PMT/KF**. Ativar **Analyze PAT/PMT/KF** coloca o analisador do fluxo em modo permanente, aumentando a carga de CPU. # Controle do jitter Para gerenciar o jitter existem várias configurações no stream: - **Jitter Compensation Delay (ms)** — função de compensação do jitter de rede; define o tamanho do buffer. Descrição detalhada: [https://forum.pstreamer.tv/viewtopic.php?t=25](https://forum.pstreamer.tv/viewtopic.php?t=25) - **Jitter Auto sync** — ativa 2000 ms para protocolos baseados em TCP (HTTP, HLS); para os protocolos UDP o valor permanece em 500 ms. - **Limit PCR gap (ms)** — verifica o quanto o PCR pode saltar; se ultrapassar, ocorre resincronização. Se após o transcodificador surgirem erros *PCR Accuracy*, é necessário definir um bitrate uniforme por meio do *stuffing* para o fluxo codificado pelo caminho: «**input** — **transcoder** — **Align Total Bitrate**». A velocidade deve ser definida garantidamente acima do bitrate de vídeo e áudio. # PCR drift A métrica *PCR drift* mede o desvio sistemático da frequência de relógio da fonte em relação ao tempo real e é expressa em *ppm* (parts-per-million). Ao contrário do *PCR jitter* instantâneo, que captura a oscilação de marcas individuais, *PCR drift* caracteriza precisamente a deriva do cristal do codificador a longo prazo — um desvio estável que se acumula ao longo de minutos e horas. A medição é realizada por regressão linear sobre pares (tempo *PCR* acumulado em segundos, tempo de recepção em segundos). O ruído de medição decai como `1/T^1.5` com o crescimento da janela, de modo que um veredito confiável só é possível em intervalos longos. A janela se expande automaticamente até 300 *segundos* (janela de aceitação do produto; a norma **TR 101 290** não fixa o intervalo de observação), após o que é aplicado um reancoramento deslizante com um limite de 6 *horas* — isso elimina a perda de precisão por estouro da mantissa `float64`. As estatísticas **XML** do stream exportam: - `pcr-drift-ppm` — veredito atual da regressão; - `pcr-drift-window-s` — comprimento da janela sobre a qual o veredito foi calculado; - `pcr-drift-samples` — número de pontos na regressão. A tolerância definida por **ISO/IEC 13818-1** §2.4.2.1 é de ±30 *ppm*. Em caso de excesso sustentado (consulte a seção de alertas abaixo), um atributo dedicado `pcr-drift-alert` é definido, e após 300 *segundos* de violação contínua — `pcr-drift-alert-acceptance` (nível de aceitação; a janela de 300 segundos é um valor de produto, no espírito das medições de longo prazo da **TR 101 290**). Expor *PCR drift* como atributo autônomo (em vez de incluí-lo no `tr101290-alert` comum) é intencional: a deriva do cristal é um problema do codificador a montante, não do receptor, e o operador deve vê-la separadamente, sem misturá-la com erros de integridade do transporte. # PCR accuracy A métrica *PCR accuracy* (seção P2.3 em **TR 101 290**) mede a precisão da inserção das marcas *PCR* no fluxo de transporte. Conforme a especificação, o valor de cada *PCR* deve coincidir com o momento efetivo de sua passagem pelo multiplexador com um erro não pior que ±500 *ns*. A medição é feita como sinal residual (*residual*) de uma regressão linear em uma janela deslizante de 30 *s*. O tamanho da janela é escolhido para capturar todo o ciclo de repetição do *PCR* (≤40 *ms* segundo a especificação) com ampla margem, mas mantendo uma resposta rápida à deterioração da qualidade de inserção. As estatísticas **XML** do stream exportam `pcr-accuracy-max-ns` — o valor de pico do residual na janela. Ao exceder ±500 *ns*, o token `pcr-acc` é adicionado ao atributo comum `tr101290-alert`. A medição só faz sentido para multiplex **CBR**: em **VBR**, os intervalos entre *PCR* podem divergir da tendência linear estimada sem violar o padrão. O analisador desativa automaticamente o token `pcr-acc` para fluxos classificados como *vbr* (consulte a seção sobre o detector de modo). # Compensador de desvio de PCR Se o *PCR drift* da fonte estiver dentro da tolerância da **ISO/IEC 13818-1** mas ainda for diferente de zero, o fluxo de saída «se afasta» lentamente em relação ao tempo de rede do receptor. Em um player com buffer pequeno, isso se manifesta como perda acumulada de sincronização ou solavancos periódicos na reprodução. O compensador elimina o desvio sem ressincronização rígida: os pacotes de saída recebem um microdeslocamento de ~11.1 *µs* (duração de um pacote *TS* de 188 bytes a 100 *Mbps*), e a decisão «se o deslocamento é necessário» é tomada com base na diferença efetiva entre o tempo de rede e o ritmo do *PCR*. O resync rígido (`Limit PCR gap`) permanece como recurso de contingência para rupturas de fluxo — o compensador opera em uma escala mais fina e preserva a continuidade. Configurações em **stream**: - *Sync Drift Compensation* — ativa/desativa o compensador. Ativado por padrão. - *Sync Drift Soft Window* — janela suave dentro da qual as correções são aplicadas uma a uma (1–60000 *ms*, padrão 500). O limite superior é restrito por `8 × Sync Disc Window`, a partir do qual considera-se necessário um resync rígido. As estatísticas **XML** exportam `slew-adjust-count` — o contador de correções desde `reset-stat`. Um crescimento abrupto desse contador significa que a fonte saiu de sua tolerância ou possui um cristal instável. # Analisador de buffer de vídeo T-STD O modelo **T-STD** (*Target Decoder*) está descrito em **ISO/IEC 13818-1** §2.4.2. É o modelo de referência do buffer do receptor: se ele for respeitado, garante-se que o fluxo será reproduzido por qualquer decodificador de hardware conforme. O analisador modela o buffer `MBn` (multiplex buffer para vídeo) e verifica que: - o buffer não estoura (overflow → o codificador é obrigado a descartar quadros); - o buffer não esvazia (underflow → o decodificador mostra uma pausa ou artefatos). Ativado pela configuração *Analyze T-STD video* (desativado por padrão — adiciona carga de CPU no caminho de processamento crítico). Tipos de ES de vídeo suportados (`stream_type`): - `0x01` / `0x02` — MPEG-2 video, capacidade 750 *KB*; - `0x10` — MPEG-4 part 2, capacidade 750 *KB*; - `0x1B` — H.264 / AVC, capacidade 3 *MB*; - `0x24` / `0x25` — HEVC, capacidade 3.75 *MB*. A taxa de drenagem (*drain rate*) é ajustada adaptativamente à taxa de bits real do vídeo: utiliza-se uma média móvel exponencialmente ponderada (EMA) com `α=0.2` em uma janela de 5 *s*. Sem adaptação, o modelo produz rapidamente falsos underflows em qualquer vídeo *VBR*. O buffer é drenado pelos pulsos de **PCR** (90 *kHz*) e não pelo tempo do sistema do host — isso torna a análise robusta frente a pausas do SO e flutuações de carga de CPU. O tempo real do host é utilizado apenas para verificar o funcionamento do compensador de desvio, nunca para T-STD. As estatísticas **XML** exportam: - `tstd-video-cap` — capacidade do modelo em bytes; - `tstd-video-drain-bps` — taxa de drenagem adaptada atual, *bytes/s*; - `tstd-video-overflows` — contador de overflows desde `reset-stat`; - `tstd-video-underflows` — contador de underflows; - `tstd-video-max-fill` — ocupação de pico em bytes. Diante de qualquer contador diferente de zero (`overflows > 0` ou `underflows > 0`), o token `tstd-video` é adicionado ao `tr101290-alert` comum. Assim como `pcr-acc`, o token aplica-se apenas a fluxos **CBR** — em um multiplex **VBR** quedas transitórias do buffer são admissíveis. # Detector de modo de taxa de bits do multiplex Parte dos testes de **TR 101 290** só faz sentido no modo **CBR** (taxa de bits do multiplex constante). Para não emitir alertas falsos em canais **VBR**, o analisador determina automaticamente o modo da fonte e exporta o veredito no atributo `bitrate-mode-detected`. Algoritmo: comparação das taxas de bits médias em duas janelas — 5 *s* e 60 *s*. Se a divergência exceder 20 %, o fluxo é marcado como `vbr`; se ficar dentro, `cbr`. Até que a estatística se acumule (~70 *s* desde o início ou desde `reset-stat`), o veredito é `unknown` e os testes exclusivos de **CBR** (`pcr-acc`, `tstd-video`) ficam temporariamente suprimidos. Valores do atributo: - `cbr` — taxa de bits constante, todos os testes ativos; - `vbr` — taxa de bits variável, `pcr-acc` e `tstd-video` estão desativados; - `unknown` — dados insuficientes, os testes exclusivos de **CBR** estão suspensos. # Alertas TR 101 290 O atributo agregado `tr101290-alert` combina vários detectores de conformidade com **TR 101 290**. Se ao menos um estiver ativo no momento atual, o atributo contém uma lista de tokens separados por espaços; caso contrário, o atributo está ausente do **XML**. Tokens possíveis e seu significado: - `pcr-int` — intervalo entre *PCR* excedido (seção 5.2.4 de **TR 101 290**, limite 40 *ms*, recomendação ≤25 *ms*); - `pcr-acc` — precisão de inserção de *PCR* excedida (seção 5.2.5, ±500 *ns*, **CBR**-only); - `pcr-disc` — foi detectado um resync rígido por *PCR* (seção 5.2.4, `PCR_discontinuity_indicator_error`); - `pat-int` — intervalo de *PAT* excedido (seção 5.1.3, limite 500 *ms*, requer *Analyze PAT/PMT/KF*); - `pmt-int` — intervalo de *PMT* excedido (seção 5.1.5, limite 500 *ms*, requer *Analyze PAT/PMT/KF*); - `tstd-video` — foi detectado um overflow ou underflow do modelo **T-STD** (seção 5.3.16, requer *Analyze T-STD video*, **CBR**-only). Para evitar a cintilação do indicador em rajadas curtas, é aplicada uma lógica de debounce: um token entra em `tr101290-alert` apenas se tiver sido acionado por pelo menos 30 dos últimos 60 segundos. Isso se aplica uniformemente a todos os tokens. Adicionalmente é exportado `tr101290-alert-acceptance` — uma cópia do atributo na qual um token só aparece após 300 *segundos* de violação contínua (nível de aceitação; o intervalo é um valor do produto, o padrão **TR 101 290** não o normatiza). É a métrica agregada «final» para a aceitação técnica do canal. O indicador `pcr-drift` é deliberadamente separado em seu próprio `pcr-drift-alert` (+ `pcr-drift-alert-acceptance`). A deriva do cristal é um problema do codificador a montante, é independente da integridade do transporte e deve ser classificada separadamente. # Assistente de IA para reclamações Se em um canal forem disparados alertas *TR 101 290* ou *PCR drift*, o operador pode obter em uma única solicitação um prompt em inglês pronto para um chat de IA que redigirá uma carta formal de reclamação ao provedor a montante do fluxo. Endpoint: `GET /data/stream//ai-complaint-prompt`. Disponível com o papel *Viewer* (assim como todas as requisições GET sob `/data/*`). Retorna `text/plain; charset=utf-8`. Para **MPTS** é retornado 404 — as métricas *T-STD* / *PCR drift* só se aplicam a **SPTS**. O prompt é compatível com qualquer chat de IA moderno: «ChatGPT», «Claude», «DeepSeek», «Qwen», «Doubao». O tom da carta é profissional, sem acusações; ao final do prompt é adicionada a escolha do idioma do documento resultante: inglês, russo, chinês simplificado ou qualquer outro à escolha do operador. Conteúdo do prompt: - nome e parâmetros medidos do stream; - a lista de todos os tokens ativos de *TR 101 290* e *PCR drift* com a referência ao padrão; - valores numéricos e limiares; - o impacto de cada erro no lado do decodificador. O que **não** entra no prompt: nome do stream, ID, URI da fonte. Esses campos são substituídos pelo marcador `` — o operador os preenche antes do envio, para que não vazem para um serviço de IA de terceiros.