Главная   Каталог   Распродажа    Справочник    Контакты   Карта сайта
Дейта Плюс
+7 (916) 296-38-88
123007, Москва, 2й Силикатный пр-д,
д.14, корп.2,стр.14
Справочник > Статьи
 Версия для печати


Виды MPEG потоков


Перед обзором различных типов цифровых потоков вкратце рассмотрим какие роли играет каждый из них:
  • Elementarry stream (ES- элементарный поток): поток данных одного типа. Например, цифровой поток из MPEG кодера содержит ES для видео и ES для звука. ES являются кирпичиками, из которых строятся все остальные виды MPEG потоков.
  • Packetized elementary streams (PES - пакетированные элементарные потоки) преобразованная разновидность ES, содержащая временную информацию, которая позволяет синхронизировать ES видео и ES звука. PES также используются для формирования данных особого вида, таких как титры и др. PES используются для формирования программного потока или транспортного потока, а так же могут для использоваться напрямую в приложениях, например, в цифровых видео рекодерах.
  • Program stream (PS - программный поток) объединяет несколько типов PES (видео, звук, служебная информация). Все PES в программном потоке должны быть привязаны к единому таймеру синхронизации.
  • Transport stream (TS - транспортный поток) другая разновидность объединения PES в единый поток для последующей передачи. Пакеты транспортного потока имеют фиксированную длину и содержат необходимую информацию по синхронизации. Транспортные потоки могут содержать PES, сформированных с разными источниками синхронизации и поэтому они могут использоваться для мультипрограммной передачи/вещания.

 

Элементарный Поток (ES)


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

Элементарные потоки имеют внутреннюю структуру, указывающую декодерам о способе восстановления данных. Например, определяют тип передаваемого фрейма (I, P или B), относительное положение блока данных на экране и другую служебную информацию. В звуковом ES потоке обычно содержится информация о частоте дискретизации исходного сигнала и используемого типа сжатия.

Для элементарных потоков характерно непрерывное формирование: MPEG кодер будет формировать каждый из типов ES видео и звука пока их сигналы присутствуют на входе устройства. Это естественно для видео систем, но не для IP систем. IP сети разбивают большие объемы данных на мелкие фрагменты (пакеты). Поэтому следующим типом MPEG потоков рассмотрим пакетированные элементарные потоки.

Пакетированные Элементарные Потоки (PES)

Пакетированные элементарные потоки (Packetized elementary stream, PES) основываются на элементарных потоках, разбитых на фрагменты (пакеты). Каждый пакет (PES) состоит из заголовка, включающего цифровой код источника элементарного потока. Эта информация важна для последующего восстановления из мультипрограммного потока, содержащего несколько каналов видео и аудио данных и определения какому элементарному потоку видео  принадлежит элементарный поток звука. Некоторые PES содержат информацию о временных метках. PES могут быть различной длины размером сотни килобайт и более.

Для видео сигнала могут использоваться два вида временных меток: PTS (presentation time stamp) и DTS (decode time stamp). PTS кадра определяет время, когда данный кадр должен быть показан. DTS кадра показывает время, когда данный кадр должен быть обработан декодером.

Для понимания различия между PTS и DTS нужно иметь представление о типах фреймов, используемых в MPEG кодировании (I, B и P). Напомним, что фрейм I-типа не содержит какой либо информации о предыдущих кадрах видеосигнала. Фрейм P-типа содержит информацию только об изменениях в кадре относительно предыдущего фрейма I или P-типа. Фрейм B-типа может быть вычислен на разнице предыдущих или последующих фреймах I или P-типа. Далее рассматривается пример группы кадров (GOP - Group of Picturies) с последовательностью IB1B2P

В рассматриваемом примере фрейм I должен быть отображен первым, поэтому он должен иметь более раннюю временную метку PTS, чем временные метки остальных фреймов данной GOP. Первый фрейм В-типа, B1, должен быть отображен вторым, а B2 - третьим. PTS вовсе не обязательна для каждого фрейма, в случае ее отсутствия декодер самостоятельно высчитает необходимую PTS. Наконец, фрейм P-типа должен быть отображен последним со значением PTS самым поздним из всех 4-х.

Следующий рисунок наглядно отображает вышесказанное.

Используя этот же пример рассмотрим DTS. Как и в первом случае фрейм I-типа должен быть декодирован первым. Однако далее декодеру требуется получить фрейм P, т.к. без его декодирования не удастся правильно восстановить фреймы B-типа. Другими словами, перед декодированием фрейма B, декодеру необходимо иметь данные о предыдущих и последующих фреймах, т.е. DTS для фрейма P должна быть меньше, чем DTS для B-фреймов.

Все это важно для понимания задач вещания видео по IP сетям, т.к. в данном случае выбирается компромисс между качеством передаваемого видеосигнала и шириной пропускания канала связи. Отличие фреймов P-типа состоит в меньшем объеме данных по сравнению с фреймами I-типа (примерно в двое), а фреймов В-типа - меньшем объеме данных по сравнению с фреймами P-типа (опять же в двое). Поэтому поток, содержащий большое количество фреймов В-типа нуждается в меньшей полосе пропускания, чем поток с небольшим содержанием фреймов В-типа. К сожалению, увеличение числа фреймов В-типа ведет к увеличению задержек. Для просчета фрейма В-типа, кодеру необходимо получить два фрейма (I или P), на которых фрейм В-типа собственно и основывается. В NTSC системах задержка составляет 33 мсек на В-фрейм, в PAL/SECAM системах - 40 мсек. Увеличивая число фреймов В-типа в потоке, мы экономим на полосе пропускания, но теряем в увеличении времени задержки системы в целом.

Программный поток (PS)

Программный поток (Program Stream) несет информацию об одной программе. Он состоит из одного или нескольких PES и добавленной служебной информацией. Все элементарные потоки одной программы привязаны к единому таймеру синхронизации, для обеспечения синхронного отображения видео данных и звукового сопровождения. Программные потоки используются в основном в DVD и в других системах, где вероятность появления ошибок минимальна. Программные потоки могут иметь переменный bit-rate и обычно используют длинные пакеты.

В MPEG программа состоит из видеопотока, звукового сопровождения и соответствующих им данных (титры, телетекст и т.п.). Обычно видеопотоку соответствует один стерео канал звукового сопровождения, но в программе может так же присутствовать звуковой канал для Surround систем, звук на другом языке, комментарии. Данные могут содержать титры, информацию о программном потоке (название, владелец, описание) и т.д. Управляющая информация другой важный тип данных передаваемых в программном потоке, включая информацию, необходимую для записи и воспроизведения. Системам условного доступа так же необходимо передавать свою служебную информацию в программном потоке.

Напомним, что несколько каналов видео могут принадлежать одному программному потоку (до 16 видео и 32 звуковых каналов), но при этом остается в силе требование о привязке к единому таймеру синхронизации. Примером может служить спортивная трансляция, когда одно действие отображается с нескольких камер.

Транспортный поток (TS)

Транспортный поток (TS - transport stream) подобен программному потоку - они оба объединяют видео поток, поток звука и относящиеся к ним данные в логическую группу. В отличие от программных потоков, транспортные потоки были разработаны специально для последующей их передачи по телекоммуникационным сетям, в которых могут возникать ошибки. Многие приложения попадают в данную категорию - спутниковое и наземное вещание, все типы проводных и оптических сетей. Другим немаловажным отличием является то, что программный поток несет только одну программу, а транспортный поток может нести несколько программ. В литературе и в других источниках вместо термина "программа" может использоваться термин "сервис" или "канал".

Транспортный поток использует фиксированную длину пакета, равную 188 байт, приспособленного для сетей с постоянным бит-рейтом. Каждый пакет содержит данные только из одного элементарного потока. Код FEC (Forward error correction) так же может быть добавлен в данный поток с использованием стандартных кодов восстановления ошибок таких, как Reed-Solomon (RS). В транспортном потоке широко используемый RS-код добавляет 16 или 20 байт к 188-байтному пакету. Получаемые при этом пакеты длиной 204 байта широко используются в DVB приложениях, распространенных в Европе и на нескольких DTH спутниковых системах. Пакеты длиной 208 байт используются в  приложениях ATSC (Advanced Television Systems Committee), распространенных системах наземного вещания США (иногда называемых DTV или HDTV). Основное назначение RS-кодов - обеспечение возможности восстановления ресиверов всего пакета в случае возникновения ошибки. 16-ти байтный RS-код позволяет восстановить ошибки в 8-ми байтах пакета; 20-ти байтный RS-код - до 10-ти искаженных байт (FEC не дает особого в выигрыша в системах гарантированной доставки, таких как TCP сети, т.к. в таких системах искаженные байты могут быть посланы заново).

Очень важно понимать, что длина пакета транспортного потока не равна длине IP пакета, предназначенного для его (TS-пакета) пересылки. Обычно IP пакет может содержать несколько TS пакетов. IP пакет, содержащий 7 TS пакетов наиболее распространен, т.к. 7 - наибольшее число TS-пакетов, которые могут быть вставлены в IP пакет без фрагментации. Напомним, что максимальная длина IP пакета, которая может быть послана в Ethernet кадре равняется 1500 байт.

Другая техника обработки ошибок в TS - это использование чередования (interleaving). В данном случае, TS пакеты имеют свой порядок сортировки, при котором в IP пакет не попадают соседние TS пакеты. Это может быть очень удобным, когда один IP пакет потеряется при передаче; MPEG декодеру проще скрыть потерю нескольких изолированных TS пакетов, чем скрыть потерю группы соседних пакетов. Большое преимущество чередования заключается в "сокрытии" возникающих ошибок без добавления дополнительных битов к основному пакету. Недостатком такого метода является возникающие дополнительные задержки в системе, которые могут быть критичными в ряде приложений.

Для указывания ресиверу, как PES организованы в сервисы, необходимо в транспортный поток включить дополнительную служебную информацию. Основным понятием, используемым в транспортных потоках является PID (Packet IDetntifier - идентификатор  пакета). PID однозначно определяет какой элементарный пакет содержит TS-пакет. Например, пакеты для видео сигнала в транспортном потоке могут иметь PID=42, а относящийся к нему сигнал звукового сопровождения PID=38. Второй канал звукового сопровождения (на другом языке) для того же видео сигнала имеет PID=85.

Для отслеживания всех PID-ов, MPEG определяет несколько таблиц, несущих служебную информацию транспортного потока. PID=0 используется для PAT (Program association table - таблица соответствия программ), которая отображает все программы в данном транспортном потоке. Каждая запись в PAT указывает на PMT (program map table - таблица карты программ), по одной для каждой программы. (Напомним,что программа - это набор из видео, звука и данных, относящихся к одному событию). Внутри PMT содержится список PID-ов для данной программы, какой бы она не была. Когда пользователь выбирает для просмотра программу, PAT и PMT определяют какой видео поток необходимо направить в видео декодер, а какйо звуковой поток в декодер звука.

Program Clock Reference (PCR)

PCR - 33 битное число, периодически вставляемое в транспортный поток, в целях синхронизации MPEG декодера с синхрогенератором 27 МГц MPEG кодера. Синхронизация необходима для слежения за состоянием входного буфера декодера.  Значение 33-битного счетчика, связанного с синхрогенератором 27 МГц в кодере, периодически вставляется в транспортный поток. Декодер извлекает его из транспортного потока и использует PCR для активации синхронизации внутреннего генератора 27 МГц. Точность синхронизации зависит от постоянства поступления данных от кодера в декодер. Влияние любых изменений во времени доставки пакетов при проходе по сети по возможности должны быть уменьшены либо исключены вовсе. Однако небольшие задержки все же будут возникать, поэтому важно, что бы декодер был спроектирован с учетом данного факта.

Мультиплексирование потока и DVB-ASI

Очень часто желательно объединять несколько транспортных потоков вместе для последующей передаче по сети. Конечно это может быть осуществлено преобразованием каждого потока в IP пакеты и передачей их по IP сетям. В рамках проекта DVB (Digital Video Broadcasting) разработан другой метод для передачи многопрограммных потоков по сетям, обычно используемым  для передачи SDI сигнала (последовательный некомпрессированный цифровой поток скоростью 270 Mbps, содержащий одну программу). Этот метод носит название DVB-ASI (Asinchronous Serial Interface) и позволяет объединять в единый поток несколько программ, даже если они имеют разные бит-рейты.

По сути DVB-ASI поток представляет канал со скоростью 270 Mbps с добавленной полезной нагрузкой, которая может состоять из одной или нескольких программ с разными бит-рейтами. Суммарный бит-рейт всех программ не может превышать 200 Mbps, но и этого хватает для передачи большоего количества программ со скоростями от 4 до 8 Mbps.

В настоящее время DVB-ASI используется очень широко. Разработано большое количество MPEG-кодеров с ASI выходами, MPEG-декодреов с ASI входами, мультиплексоров, видео серверов и т.п. оборудования. DVB-ASI очень прост в использовании для внутристудийного обмена. Наконец, уже большое число компаний предлагают услуги по доставке видео по сетям оптимизированным под 270 Mbps и использующим DVB-ASI.

Мультиплексирование потока может показаться относительно простой задачей, но на практике зачастую это процесс является сложным, имеющим дело с плотным взаимодействием мультиплексора с MPEG-кодером. На самом простом уровне мультиплексирование представляет собой разбиение PES на 188-битные транспортные потоки, с назначением PID каждому PES и передачей пакетов согласно выделенной полосе канала. Следуя передовым технологиям мультиплексирования и тенденциям развития цифрового телевидения в данный процесс мультиплексирования внесены существенные изменения. Обычно кабельный оператор устанавливает фиксированное значение бит-рейта на MPEG кодере и назначает фиксированное значение бит-рейта каждому PES при мультиплексировании. Это не самый лучший способ использования имеющегося канала передачи данных, т.к. некоторые сцены в видео сигнале требуют значительно меньшей полосы канала, чем им было назначено в кодере и в мультиплексоре. В то же время другие каналы в этом же транспортном потоке могут нуждаться в дополнительном увеличении бит-рейта.

Для решения этой проблемы многими операторами используется технология статистического мультиплексирования. Данный метод основывается на предположении, что в один момент времени только несколько видео программ могут содержать сцены, требующие широкого канала (спортивные передачи, фильмы в стиле Action и т.п.). Мультиплексор использует информацию о сложности сцены и определяет потребность выбранного канала в ширине полосы пропускания и тем самым может "занять" часть полосы у каналов, в данный момент времени содержащие статичные или маломеняющиеся сцены. Наибольшей производительности системы можно добиться, когда MPEG кодер сам сообщает мультиплексору информацию о сложности видео сцен.