PCR в MPEG-TS: программные часы, на которых держится вещание

Коротко

Транспортный поток передаёт тысячи кадров аудио и видео в секунду, но ни одна временная метка не имеет смысла, пока плеер не знает, по каким часам она отсчитывается. Программные часы – PCR (program clock reference) – и есть эти самые часы: периодический снимок мастер-часов кодера на частоте 27 МГц, вставляемый в поток, чтобы декодер мог восстановить аналогичные часы у себя и воспроизвести каждый кадр точно в нужный момент. Эти часы тикают 27 миллионов раз в секунду, хранятся в виде 42-битного числа, разбитого на базовую часть с частотой 90 кГц и более точный остаток на 27 МГц, а декодер с помощью контура обратной связи подстраивает свои часы под них с точностью до ±500 наносекунд. Если PCR настроить правильно – вещание будет стабильным сутки напролёт; если же они дрожат или приходят с задержкой – возникнут рывки, переполнение буферов и рассинхрон звука с изображением.

Почему это важно

Если вы строите что-либо, что принимает, обрабатывает или воспроизводит transport stream – OTT-бэкенд, приложение IPTV для приставки, контрибуционный канал вещания, сервер вставки рекламы – PCR – это единственное значение, которое определяет, будет ли воспроизведение плавным или сломанным. Продакт-менеджеру важно знать, что PCR существует, чтобы понимать, почему «просто перемультиплексируй» может незаметно нарушить тайминг и почему инженеры вещания так трепетно относятся к числу, которое большинство файловых форматов даже не отображают. Инженеру нужно знать, как именно кодируется PCR, как часто он должен появляться и насколько строго должен соблюдаться, чтобы по отчёту анализатора потока отличить реальную ошибку от фонового шума. Эта статья даёт обоим читателям одну модель: PCR – это сердцебиение, на котором построены все часы вещания, и каждый PTS и DTS без него теряют всякий смысл.

Задача, которую решает PCR: метку нужно сравнивать с чем-то

Начнём с факта, который удивляет тех, кто изучал тайминг по MP4-файлам. В transport stream метка презентации (PTS – число, означающее «показать этот кадр сейчас») сама по себе недостаточна. PTS, равный 90 000, означает «девяносто тысяч тиков после нуля часов» – но у декодера ещё нет часов. Он только что получил пакет со спутникового канала или кабельного фида и не знает, что такое «сейчас» на временной шкале отправителя. Метка времени – это показание часов, а у декодера их пока нет.

Этот пробел и заполняют программные часы. Кодер ведёт мастер-часы. Время от времени он фиксирует текущее значение этих часов и вставляет его в поток как PCR. Декодер считывает эти значения, воссоздаёт у себя копию часов кодера и только после этого может корректно интерпретировать значения PTS и DTS для каждого кадра. PCR – общий ориентир; PTS и DTS – позиции, отсчитываемые от него. Как работают PTS и DTS, мы подробно разобрали в статье PTS, DTS и метка времени элементарного потока – а эта статья посвящена именно тем самым часам, по которым обе метки отсчитываются.

Думайте об этом как о настенных часах на заводе. Рабочие (значения PTS и DTS) дают указания вроде: «отгрузить заказ в 15:00» и «начать партию в 15:05». Эти инструкции ничего не значат для нового сотрудника без часов. Настенные часы – это PCR: общий ориентир, по которому каждый синхронизирует свои часы. Без них любое «15:00» – просто число без смысла.

Нажмите, чтобы увеличить

Мастер-часы на 27 МГц

Каждую программу в transport stream тактируют мастер-часы, и стандарт фиксирует их частоту. Эти часы тикают 27 000 000 раз в секунду – 27 МГц. Любое значение тайминга в потоке исходит от этих одних и тех же часов. Привычные 90 кГц, используемые для PTS и DTS, – вовсе не отдельные часы; это мастер-часы 27 МГц, делённые ровно на 300:

часы 90 kHz = 27 000 000 ÷ 300 = 90 000 тиков в секунду

Зачем тогда вообще нужны часы 27 МГц, если PTS и DTS хватает 90 кГц? Две причины. Во-первых, более тонкое разрешение позволяет декодеру подстраивать свои часы значительно точнее, чем с шагом в 90 кГц: один тик 27 МГц – это около 37 наносекунд против 11 микросекунд у тика 90 кГц. Во-вторых, 27 МГц выбрали потому, что из этой частоты можно чисто синтезировать поднесущую аналогового цветного телевидения, а это было крайне важно, когда MPEG-2 разрабатывали в начале 1990-х, и каждый декодер подключался к аналоговому экрану. Это число – мост между цифровым потоком и аналоговым миром, из которого он вырос.

Часам не разрешено свободно блуждать. Стандарт MPEG-2 systems требует, чтобы тактовая частота кодера на 27 МГц удерживалась в узком диапазоне – от 27 000 000 − 810 Гц до 27 000 000 + 810 Гц. Это составляет ±30 частей на миллион (810 ÷ 27 000 000 = 0,00003). Если бы частота вышла за эти пределы, восстановленные часы декодера тоже вышли бы за допустимые границы, и буферы декодера начали бы медленно заполняться или опустошаться, пока воспроизведение не сломается. Тридцать ppm – это допустимое отклонение; вся система PCR существует для того, чтобы удерживать декодер в этих рамках.

Как строится число PCR

PCR – это один момент часов 27 МГц, но хранится он не как одно простое число. Он разбит на две части так, чтобы грубая часть точно совпадала с часами 90 кГц (которыми пользуются PTS и DTS), а тонкая часть фиксировала остаток. Полное значение – 42 бита данных, переносимых в 48-битном поле (лишние 6 бит – зарезервированное заполнение).

Обе части определяются простой арифметикой на основе показаний мастер-часов. Пусть мастер-часы зафиксировали t тиков при частоте 27 МГц. Тогда:

PCR_base = (t ÷ 300) с округлением вниз, затем по модулю 2^33
PCR_ext  = t по модулю 300
PCR      = PCR_base × 300 + PCR_ext

База – это значение в единицах 90 кГц; оно находится в том же временном домене, что и PTS и DTS, поэтому их можно напрямую сравнивать. Ширина базы – 33 бита, столько же, сколько у PTS. Расширение – это остаток от количества тиков 27 МГц, прошедших с последнего шага 90 кГц, число от 0 до 299, хранящееся в 9 битах (9 бит позволяют хранить значения от 0 до 511, что с запасом покрывает диапазон 0–299). Объедините обе части – и вы восстановите полное значение в 27 МГц с точностью до одного тика.

Числовой пример делает разбиение наглядным. Пусть мастер-часы кодера отработали ровно 27 000 123 тактов – чуть больше одной секунды:

t        = 27 000 123 тика на 27 MHz

PCR_base = (27 000 123 ÷ 300) с округлением вниз
         = 90 000 (остаток 123)       → показание 90 kHz: 1,000000 с

PCR_ext  = 27 000 123 по модулю 300
         = 123                          → 123 дополнительных тика 27 MHz

собранный PCR = 90 000 × 300 + 123 = 27 000 123   ✓

База выдаёт «одну секунду» – идеально синхронизируясь с часами PTS на частоте 90 кГц. Расширение добавляет 123 тонких тика, которые база не может выразить сама. Декодеру нужны обе части, чтобы точно настроить часы: опора только на базу давала бы точность до 11 микросекунд, а этого недостаточно для стабильного вещания.

Нажмите, чтобы увеличить

Где едет PCR и как часто

У PCR нет собственного типа пакета. Он передаётся в поле адаптации (adaptation field) – необязательном дополнительном заголовке, который пакет transport stream может содержать перед полезной нагрузкой. Transport stream представляет собой последовательность пакетов фиксированного размера – 188 байт, каждый из которых помечен идентификатором пакета (PID), указывающим, к какому потоку он относится. Носителю PCR назначается один PID на программу (он указан в таблице PMT), и каждый раз, когда пакет с этим PID должен передать значение часов, он устанавливает флаг в поле адаптации и записывает туда 42-битный PCR.

Как часто это должно происходить? Стандарт MPEG-2 systems устанавливает ограничение: соседние PCR одной программы должны поступать не реже чем раз в 100 миллисекунд. Это максимально допустимый интервал по стандарту. На практике в индустрии вещания требования строже: рекомендации по измерениям DVB (ETSI TR 101 290) предполагают наличие PCR не реже чем каждые 40 миллисекунд, а многие кодеры вставляют их ещё чаще. Причина проста – контур восстановления часов в декодере корректируется только при получении нового PCR, поэтому более частые метки обеспечивают более точное и стабильное восстановление временных меток. Слишком редкие PCR приводят к дрейфу часов декодера между обновлениями; слишком частые – к избыточному расходу полосы пропускания на служебную информацию. Интервал от 40 до 100 миллисекунд – это диапазон, на котором сегодня работает индустрия.

Вот первая распространённая ошибка, которую стоит назвать. Когда инструмент пере-мультиплексирует или пере-таймирует transport stream – врезает рекламу, меняет битрейт, переупаковывает под другой канал доставки, – он обязан перештамповать PCR под новые позиции пакетов. Вся задача PCR – указать, «вот показание часов в момент, когда этот пакет уходит», и если позиция пакета во времени изменилась, а PCR осталась прежней, значение становится неверным. Удивительно большая доля сбоев в эфире связана с этапом перемультиплексирования, на котором пакеты сдвигаются, но старые значения PCR копируются дословно.

Как декодер восстанавливает часы

Декодер оснащён свободно бегущим генератором на 27 МГц, частота которого близка к 27 МГц, но не точна – каждый кварц работает чуть быстрее или чуть медленнее. Его задача – подстраивать этот генератор так, чтобы он максимально точно синхронизировался с часами кодера, исходя из поступающих PCR. Для этого используется контур фазовой автоподстройки, или PLL (phase-locked loop) – цепь обратной связи, сравнивающая две частоты и выравнивающая их.

Контур выполняет простой цикл. Когда приходит PCR, декодер считывает из него значение часов кодера и сравнивает с собственным локальным временем в тот же момент. Если локальные часы опережают – генератор работает слишком быстро, и контур немного его замедляет; если отстают – ускоряет. Каждый PCR даёт одну коррекцию. За счёт множества PCR локальные часы постепенно выравниваются с часами кодера и далее следуют за ними, оставаясь синхронизированными, пока поступают свежие PCR. Эти восстановленные часы – системные часы декодера, STC (system time clock). Каждый PTS и DTS в потоке интерпретируются относительно этого восстановленного STC: когда STC достигает значения PTS кадра, кадр выводится на экран.

Эту цепочку стоит проговаривать прямо, потому что она – сердце всей системы. Мастер-часы кодера генерируют PCR. PCR позволяют декодеру восстановить те же часы как STC. STC – это эталон, с которым сравниваются PTS и DTS. Сломайте первое звено – дрожащие, запоздалые или неверные PCR – и каждая метка ниже по цепочке становится ненадёжной, даже если сами значения PTS и DTS идеальны.

Нажмите, чтобы увеличить

Джиттер, дрейф и смещение PCR: когда сердцебиение сбивается

Поскольку декодер полностью полагается на PCR, качество сигнала PCR напрямую определяет точность восстановленных часов. Инженеры в области вещания измеряют три основных способа, при которых поток PCR может давать сбои, и рекомендации по измерениям DVB (ETSI TR 101 290) описывают каждый из них.

Точность PCR, обычно называемая джиттером, – это насколько каждое отдельное значение PCR отклоняется от положения, которое оно имело бы при идеальных часах. Стандарт MPEG-2 требует, чтобы точность вставляемого PCR находилась в пределах ±500 наносекунд. Джиттер, превышающий этот порог, сбивает работу PLL: каждая коррекция контура основана на слегка ошибочном значении, из-за чего восстановленные часы начинают «дрожать» вместо стабильного хода. Основной причиной обычно является сеть между кодером и декодером: пакеты, которые должны прибывать с равными интервалами, группируются и растягиваются коммутаторами и маршрутизаторами, и PCR оказывается в реальном времени позже или раньше, чем указывает его значение.

Скорость дрейфа PCR – это скорость изменения частоты часов кодера. Если часы постепенно ускоряются или замедляются, PLL декодера вынужден «догонять» движущуюся цель. Рекомендации DVB ограничивают скорость изменения частоты значением 75 миллигерц в секунду (около 2,77 части на миллиард в секунду) – намеренно очень маленькое число, поскольку при более быстром дрейфе часы рано или поздно выйдут за пределы допуска декодера ±30 ppm и приведут к сбою воспроизведения.

Смещение частоты PCR – это фиксированная ошибка: часы кодера идут, например, на 27 000 400 Гц вместо 27 000 000. Пока смещение остаётся в пределах окна ±810 Гц (±30 ppm), допустимого стандартом, декодер может к нему подстроиться. Как только оно выходит за эти границы, декодер уже не успевает за синхронизацией, и его буферы начинают медленно заполняться или опустошаться.

Видимые симптомы напрямую связаны с причиной. Буфер, который медленно заполняется, потому что часы декодера отстают от потока, означает, что декодер в конце концов вынужден сбрасывать кадр, чтобы догнать – это и есть периодические рывки. Буфер, который медленно опустошается, означает, что у декодера нет кадров для отображения, и он на мгновение замирает. А подстроенные, но нестабильные часы вызывают самый коварный сбой: звук постепенно смещается относительно изображения на несколько миллисекунд за много минут – недостаточно сильно, чтобы сразу насторожить при быстрой проверке, но явно заметно к концу длительной программы. Когда зритель жалуется на рассинхрон, который «тем хуже, чем дольше смотрю», опытный инженер первым делом проверяет PCR. О том, что считается заметным дрейфом, см. Что значит «в синхроне»: ITU-R BT.1359, окна допусков рассинхрона.

Таблица 1. Четыре способа сбоя потока PCR, соответствующие лимиты и то, что видит зритель. Анализатор потока сообщает о всех четырёх; лимиты взяты из ISO/IEC 13818-1 и ETSI TR 101 290.

Почему MPEG-TS – а значит и PCR – всё ещё повсюду

Справедливо задать вопрос: почему модель часов, разработанная в начале 1990-х годов для спутниковой и кабельной передачи, в 2026 году по-прежнему удерживает большую часть видеомира, несмотря на появление более современных контейнеров и транспортных протоколов? Ответ прост: transport stream был создан для работы в условиях враждебных односторонних каналов, и до сих пор не существует равного ему решения там, где канал ненадёжен и отсутствует возможность запросить повторную передачу.

Transport stream – это последовательность небольших пакетов фиксированного размера по 188 байт, каждый из которых декодируется независимо и содержит собственную временную метку. Если спутниковый сбой или помехи в кабеле повредили один пакет, остальной поток остаётся нетронутым – декодер синхронизируется по байту синхронизации следующего пакета и продолжает работу. На уровне выше применяется прямая коррекция ошибок (DVB добавляет 16 байт коррекции на пакет, ATSC – 20), поэтому многие повреждённые пакеты восстанавливаются ещё до того, как попадут в декодер. Именно такая устойчивость необходима для вещания и профессиональных контрибуционных каналов – фидов, передающих живой контент с площадки обратно в студию, – и именно поэтому формат MPEG-TS с PCR остаётся стандартом по умолчанию в этих системах. Файловые форматы вроде MP4 оптимизированы под хранение и произвольный доступ на надёжных носителях, тогда как transport stream ориентирован на выживание в условиях плохого канала в реальном времени. Разные задачи – разные решения. Подробности о контейнерах в обоих мирах рассмотрены в статье Звук в контейнерах: как MP4, MKV, fMP4, MPEG-TS несут аудио.

Есть ещё одна причина живучести PCR: протокол стриминга HLS, обеспечивающий значительную долю интернет-видео, изначально разбивал медиа на короткие сегменты MPEG-TS – каждый из них представляет собой миниатюрный транспортный поток со своим PCR. Даже когда HLS переходит к упаковке в фрагментированный MP4, общий формат с DASH, огромная база существующих HLS-реализований на основе TS-сегментов остаётся в эксплуатации, и каждый такой сегмент по-прежнему использует ту же модель часов 27 МГц, описанную в этой статье.

Числовой пример: диагностика медленного дрейфа

Соберём всё на реалистичном сбое. Станция мониторинга сообщает, что звук канала отстаёт от видео на 40 миллисекунд через два часа, хотя начинал в синхроне. Значения PTS и DTS выглядят чистыми. Где ошибка?

Симптом      : звук на 40 ms позже через 2 часа; в синхроне на старте
Скорость дрейфа : 40 ms ÷ 2 часа = 40 ms ÷ 7 200 с ≈ 5,6 микросекунды в секунду

Как ошибка частоты часов:
   5,6 µs/s ÷ 1 секунда = 5,6 ppm смещения часов

Внутри допустимых ±30 ppm? Да — декодер остаётся подстроенным,
   но смещения 5,6 ppm достаточно, чтобы накопить 40 ms за 2 часа.

Дрейф настолько мал, что декодер ни разу не потерял подстройку и не сбрасывал кадр – именно поэтому он прошёл быструю проверку. Однако устойчивое смещение в несколько ppm, накапливающееся секунда за секундой, – классический признак смещения частоты PCR на стороне кодера (мастер-часы идут чуть не точно на 27 МГц) или сетевого джиттера, смещающего восстановленные часы в одну сторону. Лечение не в PTS или DTS, которые изначально были верны; оно – в источнике часов кодера или в буфере подавления джиттера перед декодером. Метод и есть урок: переведите наблюдаемый дрейф в ошибку частоты часов, сравните её с допустимым бюджетом ±30 ppm – и сразу поймёте, гонитесь ли вы за потерей подстройки или за медленным накоплением. Один этот расчёт указывает на нужную половину конвейера.

Где здесь Фора Софт

Мы разрабатываем функции приёма, транскодирования, записи и воспроизведения для OTT, IPTV, систем видеонаблюдения и смежных с вещанием продуктов с 2005 года, и обработка PCR – это как раз то место, где конвейеры transport stream либо незаметно выигрывают, либо проигрывают. Типичная реальная проблема редко бывает экзотической: сервис принимает живой контрибуционный фид MPEG-TS, переупаковывает его для доставки, и на этапе перемультиплексирования пакеты сдвигаются без пересчёта PCR – и поток, который был чистым на входе, теперь дрейфует на выходе. Когда клиент сообщает, что канал был синхронизирован у источника, но теряет синхронность ниже по цепочке, мы в первую очередь проверяем этап пересчёта PCR, потому что именно там можно незаметно нарушить синхронизацию вещания, а показатели джиттера и дрейфа PCR в анализаторе потока рассказывают всю историю.

Главное

• PCR – это системные часы; PTS и DTS – временные метки, отсчитываемые от них.
• Он синхронизируется с мастер-часами 27 МГц: часы меток 90 кГц получаются делением на 300.
• PCR занимает 42 бита: 33-битная база с частотой 90 кГц плюс 9-битное расширение с частотой 27 МГц.
• PCR передаются в поле адаптации не реже чем раз в 100 мс (в DVB – не реже чем раз в 40 мс).
• Декодер настраивает PLL по PCR, чтобы восстановить системные часы STC.
• Джиттер, дрейф или смещение PCR вызывают рывки, зависания или медленный рассинхрон.

Что читать дальше

• PTS, DTS и метка времени элементарного потока
• RTP-метки времени, RTCP sender reports и синхронизация по NTP
• Звук в контейнерах: как MP4, MKV, fMP4, MPEG-TS несут аудио