что такое pmt в кабельном телевидении

Транспортный поток MPEG TS: основные понятия

В данной статье мы рассмотрим основные понятия для MPEG TS, который в настоящее время является стандартом и используется в качестве канального уровня в большинстве систем наземного цифрового телевизионного вещания, использующих передачу пакетных данных в транспортных потоках.

Принимая во внимание то, что структура транспортного потока опирается на некоторые фундаментальные концепции вещания, мы кратко рассмотрим их перед тем, как приступить к MPEG TS.

Вещание и необходимость в сервисах

Большинство вещательных сетей работает, как то, что мы можем назвать однонаправленной сетевой системой (вещательная сеть). Данная структура реализуется таким способом не потому, что невозможно организовать обратный канал с любого устройства в сети, а потому, что конечному пользователю будет довольно затратно приобрести устройство, обладающее необходимыми возможностями. Данная структура делает передачу данных через крупную сеть связи дешевле.

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

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

Что такое MPEG TS?

MPEG TS определяет канальный уровень, а также уровни данных сервисной информации (с точки зрения модели OSI, MPEG TS охватывает уровни от канального до транспортного). Вся передача данных выполняется с использованием пакетов фиксированного размера, известных как «TS-пакеты». TS пакеты – это базовые кирпичики, в которых передаются все данные канала, а кроме того, они позволяют реализовать временное мультиплексирование, необходимое для передачи.

Структура TS пакета изображена на рисунке ниже:

Структура TS пакета

Любая передача в канале осуществляется путем отправки одного TS пакета за другим (минимальный блок передачи данных составляет 184 байта). Как было показано на рисунке выше, пакет состоит из двух частей:

Полезная нагрузка – это просто двоичные данные для верхних уровней; уровней, которые выходят за рамки темы данной статьи.

4 байта заголовка разделены на несколько секций:

В этой таблице наиболее важными полями являются PID и счетчик непрерывности. В следующем разделе мы кратко рассмотрим их.

Мультиплексирование данных

В начале статьи я упомянул, что одной из ключевых особенностей MPEG TS является возможность мультиплексирования данных. Но как достигается это волшебство? Ну, всё связано с PID.

Значение PID является ключом, который используется в качестве идентификатора типа данных, которые идут через поток. Это означает, что я могу выбрать PID для идентификации видеосигнала, другой PID для идентификации звука для этого видео и, наконец, третий PID, который связывает видео и звук (также известный как таблица структуры программы или «Program Map Table», PMT). Со всеми этими данными приемник может реально показать видео и связанный с ним звук, если он знает, как обнаружить PMT пакеты. И это всё? Конечно, нет! Таким же образом я могу создать множество пар пакетов видео и звука с их PMT и передавать всех их через тот же канал, что дает нам возможность создать мультиплекс из нескольких ТВ каналов, использующих один канал передачи данных! Конечно, приемнику будет нужен четвертый тип пакета, чтобы узнать, какие программы идут в потоке: также известный как таблица программ или «Program Association Table», PAT.

На следующем рисунке приведена идея мультиплексирования программ:

Мультиплексирование программ в MPEG TS

На диаграмме выше, у нас три ТВ канала передаются в одном потоке. Все показанные таблицы являются более или менее связанными группами данных. Обратите внимание, что в этом примере, если приемник хочет знать все программы в канале, ему необходимо просто прочитать PAT (которая хоть в данном примере и передается в одном пакете, но это не всегда так делается). Таким образом, приемник знает все программы, которые есть в наличии, и если он хочет настроиться на одну из них, ему просто необходимо прочитать PMT пакет и начать фильтровать все пакеты с необходимыми видео и аудио, отклоняя видео и звук ненастроенных каналов. В заключение отметим, что PID позволяет мультиплексировать данные, а также предоставляет приемнику механизм фильтрации данных, которые необходимо использовать.

MPTS пакеты несут только 184 байта данных полезной нагрузки. Любой человек, который когда-либо использовал видео или аудио файлы, знает, что этот объем данных довольно мал, чтобы переносить какой-либо объем видео/аудио данных. Таким образом, транспортный уровень отвечает за перенос этой информации (уровень выше MPTS), но всё же мы должны знать, как собрать данные полезной нагрузки, и, самое главное, знать, как определить, когда данные полезной нагрузки были потеряны (нам необходима способность обнаружения случаев потери пакета данных!). Механизм обнаружения потери данных предоставляется счетчиком непрерывности.

Счетчик непрерывности (Continuity counter, CC) – это счетчик от 0 до 15, связанный с PID (CC относится только к PID, в котором он был передан). Он увеличивается на единицу каждый раз, когда в поток передается пакет связанного с ним PID. При таком подходе обнаружение потери пакета осуществляется путем анализа потерь значений в циклическом счетчике в принятых пакетах. Таким образом, если в циклическом счетчике потеряется значение, уровень TS сможет сообщить своему верхнему уровню, что он потерял часть переданных данных, позволяя верхнему уровню выбрать действие, которое необходимо выполнить в этом случае (в большинстве случаев происходит отбрасывание поврежденной информации).

Следующие значения CC показывают пример потери данных, которая обнаруживается благодаря нарушению в последовательности значений счетчика непрерывности (для примера мы допустим, что 4 видео TS пакета представляют собой один видео кадр, и, если кадр будет потерян, то декодер выведет на экран сообщение «No signal!»). Обратите внимание, что CC является циклическим.

Счетчик непрерывности (Continuity counter, CC)

Вот и всё! Надеюсь, статья оказалась вам полезной. Оставляйте комментарии!

Источник

Структура транспортного потока MPEG

Что такое формат MPEG?. В состав чипсета MPEG энкодера в действительности входит аудио-энкодер и видео-энкодер. Видео-энкодер производит поток MPEG видеоданных, аудио-энкодер производит поток MPEG аудио данных. Эти потоки называются «элементарные MPEG потоки» (MPEG Elementary Streams или кратко ES). Оба аудио и видео элементарные (ES) потоки разбиты на пакеты (например, для видео-декодера пакетом может быть кадр изображения). Результирующие потоки называются MPEG-пакетизированные элементарные потоки (MPEG Packetized Elementary Streams или кратко PES), которые, в свою очередь, мультиплексирует входящий в состав энкодера мультиплексер транспортного потока (Transport Stream Multiplexer). Мультиплексер производит транспортный поток (Transport Stream, TS), который содержит аудио и видео PES потоки вместе с данными синхронизации.

Аудио-данные, видео-данные и данные синхронизации на выходе энкодера вместе уже являются «программой». Данные синхронизации определяют скорость передачи данных и необходимы впоследствии для точного декодирования аудио- и видео-данных программы.

Транспортный поток состоит из TS пакетов длиной 188 байт. Каждый из TS пакетов содержит заголовок и полезную нагрузку данных, например, аудио-, видео-данные, телетекст. Заголовок каждого пакета содержит информацию о содержании этого пакета и является важным для демультиплексера TS. Заголовок начинается со слова синхронизации (47 в hex формате), используемого для распознавания начала пакета. Далее следуют два байта, которые содержат некоторые необходимые флаги (flags) и идентификатор пакета (PID).

PID-код содержит важнейшую информацию о пакете и может быть в диапазоне от 0 до 8191 и используется для идентификации содержания пакета. Например, транспортный поток может содержать пакетизированные элементарные видео-потоки (PES) в пакетах с PID 100, аудио-PES в пакетах с PID 101 и данные синхронизации, принадлежащие к этим потокам в пакетах с PID 102. Но для вторых видео-PES данные синхронизации могут быть в пакетах с PID 200. Итак, в одном транспортном потоке может передаваться много элементарных потоков PES. Но как декодер узнает, какие пакеты (PID-коды) принадлежат определенной программе? Именно для этой цели транспортный поток содержит сервисную информацию (Service Information, SI).

Сервисная информация содержится в нескольких специальных таблицах. Эти таблицы передаются как отдельные потоки, подобно видео- и аудио-потокам. Большинство потоков таблиц сервисной информации имеют фиксированный известный ID, так что декодер всегда может найти их. Ниже приведены наиболее важные SI таблицы с их PID – кодами.

Наиболее важными являются PAT и PMT таблицы. Таблица PAT содержит названия всех программ в данном потоке и пакетные идентификаторы (PID-коды) для PMT этих программ (таблиц структуры программ). Если ресивером принимается неизвестный транспортный поток, то он вначале дожидается TS пакетов с PID=0, содержащих таблицу PAT, затем, в свою очередь, PAT таблица сообщает ресиверу коды PID таблицы структуры программ PMT в этом потоке.

Другие таблицы сервисной информации SI дают дополнительную информацию о вещателе, транспортном потоке, программах и о событиях в программах.

Кроме таблиц PAT и РМТ, существует еще одна чрезвычайно важная таблица – таблица условного доступа (Conditional Access Table, CAT), которая передается при PID = 0001, когда одна или более программ уплотненного потока скремблируются (шифруются).

Для мониторинга содержания транспортного потока используются так называемые анализаторы транспортного потока, которые позволяют оператору в процессе настройки мультиплексоров фильтровать ненужные сервисы. Для инжекции в транспортный поток необходимой оператору сервисной информации используются PSI/SI генераторы. Поскольку сервисная информация передается в TS как последовательная серия иерархических таблиц, PSI/SI генераторы называют ещё «карусельными» генераторами.

Если у Вас возникли какие либо вопросы, обращайтесь по E-mail: или по тел.: (495) 221-81-88. Наши специалисты дадут Вам полную исчерпывающую информацию по любому из интересующих Вас вопросов.

Источник

Что такое pmt в кабельном телевидении

Данный материал предназначен для кабельных операторов, которые задумываются о целесообразности перехода из аналога в DVB-C.
Сразу оговоримся, что ответа на вопрос, стоит или не стоит переходить, в статье не будет. Наша задача – обрисовать варианты реализации DVB вещания, круг проблем, которые при этом предстоит решить, и дать базовые теоретические и практические сведения, которые могут быть полезны начинающему цифровому оператору.
В материале, который будет разбит на три-четыре номера, мы планируем рассмотреть следующие вопросы:

1. Краткий обзор существующих систем компрессии (без технических подробностей).
2. Структура потока MPEG-2 TS.
3. Состав служебных таблиц, дескрипторы, передача субтитров и информации из КГИ.
4. Помехозащитное кодирование и модуляция.
5. Состав головной станции.
6. Четыре варианта организации ГС для ретрансляции.
7. Расчеты потоков для вариантов с ремультиплексированием и транскодированием.
8. Характеристики качества цифрового сигнала (BER, MER, Eb/No, EVM констеляционная диаграмма).
9. Возможное применение DVB-T в кабеле.
10. Типы систем доступа и критерии их выбора.
11. Краткие сведения об интерфейсах для цифрового ТВ, в том числе для ТВЧ сигналов.
12. Требования к пассивному и активному оборудованию, пригодному для QAM сигнала.
Это ориентировочный план, который может быть немного откорректирован в процессе написания.

В этой статье рассмотрены вопросы 1-3 – разные форматы компрессии, структура транспортного потока MPEG-2, а также передаваемая в потоке служебная информация.
По ходу текста мы будем приводить ссылки на первоисточники (стандарты) и на источники, в которых соответствующий вопрос рассмотрен более детально. В качестве основного источника мы используем книгу Б.А. Локшина «Цифровое вещание от студии к телезрителю», которую рекомендуем всем желающим более глубоко вникнуть в рассматриваемые вопросы. В остальных случаях приведены ссылки на интернет-сайты и периодические издания.

Системы компрессии
Наиболее распространенной на сегодняшний день системой сжатия является MPEG-2. Сразу отметим, что стандарт MPEG-2 можно разбить на две части. В одной рассматриваются непосредственно принципы компрессии аудиовидеосигналов, а в другой – транспортный формат, предназначенный для передачи ТВ сигналов, компрессированных в MPEG-2 или других форматах.
Компрессия видео- и аудиосигналов основана на устранении информационной избыточности. Для этой цели в рамках каждого формата используются единые принципы, но реализованы они могут быть по-разному и в разном объеме. Потенциал механизмов, заложенных в формате, реализуется очень постепенно. Так, для MPEG-2 этот процесс продолжается уже десять лет. Если первые кодеры позволяли сжать ТВ сигнал в приличном качестве до скорости 6 Мбит/с, то современные сжимают его примерно до 3-3,5 Мбит/с. Цифры справедливы для кодирования программ с насыщенным динамичным изображением и при сохранении качества, не имеющего видимых погрешностей. Сегодня некоторые компании декларируют компрессию до уровня менее 2 Мбит/с, но на практике такие скорости в пересчете на канал можно встретить только в пакетах, сформированных с применениям статистического мультиплексирования. То есть средняя скорость, приходящаяся на один канал передаваемого пакета, действительно может быть меньше 2 Мбит/с. Но это не означает, что с такой скоростью может быть скомпрессирован любой сюжет. Разумеется, не все современные кодеры демонстрируют одинаковую степень сжатия. Предельные возможности кодера определяются чипсетом, реализующим компрессию. Если в аппарате используется устаревший чипсет, то никакие ухищрения программистов не позволят добиться впечатляющих результатов.
Сегодня потенциал механизмов компрессии, заложенных в MPEG-2, практически исчерпан. Эта одна из причин, по которой производители ратуют за применение более современных стандартов. Самый актуальный из них – MPEG-4 Part10 или AVC (Advanced Video Coding), известный и как H.264. Два разных названия у этого стандарта появились потому, что он разрабатывался совместно двумя группами MPEG и VCEG, которые организованы в рамках разных стандартизирующих организаций.
В рамках ISO/IEC (MPEG) это десятая часть стандарта MPEG-4, определяющая механизмы продвинутого кодирования видео2. Первый вариант видеокомпрессии, принятый в рамках MPEG-4, описан во второй части стандарта. По своим механизмам он значительно проще, чем попавший в часть 10, и требует менее сложного программирования и менее производительных процессоров. Стандарт компрессии MPEG-4 Part2 используется в интернет-среде3, где его сразу оценили за хорошую масштабируемость, то есть за возможность сжимать видео до очень низких скоростей, в основном, за счет снижения разрешения и частоты кадров. Что же касается вещательных сетей, то к моменту, когда MPEG-2 был объявлен морально устаревшим, уже появилась десятая часть MPEG-4, которая и была принята к реализации. В качестве основного алгоритма для кодирования звукового сопровождения в MPEG-4 принят AAC. С незначительными улучшениями он был перенесен туда из MPEG-2, в котором присутствует в качестве продвинутой опции.
Переход к MPEG-4 связан не только с логическим завершением развития MPEG-2. Он также приурочен к запуску трансляций в ТВЧ. Переход к ТВЧ в любом случае требует смены кодеров и абонентских приемников, поэтому логично совместить смену форматов. К тому же, для передач в ТВЧ требуется в два-четыре раза больше полосы, чем для ТВ стандартной четкости4, и у спутниковых операторов, запускающих пакеты с ТВЧ, появилась необходимость компенсировать увеличившийся объем видеоинформации ее более эффективной компрессией. MPEG-4 уже сегодня позволяет формировать НЧ сигнал в полосе 7-8 Мбит/с.
Отметим, что для более эффективного использования транспортного ресурса спутниковых сетей был разработан новый стандарт спутниковой передачи DVB-S2, предусматривающий иную структуру транспортного потока, более эффективные методы помехозащитного кодирования и другие схемы модуляции5. Совместное использование компрессии MPEG-4 и транспортного формата DVB-S2 уже сегодня практически позволяет компенсировать переход на ТВЧ в плане требуемого транспортного ресурса; разумеется, если абстрагироваться от не слишком высокого качества пережатых ТВЧ трансляций. Совместное использование MPEG-4 и DVB-S2 во всех европейских спутниковых проектах привело к тому, что иногда транспортные структуры DVB-S2 начинают воспринимать как часть стандарта MPEG-4. Но для этого нет никаких оснований. ТВ потоки в формате MPEG-4 с таким же успехом могут передаваться с помощью любого другого стандарта, а транспортная структура DVB-S2 – переносить сигналы, компрессированные в любом другом формате.
По механизмам компрессии MPEG 4/AVC гораздо сложнее MPEG-2, хотя большая часть MPEG-2 включена в него как частный случай. Так, например, MPEG-2 в GOP (группа совместно кодируемых кадров) использует один опорный I-кадр (кодируемый без использования информации о других кадрах), а в AVC их может быть множество. Поэтому процессорная мощность, требующаяся для обработки потоков видео в соответствии с новым стандартом, гораздо выше, что особенно критично для бытовых декодеров, а точнее для их стоимости.
Желающих ознакомиться с базовыми возможностями компрессии MPEG-4/AVC можем адресовать, например, к Википедии http://en.wikipedia.org/wiki/H.264. Отметим только, что одна из основных идей, заложенных в MPEG-4, пока не реализована. Это идея разбиения кадра на сцену (фон) и объекты, которые кодируются отдельно, а приемнику передается информация об изменении каждого из объектов. Механизм такого многослойного кодирования актуален, в первую очередь, для систем интерактивного телевидения, в котором объекты могут, на компьютерный манер, использоваться для управления событиями. Пока что не очень понятно, насколько этот механизм востребован, и если да, то когда его реализуют на практике. Ясно только, что если этот механизм начнет массово использоваться в кодерах, то подавляющее большинство сегодняшних приставок с поддержкой MPEG-4 придется поменять. Но даже если не принимать во внимание этот нюанс, то говорить о существовании горизонтального рынка для оборудования с поддержкой MPEG-4 пока можно только с натяжкой. Горизонтальный рынок предполагает, что в рамках одного проекта можно использовать оборудование разных производителей, не ожидая системных подвохов. Он также предполагает примерно одинаковое качество работы декодеров, в том числе бытовых. Эти условия уже давно соблюдаются в отношении аппаратуры с MPEG-2, но не всегда для аналогичного оборудования с MPEG-4. Уточним, что речь идет о приеме обычных трансляций, а не интерактивных услуг, то есть лишь о декодировании сигнала MPEG-4 и стандартного для DVB трансляций набора функций. Сегодня существуют уже более или менее проработанные чипсеты, как для кодеров, так и для приемников, в том числе бытовых. В то же время практики отмечают, что в некоторых приставках наблюдается неполная реализация некоторых, не очень критичных алгоритмов, уже используемых в сегодняшних кодеров, что приводит к ухудшению качества восстановленного сигнала. А разработчики оборудования отмечают плохую проработку программной базы некоторых чипсетов, выпущенных на рынок. Серьезной проблемой является также слабая нагрузочная способность чипсетов для бытовых декодеров. Они могут корректно выполнять заложенные задачи поодиночке, но при определенном уровне функциональной загрузки они просто перегружаются и зависают. Это, несомненно, временные явления, но пока они не позволят считать оборудование MPEG-4 полностью отработанным. Тем не менее, появившиеся в марте «правила применения цифровых систем передачи телевизионного и звукового вещания» «обязали» все цифровое оборудование России поддерживать стандарт MPEG-4. Видимо, таким необычным способом в Министерстве информационных технологий попытались придать стандарту MPEG-4 статус официального, благо до сих пор ни в каких стандартизирующих документах он не упоминался. Содержание этого документа, разумеется, не следует рассматривать как запрет применения MPEG-2, но можно расценить как официальную ориентацию на постепенный переход к MPEG-4, который, видимо, будет поддерживаться государственными проектами.
Один пример уже налицо – спутниковый пакет федеральных каналов, запущенный в MPEG-4 ФГУП «Космическая связь» со спутника «Экспресс-AM1», предназначен для ретрансляции цифровыми эфирными сетями. А если добавить к этому, что во всех западноевропейских спутниковых ТВЧ каналах, равно как и в ТВЧ пакете от «НТВ-Плюс», также используется видеокомпрессия MPEG-4 /AVC, то перспективы широкого распространения стандарта просматриваются достаточно ясно.
Параллельно с MPEG-4 развиваются еще два стандарта – VC-1 (Video Codec) и AVS (Audio Video Standard). VC-1 – это разработка Microsoft. Он появился несколько лет назад одновременно с H.264 и поначалу рассматривался как его серьезный конкурент. Все ведущие производители поспешили анонсировать разработку кодеров обоих форматов. Но в итоге европейский рынок отдал предпочтение MPEG-4, и VC-1, по нашим наблюдениям, используется только в некоторых сетях IPTV, выбравших middleware Microsoft TV. И то не везде, например, в проекте «Корбина-Телеком» пока используется компрессия MPEG-2, и в перспективе возможна миграция к MPEG-4.
Разработка AVS инициирована правительством Китая. Этот стандарт описывает не только методы видео- и аудиокомпрессии, но также и систему контроля копирования контента. Оборудование с поддержкой AVS только начинает появляться (сам стандарт должен быть принят в октябре), и прогнозировать скорость, масштабы и географию его распространения мы не беремся. Судя по опубликованным механизмам компрессии, равно как и по отзывам инженеров, работавших с реальной аппаратурой, эти форматы представляют собой несколько упрощенные варианты H.264.
Несмотря на различное происхождение стандартов, причина их появления, по всей видимости, одна – нежелание оплачивать лицензию за использование MPEG стандарта.
В заключение скажем, что компрессирование компонентов потоков может выполняться с постоянной или переменной скоростью. Современные кодеры (кроме бюджетных) поддерживают оба режима. Кодирование с постоянной скоростью (CBR) оптимально для случаев, когда программы передаются поодиночке. А кодирование с переменной скоростью (VBR) используется совместно со статистическим мультиплексированием, позволяющим динамически перераспределять фиксированную ширину потока между мультиплексируемыми программами. VBR также актуально для сетей доступа на базе Ethernet.

Транспортный поток
Другая часть стандарта MPEG-2 описывает возможные структуры потока для передачи ТВ программы, компрессированной в MPEG-26.

Виды пакетов
Для последующего применения компрессированные видео- и аудиопотоки (и тех, и других в рамках одной программы может быть несколько) разбиваются на фрагменты переменной длины, которые заключаются в отдельные пакеты. Фрагмент видеопотока обычно включает один кадр, а фрагмент аудио потока – 24 мс звуковой последовательности. Каждый пакет имеет заголовок с информацией о времени его декодирования и воспроизведения и основную часть с аудио- или видеофрагментом. В результате появляются пакетизированные элементарные потоки PES (Packetized Elementary Stream). Для целей студийной обработки программ эти потоки могут объединяться в программные потоки, которые мы здесь рассматривать не будем.
Другая форма последующего объединения PES – транспортный поток MPEG-2 TS. Он формируется для передачи одной или нескольких ТВ и радиопрограмм по линиям связи. Для этой цели PES, вернее передаваемые в них видео- и аудиофрагменты, нарезаются на более мелкие части, которые упаковываются в пакеты транспортного потока длиной в 188 байт, рис. 1.

В данном случае один IP пакет переносит семь пакетов MPEG-2 TS. Это распространенная пропорция. Увеличение числа MPEG пакетов в одном IP пакете, с одной стороны, приводит к более эффективному использованию транспортного ресурса, но с другой увеличивает джиттер (неравномерность поступления пакетов в точку назначения). Поэтому выбирается компромиссный вариант.

Структура пакетов транспортного потока MPEG-2 TS
Эти пакеты имеют фиксированную длину 188 байт. При наложения помехозащитного кода Рида-Соломона длина пакета увеличивается до 204 байт, но этот вопрос будет рассмотрен в следующей части. Структура пакета транспортного потока показана на рис. 3. Он состоит из заголовка, занимающего 32 байта, поля адаптации и поля передачи аудио- и видеоданных. В поле адаптации передаются временные метки (синхросигналы), служебные таблицы или данные пользователя. Эти компоненты рассмотрены ниже.

Заголовок начинается с синхропакета (0х47), позволяющего декодеру выявить его начало. После синхропакета передаются три однобитовых флага. Флаг ошибки (Transport Error Indicator) устанавливается в 1 при наличии в пакете некорректируемых ошибок. Флаг начала полезных данных (Payload start indicator) устанавливается в 1, если в пакете передается начало PES с видео- или аудиоданными или начало служебной таблицы. Флаг приоритетной передачи устанавливается в 1, если пакет имеет большую важность, нежели другие с аналогичным PID-ом.
После флагов идет 13-битный PID идентификатор пакета. Следующие два бита указывают на наличие и тип скремблирования – 00 соответствует отсутствию скремблирования, а значение остальных комбинаций определяется в рамках системы доступа. Следующие два бита Adaptation Field Control индицируют состав поля с полезной нагрузкой. 0х1 индицирует отсутствие поля адаптации. В этом случае вся область полезных данных занята компрессированными видео или аудио. 0х2 соответствует пакету, в котором эта область отдана под поле адаптации, а оставшееся место заполнено стаффинговыми битами. 0х3 указывает на наличие как поля адаптации, так и видео-, и аудиоданных. 4-битный счетчик непрерывности Continuity Counter циклически отсчитывает пакеты с одинаковыми PID-ами. То есть в каждом следующем пакете значение счетчика увеличивается на 1. Он позволят декодеру обнаруживать потери пакетов.
Поле адаптации тоже имеет регламентированную структуру7.

Синхронизация компонентов потока
Для временной увязки компонентов одной программы в транспортном потоке, а также для синхронизации работы декодера используются три временные метки. Это ссылка на программные часы PCR (Program Clock Reference), метка декодирования DTS (Decoding Time Stamp) и метка воспроизведения PTS (Presentation Time Stamp).
Отдельные метки для декодирования и для воспроизведения нужны для того, что последовательность декодирования кадров и их появления на экране может быть разной. При компрессировании некоторых кадров используется информация не только о предыдущих, но и о последующих кадрах. Поэтому иногда для декодирования более раннего кадра надо сначала восстановить более поздний, который сохраняется в буфере декодера, где ожидает момента воспроизведения на экране.
Что касается ссылок на программные часы, то они представляют собой значение счетчика, отсчитывающего периоды частоты 90 кГц, которые получаются делением частоты 27 МГц, формируемой опорным генератором. По стандарту они должны передаваться не реже чем раз в 0,7 с. Каждая программа пакета имеет собственные независимые программные часы, то есть количество PCR, передаваемых в мультиплексированном потоке, определяется количеством включенных в него программ. Использование единого счетчика, действующего в рамках программы, позволяет синхронизировать между собой все ее составляющие, а также обеспечивает синхронизацию декодера с передатчиком. В декодере имеется аналогичный генератор частоты 27 МГц, а его подстройка в соответствии с получаемыми ссылками осуществляется с помощью системы ФАПЧ. Постоянная корректировка тактовой частоты обеспечивает корректное прочтение меток PTS и DTS, то есть своевременное декодирование и воспроизведение видеокадров и аудиофрагментов. Если декодер перестраивается на другую программу, то в его счетчик заводится новое значение, соответствующее PCR новой программы.

Служебные таблицы
Помимо аудио-, видео- и различных других данных, в транспортный поток включаются служебные таблицы, несущие информацию, необходимую для поиска, декодирования и воспроизведения программ. Определенная часть таблиц регламентируется стандартом MPEG-2. Они предназначены для описания параметров одного пакета и получили название PSI (Program Specific Information) Tables, то есть Таблицы с программно-зависимой информацией. Но впоследствии появилась потребность передачи информации, касающейся всех пакетов, передаваемых в одной сети (то есть одним провайдером). Для этой цели в рамках стандарта DVB были введены дополнительные таблицы, и весь набор получил название Service Information Tables.
Набор служебных таблиц показан на рис. 4. Часть из них является обязательной, а часть – факультативной. Таблицы левого столбца определены стандартом MPEG-2.

Таблица объединения программ PAT (Program Assosiation Table) представляет собой «корневой каталог» потока. В ней указаны PID-ы таблиц PMT всех программ, передаваемых в данном потоке, а также PID таблицы NIT. Это стартовая таблица, с нее ресивер начинает поиск программы, на прием которой его настроили. Она всегда имеет PID – 00. Для каждой программы, передаваемой в пакете, в поток включается таблица состава программ PMT (Program Map Table). Она содержит перечень всех элементарных потоков (аудио, видео, PCR и др.), входящих в состав этой программы, с указанием их PID-ов.
Остальные таблицы имеют постоянные PID-ы и обнаруживаются приемником напрямую. Содержание таблицы условного доступа CAT (Conditional Access Table) определяется системой доступа и по понятным причинам не раскрывается. Единственное, стандарт требует, чтобы таблица включала в себя PID-ы EMM (Entitlement Management Messages) всех передаваемых в пакете программ. Смысл сообщений EMM мы рассмотрим в разделе о системах доступа.
Обязательное включение в поток следующей группы таблиц регламентируется уже стандартом DVB. Это таблицы NIT, SDT, EIT и TDT. В таблице сетевой информации NIT (Network Information Table) содержатся координаты всех транспортных потоков, относящихся к той же сети, что и данный поток. Этой таблицей приемник пользуется для избирательного поиска каналов (транспондеров), передаваемых конкретной сетью. NIT для других сетей включаются в поток факультативно.
Таблица описания услуг SDT – Service Description Table, содержит названия каналов и других услуг, передаваемых в потоке. Она может содержать и некоторые другие характеристики, например, язык. В качестве опции могут также передаваться таблицы SDT для других потоков сети. Используется для обслуживания электронного гида EPG. Изменения в расписании могут передаваться в факультативной таблице RST Running Status Table, включение которой исключает необходимость передачи полной информации о программах.
Таблица TDT содержит информацию о времени по Гринвичу. В некоторых случаях она дополняется таблицей смещения времени TOT (Time Offset Table), определяющей требуемую коррекцию времени по Гринвичу в зависимости от долготы географической точки. Таблица EIT поставляет информацию о конкретных программах, необходимую для формирования EPG. А именно – название программы, время ее начала, продолжительность, идентификатор сети и индикатор скремблирования, а также краткое описание. В обязательном порядке в поток вводится таблица EIT с информацией о текущих и следующих за ними трансляциях. В качестве опции может вводиться таблица для более поздних программ и/или программ, передаваемых в других потоках.
Таблица ВАТ (Bouquet Association Table) может включать координаты всех услуг, объединенных в единый коммерческий пакет, но, в общем случае, передаваемых в разных каналах. Эта таблица не является обязательной, но ее наличие облегчает приемнику настройку на любую услугу данного коммерческого пакета вне зависимости от того, в каком транспортном потоке услуга передается.
Таблица ST (пустая таблица) может подставляться вместо любой другой таблицы, потерявшей актуальность, например, в точке ретрансляции пакета в другую сеть. Соответственно, в наследство ей достается PID ликвидированной таблицы. Изложенная информация о назначении таблиц, а также подробное описание их состава и правила размещения в транспортных пакетах приведены в стандарте DVB в части Specification for service Information in DVB systems ETSI EN 300 468.

Источник