Проверка временных меток в 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 и др.
Расчет pts dts и duration FFmpeg и C++
есть вектор, который содержит кадры и временные метки, соответствующие кадру:
std::vector> rawData; Кадры это просто QImage . Временные метки получаются так:
const int64_t timestamp = QDateTime::currentMSecsSinceEpoch(); Настройка контекста:
pCodecCxt->time_base = AVRational; pCodecCxt->framerate = AVRational; как правильно вычислить с учетом временных меток кадра?:
pkt.pts = ?; pkt.dts = ?; pkt.duration = m_currentFrameTimestamp - m_previousFrameTimestamp; UPD: Итак, зная метки кадров, я могу вычислять продолжительность кадра и начало каждого кадра.
int64_t frameTime; int64_t frameDuration; int count = m_frameCounter++; frameDuration = m_currentFrameTimestamp - m_previousFrameTimestamp; frameTime = count * frameDuration; pkt.pts = frameTime; pkt.dts = pkt.pts; pkt.duration = frameDuration; Остался вопрос по поводу настройки контекста tame_base. Так как временные метки в миллисекундах, то видимо должно быть так:
pCodecCxt->time_base = AVRational; UPD: Это по прежнему не работает.
int64_t frameTime; int64_t frameDuration; int count = m_frameCounter; frameDuration = (m_currentFrameTimestamp - m_previousFrameTimestamp) / (1000 / 60); frameTime = count * frameDuration; pkt.pts = frameTime; pkt.dts = pkt.pts; pkt.duration = frameDuration; Pts dts что это
Элементарный Поток (ES)
Элементарный поток — самый простой формат MPEG-кодированной информации. По существу, это последовательность кодированного видео или аудио сигнала. Поток для звука и поток для видео зачастую формируются разными процессорами в большинстве MPEG-кодеров.
Элементарные потоки имеют внутреннюю структуру, указывающую декодерам о способе восстановления данных. Например, определяют тип передаваемого фрейма (I, P или B), относительное положение блока данных на экране и другую служебную информацию. В звуковом ES потоке обычно содержится информация о частоте дискретизации исходного сигнала и используемого типа сжатия.
Для элементарных потоков характерно непрерывное формирование: MPEG кодер будет формировать каждый из типов ES видео и звука пока их сигналы присутствуют на входе устройства. Это естественно для видео систем, но не для IP систем. IP сети разбивают большие объемы данных на мелкие фрагменты (пакеты). Поэтому следующим типом MPEG потоков рассмотрим пакетированные элементарные потоки.
Пакетированные Элементарные Потоки (PES)
Пакетированные элементарные потоки (Packetized elementary stream, PES) основываются на элементарных потоках, разбитых на фрагменты (пакеты). Каждый пакет (PES) состоит из заголовка, включающего цифровой код источника элементарного потока. Эта информация важна для последующего восстановления из мультипрограммного потока, содержащего несколько каналов видео и аудио данных и определения какому элементарному потоку видео принадлежит элементарный поток звука. Некоторые PES содержат информацию о временных метках. PES могут быть различной длины размером сотни килобайт и более.
Для видео сигнала могут использоваться два вида временных меток: PTS (presentation time stamp) и DTS (decode time stamp). PTS кадра определяет время, когда данный кадр должен быть показан. DTS кадра показывает время, когда данный кадр должен быть обработан декодером.
Для понимания различия между PTS и DTS нужно иметь представление о типах фреймов, используемых в MPEG кодировании (I, B и P). Напомним, что фрейм I-типа не содержит какой либо информации о предыдущих кадрах видеосигнала. Фрейм P-типа содержит информацию только об изменениях в кадре относительно предыдущего фрейма I или P-типа. Фрейм B-типа может быть вычислен на разнице предыдущих или последующих фреймах I или P-типа. Далее рассматривается пример группы кадров (GOP — Group of Picturies) с последовательностью IB1B2P
В рассматриваемом примере фрейм I должен быть отображен первым, поэтому он должен иметь более раннюю временную метку PTS, чем временные метки остальных фреймов данной GOP. Первый фрейм В-типа, B1, должен быть отображен вторым, а B2 — третьим. PTS вовсе не обязательна для каждого фрейма, в случае ее отсутствия декодер самостоятельно высчитает необходимую PTS. Наконец, фрейм P-типа должен быть отображен последним со значением PTS самым поздним из всех 4-х.
Следующий рисунок наглядно отображает вышесказанное.
Используя этот же пример рассмотрим DTS. Как и в первом случае фрейм I-типа должен быть декодирован первым. Однако далее декодеру требуется получить фрейм P, т.к. без его декодирования не удастся правильно восстановить фреймы B-типа. Другими словами, перед декодированием фрейма B, декодеру необходимо иметь данные о предыдущих и последующих фреймах, т.е. DTS для фрейма P должна быть меньше, чем DTS для B-фреймов.
Все это важно для понимания задач вещания видео по IP сетям, т.к. в данном случае выбирается компромисс между качеством передаваемого видеосигнала и шириной пропускания канала связи. Отличие фреймов P-типа состоит в меньшем объеме данных по сравнению с фреймами I-типа (примерно в двое), а фреймов В-типа — меньшем объеме данных по сравнению с фреймами P-типа (опять же в двое). Поэтому поток, содержащий большое количество фреймов В-типа нуждается в меньшей полосе пропускания, чем поток с небольшим содержанием фреймов В-типа. К сожалению, увеличение числа фреймов В-типа ведет к увеличению задержек. Для просчета фрейма В-типа, кодеру необходимо получить два фрейма (I или P), на которых фрейм В-типа собственно и основывается. В NTSC системах задержка составляет 33 мсек на В-фрейм, в PAL/SECAM системах — 40 мсек. Увеличивая число фреймов В-типа в потоке, мы экономим на полосе пропускания, но теряем в увеличении времени задержки системы в целом.
Программный поток (PS)
Программный поток (Program Stream) несет информацию об одной программе. Он состоит из одного или нескольких PES и добавленной служебной информацией. Все элементарные потоки одной программы привязаны к единому таймеру синхронизации, для обеспечения синхронного отображения видео данных и звукового сопровождения. Программные потоки используются в основном в DVD и в других системах, где вероятность появления ошибок минимальна. Программные потоки могут иметь переменный bit-rate и обычно используют длинные пакеты.
В MPEG программа состоит из видеопотока, звукового сопровождения и соответствующих им данных (титры, телетекст и т.п.). Обычно видеопотоку соответствует один стерео канал звукового сопровождения, но в программе может так же присутствовать звуковой канал для Surround систем, звук на другом языке, комментарии. Данные могут содержать титры, информацию о программном потоке (название, владелец, описание) и т.д. Управляющая информация другой важный тип данных передаваемых в программном потоке, включая информацию, необходимую для записи и воспроизведения. Системам условного доступа так же необходимо передавать свою служебную информацию в программном потоке.
Напомним, что несколько каналов видео могут принадлежать одному программному потоку (до 16 видео и 32 звуковых каналов), но при этом остается в силе требование о привязке к единому таймеру синхронизации. Примером может служить спортивная трансляция, когда одно действие отображается с нескольких камер.
Транспортный поток (TS)
Транспортный поток (TS — transport stream) подобен программному потоку — они оба объединяют видео поток, поток звука и относящиеся к ним данные в логическую группу. В отличие от программных потоков, транспортные потоки были разработаны специально для последующей их передачи по телекоммуникационным сетям, в которых могут возникать ошибки. Многие приложения попадают в данную категорию — спутниковое и наземное вещание, все типы проводных и оптических сетей. Другим немаловажным отличием является то, что программный поток несет только одну программу, а транспортный поток может нести несколько программ. В литературе и в других источниках вместо термина «программа» может использоваться термин «сервис» или «канал».
Транспортный поток использует фиксированную длину пакета, равную 188 байт, приспособленного для сетей с постоянным бит-рейтом. Каждый пакет содержит данные только из одного элементарного потока. Код FEC (Forward error correction) так же может быть добавлен в данный поток с использованием стандартных кодов восстановления ошибок таких, как Reed-Solomon (RS). В транспортном потоке широко используемый RS-код добавляет 16 или 20 байт к 188-байтному пакету. Получаемые при этом пакеты длиной 204 байта широко используются в DVB приложениях, распространенных в Европе и на нескольких DTH спутниковых системах. Пакеты длиной 208 байт используются в приложениях ATSC (Advanced Television Systems Committee), распространенных системах наземного вещания США (иногда называемых DTV или HDTV). Основное назначение RS-кодов — обеспечение возможности восстановления ресиверов всего пакета в случае возникновения ошибки. 16-ти байтный RS-код позволяет восстановить ошибки в 8-ми байтах пакета; 20-ти байтный RS-код — до 10-ти искаженных байт (FEC не дает особого в выигрыша в системах гарантированной доставки, таких как TCP сети, т.к. в таких системах искаженные байты могут быть посланы заново).
Очень важно понимать, что длина пакета транспортного потока не равна длине IP пакета, предназначенного для его (TS-пакета) пересылки. Обычно IP пакет может содержать несколько TS пакетов. IP пакет, содержащий 7 TS пакетов наиболее распространен, т.к. 7 — наибольшее число TS-пакетов, которые могут быть вставлены в IP пакет без фрагментации. Напомним, что максимальная длина IP пакета, которая может быть послана в Ethernet кадре равняется 1500 байт.
Другая техника обработки ошибок в TS — это использование чередования (interleaving). В данном случае, TS пакеты имеют свой порядок сортировки, при котором в IP пакет не попадают соседние TS пакеты. Это может быть очень удобным, когда один IP пакет потеряется при передаче; MPEG декодеру проще скрыть потерю нескольких изолированных TS пакетов, чем скрыть потерю группы соседних пакетов. Большое преимущество чередования заключается в «сокрытии» возникающих ошибок без добавления дополнительных битов к основному пакету. Недостатком такого метода является возникающие дополнительные задержки в системе, которые могут быть критичными в ряде приложений.
Для указывания ресиверу, как PES организованы в сервисы, необходимо в транспортный поток включить дополнительную служебную информацию. Основным понятием, используемым в транспортных потоках является PID (Packet IDetntifier — идентификатор пакета). PID однозначно определяет какой элементарный пакет содержит TS-пакет. Например, пакеты для видео сигнала в транспортном потоке могут иметь PID=42, а относящийся к нему сигнал звукового сопровождения PID=38. Второй канал звукового сопровождения (на другом языке) для того же видео сигнала имеет PID=85.
Для отслеживания всех PID-ов, MPEG определяет несколько таблиц, несущих служебную информацию транспортного потока. PID=0 используется для PAT (Program association table — таблица соответствия программ), которая отображает все программы в данном транспортном потоке. Каждая запись в PAT указывает на PMT (program map table — таблица карты программ), по одной для каждой программы. (Напомним,что программа — это набор из видео, звука и данных, относящихся к одному событию). Внутри PMT содержится список PID-ов для данной программы, какой бы она не была. Когда пользователь выбирает для просмотра программу, PAT и PMT определяют какой видео поток необходимо направить в видео декодер, а какйо звуковой поток в декодер звука.
Program Clock Reference (PCR)
PCR — 33 битное число, периодически вставляемое в транспортный поток, в целях синхронизации MPEG декодера с синхрогенератором 27 МГц MPEG кодера. Синхронизация необходима для слежения за состоянием входного буфера декодера. Значение 33-битного счетчика, связанного с синхрогенератором 27 МГц в кодере, периодически вставляется в транспортный поток. Декодер извлекает его из транспортного потока и использует PCR для активации синхронизации внутреннего генератора 27 МГц. Точность синхронизации зависит от постоянства поступления данных от кодера в декодер. Влияние любых изменений во времени доставки пакетов при проходе по сети по возможности должны быть уменьшены либо исключены вовсе. Однако небольшие задержки все же будут возникать, поэтому важно, что бы декодер был спроектирован с учетом данного факта.
Мультиплексирование потока и DVB-ASI
Очень часто желательно объединять несколько транспортных потоков вместе для последующей передаче по сети. Конечно это может быть осуществлено преобразованием каждого потока в IP пакеты и передачей их по IP сетям. В рамках проекта DVB (Digital Video Broadcasting) разработан другой метод для передачи многопрограммных потоков по сетям, обычно используемым для передачи SDI сигнала (последовательный некомпрессированный цифровой поток скоростью 270 Mbps, содержащий одну программу). Этот метод носит название DVB-ASI (Asinchronous Serial Interface) и позволяет объединять в единый поток несколько программ, даже если они имеют разные бит-рейты.
По сути DVB-ASI поток представляет канал со скоростью 270 Mbps с добавленной полезной нагрузкой, которая может состоять из одной или нескольких программ с разными бит-рейтами. Суммарный бит-рейт всех программ не может превышать 200 Mbps, но и этого хватает для передачи большоего количества программ со скоростями от 4 до 8 Mbps.
В настоящее время DVB-ASI используется очень широко. Разработано большое количество MPEG-кодеров с ASI выходами, MPEG-декодреов с ASI входами, мультиплексоров, видео серверов и т.п. оборудования. DVB-ASI очень прост в использовании для внутристудийного обмена. Наконец, уже большое число компаний предлагают услуги по доставке видео по сетям оптимизированным под 270 Mbps и использующим DVB-ASI.
Мультиплексирование потока может показаться относительно простой задачей, но на практике зачастую это процесс является сложным, имеющим дело с плотным взаимодействием мультиплексора с MPEG-кодером. На самом простом уровне мультиплексирование представляет собой разбиение PES на 188-битные транспортные потоки, с назначением PID каждому PES и передачей пакетов согласно выделенной полосе канала. Следуя передовым технологиям мультиплексирования и тенденциям развития цифрового телевидения в данный процесс мультиплексирования внесены существенные изменения. Обычно кабельный оператор устанавливает фиксированное значение бит-рейта на MPEG кодере и назначает фиксированное значение бит-рейта каждому PES при мультиплексировании. Это не самый лучший способ использования имеющегося канала передачи данных, т.к. некоторые сцены в видео сигнале требуют значительно меньшей полосы канала, чем им было назначено в кодере и в мультиплексоре. В то же время другие каналы в этом же транспортном потоке могут нуждаться в дополнительном увеличении бит-рейта.
Для решения этой проблемы многими операторами используется технология статистического мультиплексирования. Данный метод основывается на предположении, что в один момент времени только несколько видео программ могут содержать сцены, требующие широкого канала (спортивные передачи, фильмы в стиле Action и т.п.). Мультиплексор использует информацию о сложности сцены и определяет потребность выбранного канала в ширине полосы пропускания и тем самым может «занять» часть полосы у каналов, в данный момент времени содержащие статичные или маломеняющиеся сцены. Наибольшей производительности системы можно добиться, когда MPEG кодер сам сообщает мультиплексору информацию о сложности видео сцен.
Как проверить корректность PTS в транспортном потоке?
PTS (временная метка воспроизведения) — это число, указывающее время, когда необходимо воспроизвести единицу элементарного потока (видеокадр, аудио, DVB субтитры). Это один из важнейших показателей, по которому можно судить, будет ли видео проигрываться корректно. Согласно стандарту ETSI TR 101 290 период повторения PTS не должен превышать 700 мс, иначе фиксируется ошибка второго приоритета — PTS Error.
Stream Analyzer позволяет легко проверить поток на соответствие данному стандарту. Наличие подобных ошибок можно увидеть на панели TR101-290.
Дельты значений PTS представлены на панели Time Dynamics. В выпадающих списках необходимо выбрать PTS Only, интересующий PID и график PTS/DTS Dynamics.
Чтобы визуально оценить возрастание значений PTS, в Stream Analyzer можно построить график для любого целочисленного параметра. На панели Explorer поставьте флажок напротив желаемого PES, а затем на панели Property щелкните значение PES и выберите Add to graphic control. В окне Graphics появится график.
К заголовку, отображаемому в главном окне, вы можете добавить любой параметр (например, значение PTS). Это позволит в дальнейшем легко находить необходимые PES.
Для этого на панели Property щелкните желаемый параметр и выберите Show in header title.
Stream Analyzer — приложение для анализа синтаксиса медиапотока: проверка структуры, а также выявление и анализ ошибок в составе контейнера и транспортных потоков (transport stream).