8.6.3 Подстройка системных часов

Для правильной интерпретации меток времени декодер должен иметь свое собственное системное время, причем должна быть обеспечена подстройка «часов» декодера под время «часов» кодера. Для этого текущее время кодера регулярно передается декодеру. Системное время каждой программы отсчитывается в единицах периода колебаний с частотой 27МГц. Отсчеты этого времени передаются в программном потоке в одном из полей заголовка блока (они называются SCR – System Clock Reference) не реже, чем через 0,7 секунды. В транспортном потоке могут переноситься данные нескольких телевизионных программ, каждая из которых может иметь свое независимое время, называемое программным. Отсчеты программного времени PCR (Program Clock Reference) переносятся в поле адаптации транспортного пакета с соответствующим идентификатором PID (обычно он совпадает с идентификатором элементарного потока видеоданных). Метки PCR должны появляться не реже, чем раз в 0,1 секунды. Несмотря на разницу в названиях, основные функции PCR и SCR совпадают. Принцип синхронизации декодера с кодером путем использования отсчетов программного времени иллюстрирует рисунок 8.11.

Рисунок 8.11 – Синхронизация декодера с кодером

8.6.4 Метки декодирования и предъявления

Метки времени, ассоциируемые с блоками доступа, выражаются в единицах времени периода колебаний с частотой 90кГц, полученных путем деления частоты 27МГц. Эти метки бывают двух типов: метки времени представления PTS и метки времени декодирования DTS. Метки PTS определяют момент времени, в который декодированный блок доступа (кодированное изображение или фрагмент звукового сопровождения) должен быть предъявлен зрителю. Для всех элементарных потоков, кроме видео, PTS – это единственные метки, которые необходимы. Для потока видеоданных необходимы метки времени декодирования DTS, определяющие моменты времени, в которые блоки доступа извлекаются из буфера и декодируются, но не предъявляются зрителю. Декодированные изображения временно хранятся и предъявляются в боле позднее время, назначаемое метками PTS. Метки DTS необходимы изображениям типа I и P, которые должны декодироваться раньше, чем B-изображения, для кодирования которых I и P изображения использовались в качестве опорных. Метки DTS не появляются в одиночку, а должны сопровождаться метками PTS.

Метки не должны сопровождать каждый блок доступа. Ограничение, определяемое стандартом MPEG-2, заключается в том, чтобы в элементарных потоках видео и звука метки должны появляться не реже, чем раз в 0,7 секунды. Метки переносятся в заголовках PES-пакетов. Если метка сопровождает блок доступа, то она появляется в заголовке PES-пакета, в котором этот блок доступа начинается.

8.7 Коммутация транспортных потоков mpeg-2

При производстве аналоговых ТВ программ результирующая последовательность кадров комбинируется из сигналов многих источников изображения и звука. Это выполняется с помощью звуковых и видео­коммутаторов или микшеров. В системе доставки программ коммута­ция источников требуется повсюду, начиная с редактирования содер­жания, получаемого от различных источников в виде камер и средств записи в процессе доставки программы в конечный пункт передачи. В этом пункте следует предусматривать необходимость введения программ местного содержания (например, сигналов опознавания станции, ком­мерческих программ, местных программ новостей и т.п.) в поток дан­ных для сети или ведомственного источника программ.

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

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

В стандарт MPEG-2 была введена возможность осуществления ком­мутирующей функции. Коммутация в терминалах MPEG называется склеиванием. Возможны два вида склеивания: безразрывное и с прерыванием.

Безразрывное склеивание не вызывает нарушений непрерывности декодирования. Это означает, что время декодирования первого дос­тупного фрагмента (кодированное изображение или кадр кодированной звуковой информации) нового потока будет определяться тем же вре­менным кодом, как и следующий доступный фрагмент старого потока, как если бы не было склеивания. Как и при любой операции по редак­тированию, для получения приемлемых результатов необходимо ре­шить задачи временной синхронизации и относительного времени за­держки звука и изображения. Несмотря на то, что синтаксис стандарта MPEG-2 обеспечивает возможность склеивания потоков, его весьма об­щий характер не гарантирует сопряжения потоков или взаимного об­мена данными между ними. Поэтому традиционные задачи коммута­ции следует дополнить управлением буферной памятью данных, идентификацией точек склеивания и другими практическими стандар­тами, которые необходимо разработать в будущем.

Переключения с прерываниями вызывают нарушения непрерывности процесса декодирования. Это означает, что время декодирования фрагмента, введенного в новый поток данных, не равно времени, кото­рое было бы в случае безразрывного декодирования. Другим источни­ком возможного нарушения непрерывности процесса является набор идентификаторов PID, соответствующий различным цифровым пото­кам данных. Известно, что таблица структуры программы РМТ для программного транспортного потока обеспечивает информацию PID, описывающую, какой поток видеоданных и соответствующий поток звуковых данных запрашивается для включения в состав программы. Цифровые потоки, поступающие из какой-либо аппаратуры видеозапи­си, программных сетей, коммерческих и местных студий и других ис­точников, будут, вероятно, иметь свои индивидуальные PID. Коммута­ция (склеивание) этих различных источников при монтаже общей программы вещания может привести к изменениям PID, вызывающим прерывание работы декодера в связи с поиском PID, соответствующих данной таблице РМТ, или приемом новой таблицы РМТ. На практике цифровой поток каждой программы вещания должен соответствовать PID до и после склеивания, чтобы гарантировать непрерывное опозна­вание пакетов.