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

Коротко

Transport stream несёт тысячи кадров аудио и видео в секунду, но ни одна их метка времени ничего не значит, пока плеер не знает, по каким часам она отмерена. Программные часы, PCR (program clock reference), и есть эти часы: периодический снимок мастер-часов кодера на 27 MHz, вставленный в поток, чтобы декодер мог восстановить те же часы у себя и воспроизвести каждый кадр в нужный момент. Они тикают 27 миллионов раз в секунду, хранятся как 42-битное число, разбитое на базу 90 kHz и более точный остаток 27 MHz, а декодер с помощью контура обратной связи подстраивает свои часы под них с точностью до ±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 MHz

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

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

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

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

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

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

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

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

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

Числовой пример делает разбиение наглядным. Пусть мастер-часы кодера натикали ровно 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 kHz. Расширение добавляет 123 тонких тика, которые база выразить не могла. Декодеру нужны обе половины, чтобы плотно подстроить часы; показание только по базе было бы точным лишь до 11 микросекунд, а этого мало, чтобы держать вещание стабильным часами.

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

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

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

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

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

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

Декодер приходит со свободно бегущим генератором 27 MHz, который близок к 27 MHz, но не точен – каждый кварц чуть быстрее или чуть медленнее. Его задача – подталкивать этот генератор, пока тот не совпадёт с часами кодера настолько точно, насколько это показывают приходящие 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 Hz вместо 27 000 000. Пока смещение остаётся внутри окна ±810 Hz (±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 – каждый из них миниатюрный transport stream со своим PCR. Даже когда HLS движется к упаковке в фрагментированный MP4, общей с DASH, огромная установленная база HLS на TS-сегментах всё ещё в строю, и каждый такой сегмент несёт ту же модель часов 27 MHz, что описана в этой статье.

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

Соберём всё на реалистичном сбое. Станция мониторинга сообщает, что звук канала отстаёт от видео на 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 MHz) или сетевого джиттера, смещающего восстановленные часы в одну сторону. Лечение не в PTS или DTS, которые никогда не были неверны; оно в источнике часов кодера или в буфере подавления джиттера перед декодером. Метод и есть урок: переведите наблюдаемый дрейф в ошибку частоты часов, сверьте её с бюджетом ±30 ppm – и сразу поймёте, гонитесь ли вы за потерей подстройки или за медленным накоплением. Один этот расчёт указывает на нужную половину конвейера.

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

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

Главное

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

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

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