Pcr accuracy error что это

Проверка временных меток в Transport Stream

Transport stream (TS) является доминирующим форматом передачи медиа данных в сетях цифрового телевидения IPTV, DVB/ATSC и OTT. Для формирования и воспроизведения TS используются временные метки PTS, DTS, PCR. Проверка временных меток помогает предотвратить проблемы с синхронизацией видео, аудио и других медиа данных. Основное внимание уделяется процессу формирования TS, подробному описанию и методологии проверки временных меток.

Существуют регламенты валидации временных меток. Имеются инструменты, помогающие анализировать TS. В этой статье представлен обзор подходов для проверки транспортных потоков с помощью Elecard Stream Analyzer.

I Мультиплексирование или формирования TS

Процесс можно описать следующим образом:

1. Последовательность сжатых видеокадров и аудио семплов, субтитров, страниц телетекста упаковывается в PES (Packetized Elementary Stream) пакеты.

• PES пакеты имеют переменную длину, их размер может варьироваться в зависимости от размера единицы упакованных данных.
• Каждый PES пакет имеет временную метку: PTS (Presentation Time Stamp) и DTS (Decoding Time Stamp).
• PTS указывает на момент времени, когда должен быть воспроизведен соответствующий элементарный поток данных (elementary stream — ES: видеокадр, аудио сэмпл, страница телетекста, субтитры).
• DTS (Decoding Time Stamp) указывает на момент времени, когда должен быть декодирован видеокадр.
• DTS метка указывается в том случае, если ее значение отличается от PTS.

2. В свою очередь каждый PES фрагментируется на TS (transport stream) пакеты фиксированного размера 188 байт¹.

• Если PTS и DTS это значения времени, то должна быть непрерывная шкала (часы), на которой эти значения отмерены. В качестве такой шкалы выступают PCR (Program Clock Reference) метки. Они указываются в заголовках TS пакетов.

3. В поток добавляются служебные данные — PSI/SI таблицы (Program Specific Information/System Information), SCTE-35, а также иные данные, которые передаются в рамках TS потока. Таким образом, Transport stream представляет последовательность TS пакетов (Рис. 1).

Рис.1 Структура Transport Stream

Мультиплексоры, модуляторы DVB/ATSC, пакетайзеры OTT задействуют PTS/DTS для синхронизации видео, аудио и др. ES. PCR используются для синхронизации часов отправляющей и принимающей стороны.

Ошибки и неточности во временных метках приведут к потере синхронизации, задержкам, проблемам с вещанием и воспроизведением.

Таким образом, контроль временных меток является критически важным для обеспечения высококачественного сервиса. Данная статья посвящена подробному исследованию методики валидации временных меток.

II Проверка TS относительно ETSI TR 101-290

Это технический регламент для цифрового телевидения DVB. Стандарт включает в себя 3 приоритета, ошибки временных меток собраны во втором приоритете.

В данной статье будут рассмотрены ошибки данного стандарта. Хотя существует аналогичный регламент для ATCS. Разница в подходах проверки временных меток заключается в наличии у ATCS более одного порогового значения на каждую ошибку, при этом базовые пороговые значения совпадают с регламентом ETSI TR 101-290. Он же используется при валидации TS в сетях IPTV и OTT.

Для анализа записи потока будет использовано приложение Elecard Stream Analyzer. Оно проверит поток и отобразит найденные ошибки в окне TR 101-290. С помощью Elecard Stream Analyzer можно убедиться в отсутствии следующих ошибок в записи потока (Рис. 2):

Рис.2 Ошибки ETSI TR 101-290

PCR Repetition error: означает превышение дельты между двумя последовательными значения PCR на 40 мс. Данная ошибка была исключена из регламента, т.к. по мнению экспертов, пороговое значение в 40 мс являлось слишком строгим требованием и не приводило к заметным проблемам.

PCR discontinuity indicator error —детектируется при превышении дельты между двумя последовательными значения PCR на 100 мс.

PCR accuracy — отражает точность расстановки PCR у выбранной программы — показывает разницу между ожидаемым и фактическим значениями PCR. При превышении порога в 500 нс детектируется ошибка. Чем точнее расставлены PCR, тем ровнее будет осуществляться вещание.

PTS error: ошибка возникает, когда повторение отметки времени PTS превышает 700 мс².

Рассмотрим видеопоток с частотой кадров равной 25, где за 1 секунду воспроизводится 25 видеокадров. Следовательно, длительность показа одного кадра составляет 40 мс (дельта между двумя последовательными PTS равна 40 мс). В соответствии с регламентами ошибка будет зафиксирована при превышении дельты PTS на 700 мс. Тогда как дельты 41-700 не будут являться ошибками, однако такие приросты времени свидетельствуют об отсутствии данных или, другими словами, дырах в вещании.

В большинстве случаев проверка ETSI TR 101-290 является достаточной, но не полной, поэтому переходим ко второму этапу.

III Визуальный анализ динамики временных меток

Stream Analyzer позволяет построить график для любого целочисленного значения. Чтобы сформировать график PTS или DTS, на панели Explorer необходимо поставить флажок PES напротив интересующего потока. Список PES пакетов отобразится в центральном окне. Выберите любой пакет, затем на панели Property щелкните правой кнопкой мыши по значению PTS и воспользуйтесь функцией Add to graphic control. В окне Graphics появится график. Для построения графика PCR алгоритм действий аналогичен, однако, метки времени PCR (в отличие от PTS/DTS) расположены в пакетах TS.

PTS и DTS имеют разрешение 90 кГц. Максимальное значение 2³³ — 1, система является цикличной. Значения должны монотонно возрастать с каждым последующим PES пакетом. Данное утверждение справедливо для видео кадров в display последовательности.

! В процессе сжатия энкодер может переупорядочить кадры, создав две последовательности:

• stream, в которой кадры были сжаты и уложены в поток;
• display, в которой кадры будут воспроизведены.

По аналогии с PTS/DTS, значения PCR должны монотонно увеличиваться. Эталонный график динамики временных меток имеет форму прямой (Рис. 3).

Рис.3 Динамика PTS, DTS, PCR

Отклонения свидетельствуют о проблемах с мультиплексированием, что может быть следствием ошибок во входном потоке, некорректно настроенном транскодере или мультиплексоре (Рис. 4).

Рис.4 Неравномерное приращение PTS меток

Рассмотрим вариант с OTT. Плеер воспроизводит HLS TS чанки последовательно. Каждый HLS чанк получается с помощью нарезки единого TS на множество отдельных файлов. Но OTT — это лишь часть дистрибьюции. Поэтому график нескольких последовательно соединенных HLS чанков должен иметь вид прямой, монотонно возрастая без разрывов.

IV Отсутствие ошибок относительно ETSI TR 101-290 и линейные графики временных меток не гарантируют отсутствия проблем в потоке.

Необходимо проверить чередование временных меток. Для этого воспользуемся инструментом Time Dynamics:

1. Выберем мод PTS only, в качестве Base укажем Video PID, а в качестве Complementary Audio PID. График показывает разброс между Видео и Аудио временными метками 3 секунды (Рис. 5).

Рис.5 Разброс меток PTS для Видео/Аудио

Чем сильнее разбросаны PTS, тем больше требуется размер буфера для синхронизации данных. Рабочий диапазон — до 1 секунды. Превышение порога может привести к следующим последствиям:

• возникновению дополнительной задержки;
• мультиплексор, модулятор или пакетайзер не сможет сформировать корректный TS, что будет видно по рваному графику вещания и логу с большим числом ошибок;
• с большой вероятностью приставки и плееры не смогут корректно воспроизвести такой поток. Будут наблюдаться рывки и замирания изображения, а также рассинхронизация аудио и видео.

Важно отметить, что на графике не должен наблюдаться тренд на увеличение или уменьшение дельты, т.к. это свидетельствует о постепенном разбегании меток, что точно приведет к описанным выше проблемам.

2. Выберем мод PTS only, Видео PID и PTS/DTS Dynamics. График показывает разницу между двумя последовательными значениями PTS для видео. По аналогии можно построить график для аудио. Данный график визуализирует ошибку второго приоритета PTS error, пороговое значение 700 мс (Рис. 6).

Рис.6 Дельты меток PTS по Видео PID

3. Выберем мод PTS/DTS, Видео PID и PTS/DTS Dynamics. График показывает разницу между PTS и DTS. В нормальных условиях график имеет вид константы, но возможны небольшие коллебания в верхнюю область. Тренд к росту или падению говорит о разбегании меток. Отрицательные дельты соответствуют случаю, при котором значения DTS больше PTS, такого быть не должно. В результате обоих вариантов с большой вероятностью возникнут проблемы с синхронизацией на отправляющей и принимающей стороне (Рис. 7).

Рис.7 Дельты меток PTS/DTS по Видео PID

4. PCR Dynamics показывает дельту между двумя последовательными значениями PCR. Пороговые значения 40 мс и 100 мс, при превышении которых детектируются ошибки 2 приоритета: PCR Repetition error и PCR discontinuity indicator error соответственно (Рис. 8).

Рис.8 Дельты меток PCR по Видео PID

5. Выбираем видео или аудио PID, PTS/PCR Dynamics. График показывает разброс между PTS и PCR метками для одного и того же момента. Рабочий диапазон — до 1 секунды. На рисунке 9 дельта составила 3 секунды. Возможны проблемы, описанные в пункте 1.

Рис.9 Разброс меток PTS/PCR по Видео PID

6. Offset/PCR Dynamics — график показывает дельты между позициями TS пакетов, содержащих метки PCR, и отражает насколько равномерно распределены значения PCR в потоке (Рис. 10). В нормальных условиях график имеет вид константы. На практике возможны колебания вокруг некоторого среднего значения как в нижнюю, так и в верхнюю области. На графике не должен наблюдаться выраженный наклон (тренд) к росту/падению.

Рис.10 Разброс меток PCR в потоке

7. PCR Accuracy — визуализация отклонения значений PCR от ожидаемых значений для выбранной программы (Рис. 11). Допустимое отклонение лежит в диапазоне ±500 нс, в противном случае, детектируется ошибка второго приоритета PCR accuracy. От точности расстановки PCR меток зависит битрейт всей программы, поэтому DVB/ATCS модуляторы крайне чувствительны к данной ошибке.

Рис.11 График PCR accuracy

В этом руководстве мы рассмотрели основные аспекты формирования TS, роль временных меток PTS, DTS, PCR и их валидацию. Приведенная информация поможет более эффективно настраивать, обслуживать и локализовать неисправности в сетях цифрового телевидения IPTV, DVB/ATSC и OTT.

¹В рамках данной статьи не рассматривается вариант реализации с кодами Рида-Соломона.

²В рамках данной статьи мы не рассматриваем вариант «Still pictures».

Александр Круглов — ведущий инженер компании Elecard. Работает в сфере видеоанализа с 2018 года. Александр отвечает за работу с крупнейшими клиентами Elecard, такими как Netflix, Cisco, Walt Disney Studios и др.

Особенности формирования и измерения PCR в MPEG-сигнале

Одной из важнейших задач при формировании, приеме и распространении цифровых телевизионных MPEG-потоков является обеспечение временной синхронизации сигналов. Этой цели служит вставка в цифровой поток специальных временных меток Program Clock Reference — PCR. Описанию того, что это за метки, как они влияют на работу цифровых устройств, методам измерений и диагностики посвящена эта статья. Основной материал для нее базируется на результатах исследований фирмы Tektonix, которые были использованы с любезного разрешения ее московского представительства.

Дмитрий Гиенко

Дмитрий Гиенко

Одной из важнейших задач при формировании, приеме и распространении цифровых телевизионных MPEG-потоков является обеспечение временной синхронизации сигналов. Этой цели служит вставка в цифровой поток специальных временных меток Program Clock Reference — PCR. Описанию того, что это за метки, как они влияют на работу цифровых устройств, методам измерений и диагностики посвящена эта статья. Основной материал для нее базируется на результатах исследований фирмы Tektonix, которые были использованы с любезного разрешения ее московского представительства.

Прием и ретрансляция сигналов цифрового телевидения требуют восстановления всех временных интервалов, использованных при формировании исходного сигнала. В ряде случаев восстановление принятых потоков может быть проблематичным в результате флуктуаций сигналов синхронизации. Далее кратко описываются принципы формирования сигналов синхронизации и измерений их флуктуаций.

На рисунке 1 приведена структурная схема формирования транспортного потока MPEG для цифрового компонентного сигнала. При формировании сжатого видео­сигнала MPEG кодер в качестве опорного генератора использует эталонный высокоточный генератор с частотой 27 МГц. Такой выбор опорной частоты обусловлен тем, что путем различных операций деления/умножения из него можно легко сформировать полный набор всех опорных сигналов, необходимых для аналоговых и цифровых видеосигналов различных стандартов. На рисунке 3 показано, как из частоты опорного генератора формируются все основные сигналы, необходимые для формирования телевизионных сигналов BT.601/PAL/NTSC.

В случае формирования транспорт­ного потока из входного сигнала PAL/NTSC схема выглядит несколько сложнее (рисунок 2), но в ней также присутствует опорный генератор 27 МГц.

В этом случае его частота формируется из входного сигнала с использованием петли фазовой автоподстройки частоты (ФАПЧ).

В обеих схемах опорный генератор подключается к счетчику, значения которого периодически фиксируются в регистре и включаются в выходной транс­портный поток как сигналы временнóй привязки — PCR.

Период и стабильность следования этих меток не являются слишком критическими. Так, в ISO/IEC13818-1 рекомендуется использовать интервал 100 мс, в то время как в DVB ETR154 это значение составляет 40 мс. Следует только заметить, что более высокая частота следования PCR-меток облегчает работу системы ФАПЧ приемника и делает ее более стабильной.

Требования к стабильности опорной частоты 27 МГц значительно более жесткие. Стандарт ISO/IEC13818-1 определяет допуск на значение PCR в ±500 нс, что соответствует отклонению частоты не более ±810 Гц или ±30 x 10-6.

Эти значения были положены в основу технологии измерений параметров PCR, описанной в документе ETR290, хотя в рекомендации четко указано, что это измерение не включает в себя любые нарушения транспорта.

Сигналы PCR в составе цифрового потока проходят весь путь распространения цифрового сигнала и дают цифровому ТВ-приемнику возможность синхронизации декодированного выходного видео c исходным видео на входе кодера. Приемник, то есть MPEG-декодер, для правильного функционирования должен считывать значения PCR, сравнивать их с собственными внутренними системными часами.

Если полученные значения PCR совпадают с системными часами декодера, часы на обоих концах синхронизированы. Отклонения опорного генератора декодера корректируются с помощью фазовой автоподстройки частоты — ФАПЧ (англ. PLL).

В процессе формирования цифрового потока и доставки его до декодера в сигналы PCR вносятся погрешности, которые приводят к ошибкам декодирования и являются одной из основных причин искажений в выходных видеосигналах MPEG-декодеров. Поэтому вопросы измерения различных параметров качества входящих PCR-сигналов имеют такое важное значение.

Точность формирования PCR конечна, определяется тактовой частотой генератора и не может превышать периода его колебаний ~37 нс. Далее мультиплексор сигнала вводит значение PCR в поток не в момент записи сигнала PCR, а в момент передачи соответствующего пакета, что также вносит дополнительную ошибку. При добавлении других сервисов также могут появиться дополнительные ошибки, если мультиплексор изменит положение пакета в потоке, содержащем PCR. Все эти ошибки в документе TR 101 290 получили название PCR_AC.

PCR accuracy (PCR_AC) включает в себя все ошибки опорной частоты 27 МГц, связанные с процессом формирования транспортного потока, но не включает дополнительные ошибки, связанные с транспортом, добавляющиеся при передаче и промежуточных преобразованиях.

Проблемы PCR проявляются в первую очередь в появлении артефактов на выходе MPEG-декодера или потере цветности на PAL/NTSC-изображении. Проблемы джиттера могут возникнуть при повторном мультиплексировании транспортного потока. Причина в том, что, например, меняется порядок следования пакетов транспортного потока без соответствующего изменения значения PCR.

Иногда джиттер PCR может значительно превышать допустимые значения ± 500 ns и не все декодеры могут это отработать. Информация PCR передается в поле адаптации пакета транспортного потока, принадлежащего к соответствующей программе. Информация о типе пакетов TS находится в соответствующей РМТ. Таблица PMT содержит так называемый PCR_PID, чаще всего для этой цели используют PID видео. Этот PID нельзя удалять из потока, так как без него будет невозможно декодирование сервисов.

В приемнике PCR извлекаются из транс­портного потока и значения отсчетов сравниваются с аналогичными отсчетами от локального генератора 27 МГц. Разница между полученными значениями PCR и значениями, генерируемыми локальным счетчиком, используется для управления ФАПЧ декодера (Phase Locked Loop).

Система ФАПЧ имеет ограничения по своим возможностям. Так, она может обеспечивать синхронизацию только в ограниченном диапазоне частот, но и это применимо только к медленным изменениям частоты. Для быстрых изменений частоты этот диапазон существенно сужается.

При выборе параметров системы ФАПЧ перед разработчиками стоит сложная задача выбора: если сделать петлю ФАПЧ инерционной, то это обеспечит высокую стабильность локального генератора, но полоса захвата и удержания такой петли получается невысокой. Если сделать постоянную времени петли малой («быстрая» ФАПЧ), то такая ФАПЧ способна захватить и удержать входной поток даже со значительным джиттером, но частота локального генератора при этом получается нестабильной.

Именно разница в настройке петли ФАПЧ является причиной того, что разные приемники по-разному принимают один и тот же поток при наличии в нем ошибок PCR. Некоторые устройства, такие как абонентские телевизоры и STB, в состоянии синхронизироваться, другие устройства, такие как профессиональные декодеры, не могут. В результате система теряет синхронизацию и просмотр ТВ-программы становится невозможным.

Таким образом, система ФАПЧ, обеспечивая синхронную работу опорных генераторов в передатчике и приемнике, дает возможность декодирования цифрового сигнала.

Однако, как отмечалось ранее, в процессе передачи цифрового сигнала по транспортным сетям генерируются дополнительные ошибки PCR, связанные с различиями во времени доставки пакетов (jitter) или даже с изменением порядка следования пакетов.

Ремультиплексоры, вставляя или удаляя некоторые потоки из сервисов, меняют положение пакетов, содержащих метки PCR, что приводит к дополнительным ошибкам PCR. Чтобы уменьшить такие ошибки, профессиональные мультиплексоры рассчитывают величину сдвига пакетов с PCR в транспортном потоке и корректируют содержащиеся в них значения PCR (PCR restamping). Но ошибки полностью не устраняются. Накопление таких ошибок может вызвать проблемы в цепи устройств на последующих этапах.

Рисунок 3. Формирование импульсов из опорной частоты

Эти ошибки имеют более сложную структуру по сравнению с ошибками PCR_AC. Учет ошибок, связанных с транспортом сигналов, потребовал доработки документов ETR290 и TR 101 290. Были добавлены еще три измеряемых параметра:

• PCR drift rate (PCR_DR) — ошибки, вызванные медленными изменениями PCR, связанными с вариациями параметров среды передачи (drift).

• PCR overall jitter (PCR_OJ) — ошибки, вызванные быстрыми изменениями PCR, связанными с вариациями параметров среды передачи (jitter).

• PCR frequency offset (PCR_FO) — смещение опорной частоты по отношению к эталонной частоте 27 МГц.

Можно заметить, что значения PCR_DR и PCR_OJ отражают влияние вариации параметров среды передачи и различаются только диапазоном частот. По рекомендациям DVB MG, вариации с частотами ниже 0,01 Гц относятся к PCR_DR, а выше — к PCR_OJ.

С практической точки зрения ошибки PCR_DR и PCR_FO могут быть относительно легко скорректированы системой ФАПЧ приемника, в то время как ошибки PCR_OJ являются более критичными.

Более сложной получается картина в том случае, когда принимаемый цифровой MPEG-поток преобразуется в сигналы аналогового стандарта PAL/SECAM/NTSC.

Рисунок 4. Прием и декодирование MPEG TS

Здесь, как и во многих подобных преобразователях, для формирования всех необходимых опорных частот используется общий опорный генератор 27 МГц (см. рисунки 3 и 4). В таблице 1 приведены требования к стабильности опорных частот для различных систем цветного телевидения. Из этой таблицы видно, что для систем PAL/NTSC эти требования существенно выше, чем требования к опорной частоте цифрового MPEG-декодера. Поэтому при преобразовании MPEG=>PAL/NTSC встречаются ситуации, когда при нормальном функционировании MPEG-декодера выходной сигнал PAL/NTSC формируется со сбоями. Чаще всего это проявляется в виде потери цветности. Исправить данную ситуацию можно ужесточением требований к ошибкам PCR или отключением опорного генератора PAL/NTSC от генератора MPEG-декодера и функционированием его в автономном режиме. Однако это требует поддержки от разработчиков оборудования.

Можно заметить, что требования к стабильности цветовых поднесущих стандарта SECAM существенно ниже, чем требования MPEG. Поэтому при использовании этого стандарта цветности вышеописанная ситуация практически не встречается.

На структурных схемах (рис. 1 и 2) видно, что, кроме опорного генератора MPEG-потока, в формирователях присутствует опорный генератор выходного битрейта. Это независимые генераторы. Причем генератор битрейта единый для всего транспортного потока и обеспечивает синхронизацию приемника/передатчика сети передачи. Его нестабильность также может влиять на ошибки PCR. Однако практически во всех системах передачи используется буферизация входного потока, когда нестабильный входной поток сначала загружается в буфер, а затем выдается в MPEG-декодер с равномерной скоростью с использованием вспомогательного стабильного опорного генератора. Это устраняет ошибки PCR, связанные с нестабильностью битрейта (например, от IP jitter), если они находятся в диапазоне буферизации потока.

Сложнее, если MPEG-поток содержит несколько программ. В этом случае он может формироваться как поток, содержащий единый PCR для всех программ (SPTS). Но чаще каждая программа имеет свой собственный PCR (MPTS). В этом случае документ ETSI TS 102 034 накладывает ограничения на передачу таких транспорт­ных потоков через IP-сети. Так, SPTS-поток может передаваться как в режиме VBR, так и в режиме CBR, но при передаче MPTS-потоков, содержащих несколько PCR, передавать их допускается только в CBR-режиме.

Заключение

Для обеспечения надежной работы сети распространения цифровых MPEG-сигналов выполнение требований по допуску на сигналы PCR в ±500 нс является недостаточным, необходимо проводить измерения параметров PCR по 4 параметрам:

Единственные измерения, которые могут выявить нарушения транспорта, облегчая тем самым выявление и устранение неисправностей, — это PCR_DR и PCR_OJ.

В случае использования MPEG-сигнала для преобразования программ в аналоговый формат требования к стабильности PCR должны быть значительно ужесточены либо можно рекомендовать использование системы цветности SECAM.

Для передачи по IP-сетям SPTS-сигналов можно использовать CBR- или VBR-режим передачи, для MPTS-сигналов — только CBR.

К сожалению, ограниченный объем статьи позволил дать только краткий обзор вопросов, связанных с проблемами PCR. Те, кого заинтересовал данный материал, могут найти более подробную информацию в первоисточниках, ссылки на которые приведены в конце статьи.

Использованная литература и полезные ссылки:

Guide to PCR Measurements, document number 25W-14617-0, Tektronix.

A Layman’s Guide to PCR Measurements, Tektronix, Technical Brief

Walter Fischer. Digital Video and Audio Broadcasting Technology. A Practical Engineering Guide. Second Edition.

ETSI TS 102 034 V1.5.1 (2014-05) Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks»

International Standard ISO/IEC13818-1 MPEG Systems

ETSI Technical Report ETR290 — Measurement Guidelines for DVB Systems — May ‘97

Draft ETSI Technical Report TR 101 290 — Measurement Guidelines for DVB Systems

A Guide to MPEG Fundamentals and Protocol Analysis – document number 25W-11418-3

Тестирование IPTV в режиме эмуляции ресивера (STB EMULATION)

Продолжаем серию статей про тестирование IPTV при помощи анализатора Greenlee DataScout 1G. В этом разделе мы рассмотрим тестирование в режиме эмуляции ресивера (STB EMULATION).

В режиме STB EMULATION устройство DataScout 1G подключается как конечное устройство для эмуляции ресивера телевещания (отправка запроса IGMP join). Приложение поддерживает стеки сетевых протоколов UDP/MPEG-2 TS и UDP/RTP/MPEG-2 TS.

Рисунок 1 – Схема тестирования IPTV в режиме эмуляции STB

ADSL2 или VDSL2

xDSL modem w/router

Модем xDSL с маршрутизатором

Головная станция видеосигнала

В приборе DataScout 1G должен быть установлен IP адрес и выбрана нужная (или создана новая) конфигурация прибора в меню «Настройки».

Перед началом эмуляции STB устройству DataScout 1G потребуется список каналов. Этот список включает номера каналов и IP-адреса, которые будут использоваться для тестирования. Список можно ввести вручную или импортировать через USB-порт устройства DataScout 1G. Подробнее работа со списком каналов описана в разделе «Импортирование, создание или редактирование списка тестируемых IPTV каналов».

После загрузки списка каналов (Channel List) для каждого канала будет отображено действие Connect (подключиться). После нажатия на Connect (подключиться) обозначение измениться на Disconnect (отключиться). Это означает, что при запуске эмуляции STB будет запрашиваться подключение к этому каналу. В зависимости от используемой полосы пропускания можно запросить одновременное подключение к нескольким каналам. Рекомендуется не превышать скорость 40 Мбит/с.

Запуск эмуляции STB

1. Далее следует выбрать каналы, к которым необходимо подключиться.
2. Чтобы запустить тестирование эмуляции, нажмите кнопку «Старт». В случае нахождения на экране списка каналов (Channel List), нажмите кнопку «Влево», чтобы перейти к экрану LIVE.

Подождите, пока не появится список подключенных каналов.

Рисунок 2 – Пример подключенного IPTV потоков

На рисунке 3 показан список подключенных потоков. Щелкните на значке «+», чтобы развернуть дерево с информацией о номерах PID внутри потока:

• Тип PID (таблица типа PAT/PMT/. и данные аудио/видео)
• Номер PID
• Пропускная способность для каждого PID, соответственно.
• Общая пропускная способность для всех подключенных каналов. (Примечание: Если общая пропускная способность превышает 40 Мбит/с, лишние каналы будут отключены.)

Рисунок 3 – Пример дерева с информацией о номерах PID внутри потока IPTV

В любое время во время тестирования можно вручную изменить состояние канала Connect/Disconnect (подключиться/отключиться) в списке каналов.

Если линии передачи имеются другие потоки, кроме перечисленных в списке каналов, они будут показаны как пассивные (если в настройках включена функция пассивного мониторинга (Passive Monitoring)).

Результаты тестирования IPTV в режиме эмуляции ресивера (STB)

Чтобы просмотреть подробные результаты, нужно щелкнуть на соответствующем узле дерева потоков на экране LIVE, а затем нажать кнопку «Вправо», чтобы перейти на экран статистики. Для каждого PID, а также для всего потока, на трех вкладках, обозначенных как Basic (основные), Packets (пакеты) и TR101290, будут представлены подробные показатели и информация о состоянии.

Вкладка Basic (основные)

Рисунок 4 – Результаты измерения IPTV: информация о потоке (STREAM) или PID в потоке

На этой вкладке представлена информация о потоке (STREAM) или PID в потоке, включая:

• Адрес многоадресной передачи
• Тип данных (поток/PID)
• Номер PID только для PID
• Битрейт
• IP-адреса источника и адресата
• UDP-адрес источника и адресата

Вкладка Packets (пакеты)

Рисунок 5 – Результаты измерения IPTV: информация о статистике пакетов потока

На этой вкладке представлена информация о статистике пакетов потока (STREAM), включая:

• Потери пакетов (общее количество и процентное соотношение)
• Нарушение последовательности пакетов (общее количество и процентное соотношение)
• Отброшенные пакеты (общее количество и процентное соотношение)
• Полученные пакеты (общее количество и процентное соотношение)

Вкладка TR101290

На этой вкладке представлена информация о показателях потока Priority 1 и Priority 2 для TR101290, включая:

Рисунок 6 – Результаты измерения IPTV: информация о показателях потока Priority 1 и Priority 2 для TR101290

Показатели Priority 1:

• TS Sync Loss (потеря синхронизации),
• Sync Byte Error (ошибка байтовой синхронизации),
• PAT Error (ошибка PAT),
• PAT 2 Error (ошибка PAT2),
• Continuity Error (ошибка последовательности),
• PMT Error (ошибка PMT),
• PMT 2 Error (ошибка PMT 2),
• PID Error (ошибка PID).

Показатели Priority 2:

• Transport Error (ошибка транспорта),
• CRC Error (ошибка CRC), PCR Error (ошибка PCR),
• PCR Repetition Error (ошибка повторяемости PCR),
• PCR Discountinuity Error (ошибка нарушения последовательности PCR),
• PCR Accuracy Error (ошибка точности PCR),
• PTS Error (ошибка PTS),
• CAT Error (ошибка CAT).

ffmpeg: ну очень неровный битрейт

Я тут опять с дурным вопросом. Наверное, блуждаю в трёх соснах. В общем, есть простейшая задача. Надо взять файл и завещать его мультикастом в кольце.

Файл изначально был в Mp4. Я очень аккуратно транскодировал его, аж в два прохода. Вот так:

ffmpeg -hide_banner -fflags +genpts -y -i sample_file.mp4 -c:v libx264 -profile:v high -b:v 4000K -g 25 -pass 1 -an -f mpegts /dev/null ffmpeg -i sample_file.mp4 -c:v libx264 -profile:v high -b:v 4000K -g 25 -pass 2 -c:a copy -b:a 128k -f mpegts sample_file.ts 

Тем самым я очень рассчитывал добиться более-менее ровного битрейта в выходном мультикасте. Ведь ffmpeg’у при таких делах вроде как и ремукса делать не надо, надо просто взять файлик и пульнуть его в виде udp-потока.

Вот параметры файла для вещания:

Input #0, mpegts, from 'sample_file.ts': Duration: 00:08:14.46, start: 1.458667, bitrate: 4490 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:1[0x101](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 139 kb/s 

Вот как я это сделал:

ffmpeg -threads 0 -re -stream_loop -1 -i sample_file.ts -c copy -f mpegts "udp://@235.5.5.5:1234?pkt_size=1316"

И что же получилось? Плеваться хочется. Ну, ошибки типа PCR error и PCR accuracy error — это неизбежное зло. Бес с ними. PAT error и PMT error меня немного удивили. Хотя понятно, что появляются они на стыке, когда ffmpeg заканчивает вещание файла и приступает к его чтению заново. Но неужто там никакой буферизации нет? Или её, буферизацию, надо как-то задавать заранее?

Но вот битрейт. Взгляните сами. Исходный файл, как показано выше, имеет битрейт около 4,5 Mbps. А у мультикаста он скачет как сумасшедший.

В результате когда я подаю этот поток на ремультиплексор (чисто для выравнивания битрейта), то на особо резвых скачках получаю адову пачку CC error, что есть ад и ужас.

Где грабельки? Что я не предусмотрел? Как поправить дело?