Стандарт mpeg-4, -7, -21

Детальное техническое описание MPEG-4 DMIF и систем

Рис. 6.3 показывает, как потоки, приходящие из сети (или запоминающего устройства), или потоки TransMux, демультиплексируются в потоки FlexMux и передаются соответствующим демультиплексорам FlexMux, которые извлекают элементарные потоки. Элементарные потоки (ES) анализируются и передаются соответствующим декодерам. Декодирование преобразует данные в AV (аудио-визуальный) объект и выполняет необходимые операции для реконструкции исходного AV-объекта, готового для рэндеринга на соответствующем аппарате. Аудио- и визуальные объекты представлены в их кодированной форме. Реконструированный AV-объект делается доступным для слоя композиции при рэндеринге сцены. Декодированные AVO, вместе с данными описания сцены, используются для композиции сцены. Пользователь может расширить возможности, разрешенные автором, взаимодействовать со сценой, которая отображается.

DMIF

DMIF (Delivery Multimedia Integration Framework) является протоколом сессии для управления мультимедийными потоками поверх общих средств доставки данных. В принципе он имеет много общего с FTP. Единственное (существенное) отличие заключается в том, что FTP выдает данные, а DMIF предоставляет указатели, где получить данные (streamed).

Рис. 6.3. Главные компоненты терминала MPEG-4 (принимающая сторона)

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

Аналогично, когда работает DMIF, первым действием, которое он выполняет, является установление сессии с удаленным партнером. Позднее выбираются потоки и DMIF посылает запрос передать их; партнер DMIF в отклике пришлет указатель на соединение, где будут проходить потоки, и затем также устанавливает соединение.

По сравнению с FTP, DMIF является системой и протоколом. Функциональность, предоставляемая DMIF, определяется интерфейсом, называемым DAI ( DMIF -Application Interface), и реализуется через протокольные сообщения. Эти протокольные сообщения для разных сетей могут отличаться.

При конструировании DMIF рассматривается и качество обслуживания (QoS), а DAI позволяет пользователю DMIF специфицировать требования для нужного потока. Проверка выполнения требований оставляется на усмотрение конкретной реализации DMIF. Спецификация DMIF предоставляет советы, как решать такие задачи на новом типе сети, таком, например, как Интернет.

Интерфейс DAI используется для доступа к широковещательному материалу и локальным файлам. Это означает, что определен один, универсальный интерфейс для доступа к мультимедийному материалу для большого числа технологий доставки.

Уместно заявить, что интегрирующая система DMIF покрывает три главные технологии, интерактивную сетевую технику, широковещательную технологию и работу с дисками; это показано на рис. 6.4 ниже.

Рис. 6.4. DMIF осуществляет интеграцию доставки для трех основных технологий

Архитектура DMIF такова, что приложения, которые для коммуникаций базируются на DMIF, не должны быть чувствительны к нижележащему методу коммуникаций. Реализация DMIF заботится о деталях технологии доставки, предоставляя приложению простой интерфейс.

На рис. 6.5 представлена указанная выше концепция. Приложение получает доступ к данным через интерфейс приложения DMIF, вне зависимости от того, откуда получены данные: от широковещательного источника, локальной памяти или от удаленного сервера. Во всех сценариях локальное приложение только взаимодействует через универсальный интерфейс (DAI). Различные варианты DMIF будут затем транслировать запросы локального приложения в специфические сообщения, которые должны быть доставлены удаленному приложению, учитывая особенности используемых технологий доставки. Аналогично, данные, поступающие на терминал (из удаленного сервера, широковещательных сетей или локальных файлов) доставляются локальному приложению через DAI.

Специализированные версии DMIF подключаются приложением опосредовано, чтобы управлять различными специфическими технологиями доставки данных; это, однако прозрачно для приложения, которое взаимодействует только с одним DMIF -фильтром. Этот фильтр отвечает за управление конкретным примитивом DAI в нужный момент.

Концептуально "настоящее" удаленное приложение, доступное через сеть, например, через IP или ATM, ничем не отличается от эмулируемого удаленного приложения, получающего материал от широковещательного источника или с диска. В последнем случае, однако, сообщения, которыми обмениваются партнеры, должны быть определены, чтобы обеспечить совместимость (это сигнальные сообщения DMIF ). С другой стороны, интерфейсы между двумя партнерами DMIF и эмулируемым удаленным приложением являются внутренними по отношению реализации и не должны рассматриваться в этой спецификации. Заметим, что для сценариев получения данных широковещательно и из локальной памяти рисунок показывает цепочку "Локальный DMIF ", "Удаленный DMIF (эмулированный)" и "Удаленное приложение (эмулированное)". Эта цепочка представляет концептуальную модель и не должна отражаться в практической реализации (на рисунке она представлена закрашенной областью).

Рис. 6.5. Архитектура коммуникаций DMIF

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

При рассмотрении сценария удаленного взаимодействия слой DMIF ничего не знает о приложении. Введен дополнительный интерфейс DNI ( DMIF -Network Interface), который служит для подчеркивания того, какого рода информацией должны обмениваться партнеры DMIF. Дополнительные модули SM (Signaling mapping) служат для установления соответствия между примитивами DNI и сигнальными сообщениями, используемыми в конкретной сети. Заметим, что примитивы DNI специфицированы для информационных целей, и интерфейс DNI в настоящей реализации может отсутствовать.

DMIF допускает одновременное присутствие одного или более интерфейсов DMIF, каждый из которых предназначен для определенной технологии доставки данных. Одно приложение может активировать несколько технологий доставки.

Вычислительная модель DMIF

Когда приложение запрашивает активацию услуги, оно использует сервисный примитив DAI и формирует соответствующую сессию. Реализация DMIF устанавливает контакт с партнером (который концептуально может быть либо удаленным, либо эмулируемым локальным партнером) и формирует вместе с ним сетевую сессию. В случае широковещательного и локального сценариев способ формирования и управления сессией находится вне зоны ответственности данного документа. В случае интерактивного сценария с удаленным сервером DMIF задействует свой сигнальный механизм для формирования и управления сессией, например сигнальный механизм ATM. Приложения партнеров используют эту сессию для установления соединения, которое служит для передачи прикладных данных, например элементарных потоков MPEG-4.

Когда приложению нужен канал, оно использует примитивы канала DAI, DMIF транслирует эти запросы в запросы соединения, которые являются специфическими для конкретных запросов сетевых реализаций. В случае сценариев широковещания и локальной памяти метод установления соединения и последующего управления находится за пределами регламентаций MPEG-4. В случае сетевого сценария, напротив, DMIF применяет свой сигнальный механизм для формирования и управления соединением. Это соединение используется приложением для целей доставки данных.

На рис. 6.6 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа.

• Приложение-инициатор посылает запрос активизации услуги своему локальному слою DMIF — коммуникационное соединение между приложением-инициатором и его локальным партнером DMIF устанавливается в плоскости управления (1).
• Партнер-инициатор DMIF запускает сетевую сессию с партнером — адресатом DMIF — коммуникационное соединение партнером — инициатором DMIF и партнером — адресатом DMIF устанавливается в плоскости управления (2).
• Партнер — адресат DMIF идентифицирует приложение-адресат и переадресует запрос активации услуги — коммуникационное соединение между партнером — адресатом DMIF и приложением-адресатом устанавливается в плоскости управления (3).
• Приложения партнеров создают каналы (запросы передаются через коммуникационные пути 1, 2 и 3). Результирующие каналы в пользовательской плоскости (4) используются приложениями для реального информационного обмена. DMIF вовлечена во все четыре этапа.

Рис. 6.6. Вычислительная модель DMIF

Слой DMIF автоматически определяет, предполагается ли предоставление данной услуги удаленным сервером в конкретной сети, например в IP или ATM, широковещательной сетью или устройством локальной памяти. Выбор основывается на адресной информации партнера, которая предоставляется приложением в качестве части URL, переданной DAI.

Демультиплексирование, синхронизация и описание потоков данных

Отдельные элементарные потоки должны быть выделены на уровне доставки из входных данных некоторого сетевого соединения или из локального устройства памяти. Каждое сетевое соединение или файл в модели системы MPEG-4 рассматривается как канал TransMux. Демультиплексирование выполняется частично или полностью слоями вне области ответственности MPEG-4. Единственным демультиплексирующим средством, определенным MPEG-4, является FlexMux, которое может опционно использоваться для снижения задержки, получения низкой избыточности мультиплексирования и для экономии сетевых ресурсов.

Для целей интегрирования MPEG-4 в системную среду интерфейс приложения DMIF является точкой, где можно получить доступ к элементарным потокам как к потокам пакетов sync. DMIF является интерфейсом для реализации функций, недоступных в MPEG. Управляющая часть интерфейса рассмотрена в разделе DMIF.

MPEG-4 определяет модель системного декодера. Это позволяет точно описать операции терминала, не делая ненужных предположений о деталях практической реализации. Такое описание важно для того, чтобы дать свободу разработчикам терминалов MPEG-4 и декодирующих приборов. Это оборудование включает в себя широкий диапазон аппаратов — от телевизионных приемников, которые не имеют возможности взаимодействовать с отправителем, до ЭВМ, которые имеют полноценный двунаправленный коммуникационный канал. Некоторые устройства будут получать потоки MPEG-4 через изохронные сети, в то время как другие будут использовать для обмена информацией MPEG-4 асинхронные средства (например Интернет). Модель системного декодера предоставляет общие принципы, на которых могут базироваться все реализации терминалов MPEG-4.

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

Демультиплексирование

Демультиплексирование происходит на уровне доставки, который включает в себя слои TransMux и DMIF. Извлечение входящих информационных потоков из сетевого соединения или из памяти включает в себя два этапа. Во-первых, каналы должны быть найдены и открыты. Это требует наличия некоторого объекта, который осуществляет транспортный контроль и устанавливает соответствие между транспортными каналами и специальными элементарными потоками. Таблица карты таких потоков связывает каждый поток с ChannelAssociationTag (канальной меткой), служащей указателем для канала, через который идет поток. Определение ChannelAssociationTag для реального транспортного канала, а также управление сессией и каналами осуществляется DMIF.

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

Базовый термин "TransMux Layer" используется, чтобы абстрагироваться от нижележащей функциональности — существующей или будущей, которая пригодна для транспортировки потоков данных MPEG-4. Заметим, что этот уровень не определен в контексте MPEG-4. Примерами могут служить транспортные потоки MPEG-2, H.223, ATM AAL 2, IP/UDP. Предполагается, что слой TransMux предоставляет защиту и средства мультиплексирования, этот уровень обеспечивает определенный класс QoS. Средства безопасности включают в себя защиту от ошибок и детектирование ошибок, удобные для данной сети или устройств памяти.

В любом конкретном сценарии приложения используются один или более специфических TransMux. Каждый демультиплексор TransMux предоставляет доступ к каналам TransMux. Требования на информационный интерфейс доступа к каналу TransMux те же, что и для всех интерфейсов TransMux. Они включают необходимость надежного детектирования ошибок; доставки, если возможно, ошибочных данных с приемлемой индикацией ошибок; кадрирования поля данных, которое может включать потоки либо SL, либо FlexMux. Эти требования реализованы в интерфейсе TransMux (системная часть стандарта MPEG-4). Адаптация потоков SL должна быть специфицирована для каждого стека протоколов.

Средство FlexMux специфицировано MPEG для того, чтобы опционно предоставить гибкий метод, имеющий малую избыточность и задержку для переукладки данных в тех случаях, когда нижележащие протоколы не поддерживают это. Средство FlexMux само по себе недостаточно устойчиво по отношению к ошибкам и может использоваться либо в каналах TransMux с высоким QoS, либо для объединения элементарных потоков, которые достаточно устойчивы к ошибкам. FlexMux требует надежного детектирования ошибок. Эти требования реализованы в информационных примитивах прикладного интерфейса DMIF, который определяет доступ к данным в индивидуальных транспортных каналах. Демультиплексор FlexMux выделяет SL-потоки из потоков FlexMux.