--- title: Анализ потоков url: https://doc.pstreamer.tv/ru/manual/stream_analyze.html lang: ru product: Perfect Streamer version: 1.13.3.445 --- # Анализ потоков Анализатор потоков стримера производит измерение и анализ различных параметров потока MPEG-TS, что позволяет оценить качество. **Input speed** — скорость (битрейт) потока в `kbps`. Измеряется после фильтрации по меткам PCR. Выводится в виде графика, где также отображается выходной битрейт после синхронизатора. **Raw data speed** — скорость приёма данных по заданному протоколу. **Overhead** — дополнение в % на издержки протокола. **CC errors** — пропуск пакетов (CC, discontinuity). Отображаются счётчики за периоды и накопительный счётчик за stream uptime. Также отображается история в виде графика. **Scrambled** — счётчики закодированных MPEG-TS ES пакетов. Если не 0, то имеются сбои в декодировании закрытых каналов. **Sync by** — Источник синхронизации — PCR. **PCR interval** — интервал между PCR отметками. Рекомендуется не более 50 мс. **PCR jitter** — характеризует точность синхронизации выходного потока. Измеряется как разница между PCR и реальным временем. **Analyze PCR PMT Gap** — включается отдельной настройкой. Анализируется разброс между PCR и PTS/DTS для каждого ES. История отображается в виде графика. Слишком большой разброс может вызвать проблемы у проигрывателей с малым размером буфера синхронизации. Анализ включается настройкой **Analyze PAT/PMT/KF**. **PAT interval** и **PMT interval** — измеряется интервал между PAT (PMT) таблицами. Рекомендуется не более 500 мс. Анализ включается настройкой **Analyze PAT/PMT/KF**. **Key Frame interval** (интервал GOP) — интервал между ключевыми кадрами (началами GOP). Для проигрывателей со случайным подключением к потоку рекомендуется не более 1 сек. Анализ включается настройкой **Analyze PAT/PMT/KF**. **IDR interval** — интервал между IDR-кадрами — настоящими точками случайного доступа (*SPS / PPS / IDR*). Показывается, только если источник вещает с IDR. Если **IDR interval** примерно совпадает с **Key Frame interval**, поток имеет *closed-GOP*: каждый GOP открывается полной точкой входа, и плеер стартует с любого сегмента. Если метрика отсутствует, поток *open-GOP* без IDR — ключевые кадры есть, но они не являются полными точками входа. По этому соотношению сразу виден тип GOP-структуры источника. Анализ включается настройкой **Analyze PAT/PMT/KF**. **PAT/KF interval** — измеряет средний интервал между началом и концом последовательности PAT/PMT/SPS/PPS/KF. От этого зависит скорость старта воспроизведения проигрывателей со случайным подключением к потоку. Измеряется по началу KF в потоке, поэтому реальное время старта проигрывателя будет больше. Анализ включается настройкой **Analyze PAT/PMT/KF**. Включение **Analyze PAT/PMT/KF** включает анализатор потока в постоянном режиме, что приводит к увеличению нагрузки на CPU. # Управление джиттером Для управления джиттером существует несколько настроек в стриме: - **Jitter Compensation Delay (ms)** — функция компенсации сетевого Jitter, устанавливается размер буфера. Расширенное описание функции: [https://forum.pstreamer.tv/viewtopic.php?t=25](https://forum.pstreamer.tv/viewtopic.php?t=25) - **Jitter Auto sync** — активирует значение 2000 мс для протоколов на базе TCP (HTTP, HLS), для UDP-протоколов значение остаётся прежним — 500 мс. - **Limit PCR gap (ms)** — проверка, насколько PCR может скачкообразно измениться; если больше, то будет пересинхронизация. При появлении ошибок *PCR Accuracy* после транскодера необходимо задать ровный битрейт с помощью *stuffing* у энкодируемого потока по следующему пути: «**input** — **transcoder** — **Align Total Bitrate**». Скорость надо задать гарантировано больше битрейта видео и звука. # PCR drift Метрика *PCR drift* измеряет систематический уход тактовой частоты источника относительно реального времени и выражается в *ppm* (parts-per-million). В отличие от мгновенного *PCR jitter*, который ловит дрожание отдельных отметок, *PCR drift* характеризует именно дрейф кварца энкодера — устойчивое отклонение, накапливающееся за минуты и часы. Измерение выполняется методом линейной регрессии по парам (накопленное время *PCR* в секундах, время приёма в секундах). Шум измерения убывает как `1/T^1.5` с ростом окна, поэтому достоверный вердикт возможен только на длинных интервалах. Окно автоматически расширяется до 300 *секунд* (приёмочное окно продукта; стандарт **TR 101 290** интервал наблюдения не фиксирует), после чего применяется скользящая перепривязка с лимитом 6 *часов* — этим исключается потеря точности из-за переполнения мантиссы `float64`. В **XML**-статистике стрима экспортируются: - `pcr-drift-ppm` — текущий вердикт регрессии; - `pcr-drift-window-s` — длина окна, на котором посчитан вердикт; - `pcr-drift-samples` — число точек в регрессии. Допуск, заданный **ISO/IEC 13818-1** §2.4.2.1, — ±30 *ppm*. При устойчивом превышении (см. раздел про алерты ниже) выставляется отдельный атрибут `pcr-drift-alert`, а после 300 *секунд* непрерывного нарушения — `pcr-drift-alert-acceptance` (приёмочный уровень; окно 300 секунд — значение продукта, в духе долгосрочных измерений **TR 101 290**). Вынесение *PCR drift* в самостоятельный атрибут (а не в общий `tr101290-alert`) сделано намеренно: дрейф кварца — это проблема upstream-энкодера, не приёмника, и оператор должен видеть её отдельно, не примешанной к ошибкам потоковой целостности. # PCR accuracy Метрика *PCR accuracy* (раздел P2.3 в **TR 101 290**) измеряет точность вставки отметок *PCR* в транспортный поток. По спецификации значение каждой *PCR* должно совпадать с фактическим моментом её прохождения через мультиплексор с погрешностью не хуже ±500 *нс*. Измерение делается как остаточный сигнал (*residual*) линейной регрессии на скользящем окне 30 *секунд*. Размер окна выбран так, чтобы захватить весь цикл повторения *PCR* (≤40 *мс* по спецификации) с большим запасом, но при этом быстро реагировать на ухудшение качества вставки. В **XML**-статистике стрима экспортируется `pcr-accuracy-max-ns` — пиковое значение residual за окно. При превышении ±500 *нс* в общий атрибут `tr101290-alert` добавляется токен `pcr-acc`. Измерение имеет смысл только для **CBR**-мультиплексов: в **VBR** интервалы между *PCR* могут расходиться с расчётным линейным трендом без нарушения стандарта. Анализатор автоматически отключает токен `pcr-acc` для потоков, классифицированных как *vbr* (см. раздел про детектор режима). # Компенсатор PCR drift Если *PCR drift* источника лежит в пределах допуска **ISO/IEC 13818-1**, но всё же отличен от нуля, выходной поток медленно «уезжает» относительно сетевого времени получателя. У плеера с маленьким буфером это видно как накапливающаяся рассинхронизация или периодические рывки воспроизведения. Компенсатор устраняет дрейф без жёсткой пересинхронизации: исходящие пакеты приходят с микросдвигом ~11.1 *мкс* (длительность одного 188-байтного *TS*-пакета на скорости 100 *Мбит/с*), а решение «нужен ли сдвиг» принимается по фактической разнице между сетевым временем и темпом *PCR*. Жёсткий resync (`Limit PCR gap`) остаётся как fallback на случай разрывов потока — компенсатор работает на меньшем масштабе и сохраняет непрерывность. Настройки в **stream**: - *Sync Drift Compensation* — включает/выключает компенсатор. По умолчанию включён. - *Sync Drift Soft Window* — мягкое окно, внутри которого корректировка применяется поштучно (1–60000 *мс*, по умолчанию 500). Верхняя граница ограничена `8 × Sync Disc Window`, после чего считается, что пора делать жёсткую пересинхронизацию. В **XML**-статистике экспортируется `slew-adjust-count` — счётчик корректировок с момента `reset-stat`. Резкий рост счётчика означает, что источник либо вышел за пределы допуска, либо имеет нестабильный кварц. # T-STD анализатор видеобуфера Модель **T-STD** (*Target Decoder*) описана в **ISO/IEC 13818-1** §2.4.2. Это эталонная модель буфера приёмника: если её соблюсти, поток гарантированно проигрывается любым корректным аппаратным декодером. Анализатор моделирует буфер `MBn` (multiplex buffer для видео) и проверяет, что: - буфер не переполняется (overflow → encoder обязан отбрасывать кадры); - буфер не опустошается (underflow → decoder показывает паузу или артефакты). Включается настройкой *Analyze T-STD video* (по умолчанию выключено — добавляет CPU-нагрузку в горячем пути обработки). Поддерживаемые типы видео-ES (`stream_type`): - `0x01` / `0x02` — MPEG-2 video, ёмкость 750 *КБ*; - `0x10` — MPEG-4 part 2, ёмкость 750 *КБ*; - `0x1B` — H.264 / AVC, ёмкость 3 *МБ*; - `0x24` / `0x25` — HEVC, ёмкость 3.75 *МБ*. Скорость выкачивания (*drain rate*) адаптивно подстраивается под реальный битрейт видео: используется экспоненциально взвешенное среднее (EMA) с `α=0.2` на окне 5 *секунд*. Без адаптации модель быстро выдаёт ложные underflow на любом *VBR*-видео. Буфер выкачивается по тактам **PCR** (90 *кГц*), а не по системному времени хоста — это делает анализ устойчивым к паузам ОС и колебаниям нагрузки на CPU. Реальное время хоста используется только для верификации работы компенсатора drift, не для T-STD. В **XML**-статистике экспортируются: - `tstd-video-cap` — ёмкость модели в байтах; - `tstd-video-drain-bps` — текущая адаптированная скорость выкачивания, *байт/с*; - `tstd-video-overflows` — счётчик переполнений с момента `reset-stat`; - `tstd-video-underflows` — счётчик опустошений; - `tstd-video-max-fill` — пиковое заполнение в байтах. При любом ненулевом счётчике (`overflows > 0` или `underflows > 0`) в общий `tr101290-alert` добавляется токен `tstd-video`. Как и `pcr-acc`, токен применяется только к **CBR**-потокам — у **VBR**-мультиплекса временные просадки буфера допустимы. # Детектор режима мультиплекса Часть тестов **TR 101 290** имеет смысл только в **CBR**-режиме (постоянный битрейт мультиплекса). Чтобы не выдавать ложные алерты на **VBR**-каналах, анализатор автоматически определяет режим источника и экспортирует вердикт в атрибут `bitrate-mode-detected`. Алгоритм: сравнение средних битрейтов на двух окнах — 5 *секунд* и 60 *секунд*. Если расхождение более 20 %, поток помечается как `vbr`; если в пределах — `cbr`. До накопления статистики (~70 *секунд* от старта или `reset-stat`) вердикт — `unknown`, и **CBR**-only тесты (`pcr-acc`, `tstd-video`) временно подавлены. Значения атрибута: - `cbr` — постоянный битрейт, все тесты активны; - `vbr` — переменный битрейт, `pcr-acc` и `tstd-video` отключены; - `unknown` — недостаточно данных, **CBR**-only тесты приостановлены. # TR 101 290 алерты Сводный атрибут `tr101290-alert` объединяет несколько детекторов соответствия **TR 101 290**. Если в текущий момент срабатывает хоть один — атрибут содержит список токенов через пробел; если нет — атрибут отсутствует в **XML**. Возможные токены и их значение: - `pcr-int` — превышение интервала между *PCR* (раздел 5.2.4 **TR 101 290**, лимит 40 *мс*, рекомендация ≤25 *мс*); - `pcr-acc` — превышение точности вставки *PCR* (раздел 5.2.5, ±500 *нс*, **CBR**-only); - `pcr-disc` — обнаружен жёсткий resync по *PCR* (раздел 5.2.4, `PCR_discontinuity_indicator_error`); - `pat-int` — превышение интервала *PAT* (раздел 5.1.3, лимит 500 *мс*, требует *Analyze PAT/PMT/KF*); - `pmt-int` — превышение интервала *PMT* (раздел 5.1.5, лимит 500 *мс*, требует *Analyze PAT/PMT/KF*); - `tstd-video` — обнаружено переполнение или опустошение модели **T-STD** (раздел 5.3.16, требует *Analyze T-STD video*, **CBR**-only). Чтобы исключить мигание индикатора на коротких всплесках, используется debounce-логика: токен попадает в `tr101290-alert` только если сработал не менее чем в 30 секундах из последних 60. Это применяется ко всем токенам единообразно. Дополнительно экспортируется `tr101290-alert-acceptance` — копия атрибута, в которую токен попадает только после 300 *секунд* непрерывного нарушения (приёмочный уровень; интервал — значение продукта, стандарт **TR 101 290** его не нормирует). Это «итоговая» сводная метрика для технической приёмки канала. Атрибут `pcr-drift` намеренно вынесен в отдельный `pcr-drift-alert` (+ `pcr-drift-alert-acceptance`). Уход кварца — проблема upstream-энкодера, она не зависит от транспортной целостности и должна классифицироваться отдельно. # AI-помощник для рекламаций Если у канала срабатывают *TR 101 290* или *PCR drift* алерты, оператор может одной командой получить готовый англоязычный промпт для AI-чата, который сформулирует формальное письмо-рекламацию в адрес upstream-провайдера потока. Endpoint: `GET /data/stream//ai-complaint-prompt`. Доступен с ролью *Viewer* (как и все GET-запросы по `/data/*`). Возвращает `text/plain; charset=utf-8`. Для **MPTS** возвращается 404 — метрики *T-STD* / *PCR drift* применимы только к **SPTS**. Промпт совместим с любым современным AI-чатом: «ChatGPT», «Claude», «DeepSeek», «Qwen», «Doubao». Тон письма — деловой, без обвинений; в конец промпта добавлен выбор языка готового документа: английский, русский, упрощённый китайский или любой другой по выбору оператора. Содержание промпта: - название и измеренные параметры стрима; - список всех активных токенов *TR 101 290* и *PCR drift* с расшифровкой стандарта; - численные значения и пороги; - влияние каждой ошибки на decoder-side. Что в промпт **не попадает**: имя стрима, ID, URI источника. Эти поля заменяются плейсхолдером `` — оператор подставит их сам перед отправкой, чтобы не утекали в третий AI-сервис.