Цифровой сигнал непосредственно с выхода кодера МРЕG-2 называется «сырым» (необработанным) элементарным потоком (ES) и представляет собой бесконечную последовательность видео- или звукоданных в том порядке, как они появляются на выходе в процессе кодирования. Он не содержит необходимой информации для идентификации потока, для его синхронизации с другими потоками и не может непосредственно использоваться для организации вещания или других служб.
Для дальнейшего использования элементарные потоки переформировывают в пакетированные элементарные потоки (PES), в которых данные разделены на пакеты удобного размера с заголовками, содержащими необходимую информацию о потоках и синхронизации. В зависимости от приложений длина PES-пакета может составлять от единиц до 64 килобайт. Обычно пакет содержит одну единицу воспроизведения данных определенного типа. Единица воспроизведения видеопотока - один видеокадр, звукопотока - один звуковой кадр AES/EBU. Заголовок (рис. 1.1) начинается со стартового кода длиной 3 байта и однобайтового идентификатора потока, показывающего вид информации (видео, аудио, вспомогательные данные) и параметры кодирования.
Рисунок 1.1 Структура PES-пакета
Следующие 2 байта - это указатель длины пакета, он показывает число байтов в пакете. Далее следуют 12 флагов, несущих сведения о свойствах цифрового потока. Они сообщают информацию о скремблировании, о приоритете пакета, условия авторского права, тип временной метки (присутствует ли только PTS или PTS и DTS), наличие или отсутствие определенных полей (поля скорости потока, режима DSM, информации о дополнительных копиях, полей расширения и др.). Опционные поля входят в состав заголовка, если соответствующие флаги установлены на «1». Поле режима DSM (цифровой видеозаписи) содержит биты, управляющие движением ленты (перемотка, стон-кадр, замедленное воспроизведение) и другими видеоэффектами; информация о дополнительных копиях необходима для решения вопросов авторского права. Поле длины заголовка указывает размер заголовка в байтах.
Привязка PES-сборки к определенному моменту времени осуществляется периодическим помещением в заголовок ссылок на системные часы (SCR) - 33-битового числа, отсчитывающего периоды опорной частоты 90 кГц. Число периодов частоты 90 кГц подсчитывается многоразрядным счетчиком и вводится в заголовок потока. Нетрудно подсчитать, что полный цикл счетчика завершается за 26 с небольшим часов.
Рисунок 1.2 Восстановление тактовой частоты в приемнике MPEG-2 по меткам SCR
Основная задача, решаемая системными часами, - обеспечение синхронизации тактовых частот кодера и декодера. Она решается с помощью схемы дискретной автоподстройки частоты в декодере (рис. 1.2).
Частота местного генератора подсчитывается с помощью многоразрядного счетчика и периодически сравнивается с приходящими от кодера значениями SCR. Выходной сигнал компаратора, пропорциональный разности двух чисел, управляет через ФНЧ частотой генератора и корректирует ее в соответствии со знаком разности. На передающей стороне точность поддержания частоты должна быть не хуже 3·10-5.
При двунаправленном кодировании, как отмечалось, порядок следования и порядок передачи Р- и В-кадров не совпадают, и для синхронизации используются два вида временных меток. Временная метка декодирования (DTS) указывает время, когда видеокадр должен быть декодирован, а временная метка воспроизведения (PTS) - момент времени, когда он должен появиться на выходе декодера. Если, например, принимается последовательность IPBB декодер декодирует I-кадр и запоминает его, в следующий момент он декодирует P-кадр и выдает на выход I-кадр, затем вычисляет и выдает кадр В1, затем В2 и только после этого Р1 (рис. 1.3).
Рисунок 1.3 Восстановление порядка следования видеокадров по меткам DTS и PTS
Временные метки PTS и DTS формируются по тому же принципу, что и ссылка на системные часы (SCR).
Привязка к временным меткам позволяет обеспечить одинаковую задержку кодера и декодера для всех составляющих программы при их независимой передаче с разбивкой на пакеты, синхронизировать элементарные потоки видео и аудио и образовать из них ТВ программу. Декодер может интерполировать временные промежутки между двумя появлениями временной метки, поэтому нет необходимости размещать метку в каждой единице воспроизведения.
При формировании единого потока данных стандарт MPEG-2 предусматривает две формы такого потока: программный (PS) и транспортный (TS).
Программный поток ПП (PS). Структура PS включает пачки (pack), содержащие один или несколько PES-пакетов и заголовок со ссылкой на системные часы (SCR) (рис. 1.4). В потоке может быть до 16 видео и до 32 звуковых потоков, но все они считаются компонентами одной программы, так как имеют общую временную базу (единый генератор тактовой частоты).
Рисунок 1.4 Структура программного потока MPEG-2
Транспортный поток ТП (TS) представляет собой более высокий уровень организации данных. В TS пакетированные элементарные потоки, принадлежащие разным программам, переносятся в различных транспортных пакетах небольшой длины, снабженных кодозащитой для передачи в каналах с ошибками, в частности, для вещания. Один транспортный поток может переносить несколько программ, не связанных единой временной базой, каждая из нескольких компонентов. Передача оказывается, по сути дела, асинхронным и потому не может управляться единым синхронизирующим сигналом. Рассмотрим, как решены вопросы синхронизации в транспортном потоке МРЕG-2.
Пакеты TS имеют фиксированную длину 188 байт, из которых 4 байта выделяются на заголовок и 184 байта - на полезные данные. Это могут быть видео- или звукоданные, данные пользователя или пустые байты (11111111), называемые стаффингом. Каждый пакет переносит данные только одного вида. Размер пакета выбран для совместимости с широко применяемым на сетях связи стандартом асинхронной передачи данных АТМ. Ячейка ATM имеет длину 53 байта, из которых полезных - 47 байт (с учетом 1 байта на уровень адаптации). Один пакет МРЕG-2 длиной 188 байт упаковывается в 4 пакета АТМ. Структура заголовка показана на рис. 1.5.
Рисунок 1.5 Структура заголовка пакета транспортного потока MPEG-2
Первый байт - байт синхронизации - содержит зарезервированное кодовое число 0×47, легко опознаваемое демультиплексором. Далее идут три однобитовых флага (ошибки передачи, начала PES-пакета и приоритетной передачи) и 13-битовьтй идентификатор типа пакета PID, указывающий на принадлежность пакета тому или иному потоку данных. PID служит основным признаком, по которому демультиплексор сортирует приходящие пакеты на приемной стороне. Из общего числа 8192 возможных значений PID 16 выделены на общесистемные цели, номер 8191 (0×1FFF) закреплен за стаффинговыми байтами, остальные могут назначаться пользователями произвольно для отдельных компонент своих программ.
Передача информации пакетами фиксированной длины и система идентификаторов имеют свои преимущества. Пропускная способность в этом случае используется в максимальной степени и может динамически перераспределяться между программами. Можно добавлять новые PES или удалять ненужные, не меняя в целом структуру потока. Для извлечения необходимой информации декодеру не нужно знать детальную структуру всего потока, достаточно указать только PID, который всегда находится в заголовке на одном и том же месте.
Еще один байт в заголовке содержит три необходимых указателя:
- 2-битовый указатель скремблирования TS - свидетельствует о наличии или отсутствии скремблирования TS;
- 2-битовый индикатор наличия полей адаптации в нагрузке пакета.
Поле адаптации занимает часть области полезных данных и служит для ввода управляющих и вспомогательных сигналов, передаваемых не в каждом пакете. В частности, в полях адаптации передаются таблицы программно-зависимой информации (PSI) и сигналы синхронизации. Поле адаптации может также использоваться для передачи данных пользователя, в этом случае оно разбивается на секции.
Значение указателя наличия полей адаптации 0×1 означает, что поле адаптации отсутствует, и в пакете передаются данные видео или звука; 0×2 присваивается пакету, в котором часть области полезных данных занимает поле адаптации, остальное занято стаффингом; индикатор, установленный на 0×3, свидетельствует об одновременном наличии и поля адаптации, и полезных данных. Отметим, что заголовок пакета и поле адаптации не скремблируются.
4-битный счетчик непрерывности пакетов увеличивает свое значение на единицу при поступлении каждого следующего пакета с данным PID и обнуляется после каждого 15-го пакета. Он позволяет декодеру обнаруживать потерю пакета и принимать меры по его замене.
Область полезных данных транспортного пакета значительно меньше, чем обычная длина PES-пакета, поэтому последний для укладки в пакеты TS должен разрезаться. Стандарт определяет, что первый байт PES-пакета должен обязательно совпадать с первым байтом области полезных данных, а конец PES-пакета - с концом одного из последующих транспортных пакетов. Незаполненные начальные байты этого последнего пакета дополняются пустыми байтами.
Если в пакете присутствует поле адаптации, оно имеет структуру, показанную на рис. 1.6. Первый байт указывает длину поля, затем следуют три однобитовых указателя - непрерывности, случайного доступа и приоритета элементарного потока. Первый указатель свидетельствует о непрерывности счета времени во временных метках и необходим на приеме для мониторинга TS. Он устанавливается в «1», если на передающей стороне изменена база отсчета времени, например, гладко введена другая программа с иным PCR.
Рисунок 1.6 Структура поля адаптации транспортного потока
Если в данном поле адаптации передается PCR, об этом свидетельствует однобитовый флаг PCR. Метка PCR занимает 48 битов, в том числе 33 бита собственно PCR, 6 битов зарезервировано для будущих применений и 9 битов занимает поле расширения PCR. В поле расширения ведется счет импульсов тактовой частоты 27 МГц. Как только их число достигает 300, поле обнуляется, и значение PCR увеличивается на единицу. Так обеспечивается совместимость с МРЕG-1, где отсчет времени ведется в периодах тактового генератора 90 кГц. Такой же формат имеет метка Исходной PCR (OPCR), передаваемой вместе с программой, заимствованной из другого транспортного потока. В отличие от PCR, значение OPCR не изменяется в процессе передачи. Оно может использоваться, например, при записи и воспроизведении программы.
Еще один флаг, splice_countdown, указывает число пакетов с тем же PID в транспортном потоке, оставшихся до точки гладкого входа в поток (например, для ввода рекламы или местных программ).
Оставшуюся часть поля адаптации могут занимать либо служебные данные, либо данные пользователя, либо расширения поля адаптации, на что указывают соответствующие флаги. Формат данных пользователя включает однобайтовый указатель длины поля и собственно поле данных, которые в этом случае вводятся в так называемые секции транспортного потока.
