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 и др.