Стандарт MPEG-4 (часть 2)

Верификационное тестирование: проверка работы MPEG

Низкие и средние скорости передачи бит (версия 1)

При испытаниях для низкой и средней скорости передачи, рассматривались последовательности кадров, которые следуют стандарту MPEG-1. (MPEG-2 будет идентичным для прогрессивных последовательностей за исключением того, что MPEG-1 немного более эффективен, так как имеет несколько меньшую избыточность заголовков). Тест использует типовую тестовую последовательность для разрешений CIF и QCIF, закодированный с идентичными условиями по скорости передачи для MPEG-1 и MPEG-4. Тест был выполнен для низких скоростей от 40 кбит/с до 768 кбит/с.

Тесты эффективности кодирования показывают полное превосходство MPEG-4 перед MPEG-1 как на низкой, так и на средней скорости передачи.

Кодирование, базирующееся на содержимом (версия 1)

Верификационные тесты для кодирования, базирующегося на содержимом, сравнивают визуальное качество кодирования object-based и frame-based. Главным соображением было гарантировать, чтобы object-based кодирование можно было поддерживать без ухудшения визуального качества. Содержимое теста было выбрано так, чтобы перекрыть широкий спектр условий моделирования, включая видео сегменты с различными типами движения и сложностью кодирования. Кроме того, условия теста были выбраны так, чтобы перекрыть низкие скорости передачи в диапазоне от 256 кбит/с до 384 кбит/с, и высокие скорости передачи в диапазоне от 512кбит/с до 1.15 Мбит/с. Результаты тестов ясно продемонстрировали, что объектно-ориентированная функциональность, предоставляемая MPEG-4, не имеет избыточности или потерь визуального качества, по сравнению с кодированием frame-based. Не существует статистически значимого различия между вариантами object-based и frame-based.

Профайл продвинутой эффективности кодирования ACE (Advanced Coding Efficiency) (версия 2)

Формальные верификационные тесты профайла ACE (Advanced Coding Efficiency) были выполнены с целью проверки, улучшают ли эффективность кодирования три новые средства версии 2, включенные в визуальный ACE профайл MPEG-4 версии 2 (компенсация общего перемещения, компенсация перемещения на четверть пикселя и адаптированное к форме преобразование DCT), по сравнению с версией 1. Тесты исследуют поведение ACE профайла и главного визуального профайла MPEG-4 версия 1 в режимах object-based и frame-based при низкой скорости передачи, frame-based при высокой скорости передачи. Полученные результаты показывают преимущество ACE профайла перед главным профайлом. Ниже приведены некоторые детали сопоставления работы этих профайлов:

• Для объектно-ориентированного случая, качество, предоставляемое профайлом ACE при 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 384 кбит/с.
• Для кадр-ориентированного случая, качество, предоставляемое профайлом ACE при 128 кбит/с и 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 256 кбит/с и 384 кбит/с соответственно.
• Для кадр-ориентированного случая при высоких скоростях передачи, качество, предоставляемое профайлом ACE при 768 кбит/с равно качеству, обеспечиваемому главным профайлом при 1024 кбит/с.

При интерпретации этих результатов, нужно заметить, что главный профайл MPEG-4 более эффективен, чем MPEG-1 и MPEG-2.

Тесты устойчивости к ошибкам

Простой профайл (версия 1)

Устойчивость видео к ошибкам в простом профайле MPEG-4 была оценена в ходе тестов, которые симулируют видео MPEG-4, выполненных при скоростях между 32 кбит/с и 384 кбит/с. Испытания произведены при BER < 10-3, и средней длине блока ошибок около 10мс. Тестовая методология базировалась на непрерывной оценке качества в течение 3 минут.

Результаты показывают, что в среднем качество видео, полученное для мобильного канала, является высоким, что воздействие ошибок в видео MPEG-4 остается локальным, и что качество быстро восстанавливается по завершении блока ошибок.

6.1.2.2. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)

Устойчивость видео к ошибкам в MPEG-4 профайле ARTS была оценена в ходе тестов, аналогичных описанным выше, при скоростях между 32 кбит/с и 128 кбит/с. В этом случае, остаточный уровень ошибок достигал 10-3, а средняя длительность блока ошибок была около 10 мс или 1 мс.

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

Тестирование стабильности временного разрешения

Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)

В данном тесте исследовались характеристики видео кодека, использующего технику преобразования с динамическим разрешением, которая адаптирует разрешение видео материала к обстоятельствам в реальном времени. Материал активной сцены кодировался при скоростях 64 кбит/с, 96 кбит/с и 128 кбит/с. Результаты показывают, что при 64 кбит/с, он превосходит простой профайл, работающий при 96 кбит/с, а при 96 кбит/с, визуальное качество эквивалентно полученному для простого профайла при 128 кбит/с.

Проверки масштабируемости

Простой масштабируемый профайл (версия 1)

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

1. 24 кбит/с для базового слоя и 40 кбит/с для дополнительного слоя.
2. 32 кбит/с для обоих слоев.
3. 64 кбит/с для базового слоя и 64 кбит/с для дополнительного слоя.
4. 128 кбит/с для обоих слоев.

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

Центральный профайл (версия Core Profile 1)

Цель верификационного теста заключалась в оценке особенностей временного масштабирования MPEG-4 видео в рамках центрального профайла (Core Profile).

Для проведения тестирования применялся метод "Single Stimulus". В процессе эксперимента принимали участие 45 испытуемых из двух различных лабораторий. Результаты демонстрируют, что качество закодированных последовательностей с использованием временного масштабирования сравнимо с качеством без применения масштабирования. Кроме того, было выявлено, что функция временного масштабирования в центральном профайле предоставляет лучшие результаты по сравнению с одновременным кодированием в этом же профайле.

Звук

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

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

Работа различных средств кодирования MPEG-4 представлена в таблице ниже. Для лучшей оценки свойств технологии MPEG-4 в тесты были включены несколько кодировщиков от MPEG-2 и ITU-T и их оценка также включены в таблицу. Результаты из различных тестов не следует сравнивать.

При кодировании 5-канального материала при 64 кбит/с/канал (320 кбит/с) Продвинутое кодирование аудио AAC (Advanced Audio Coding) главного профайла было оценено как имеющее "неотличимое качество" (относительно оригинала) согласно определению EBU. При кодировании 2- канального материала при 128 кбит/с как AAC главного профайла так и AAC профайла низкой сложности были оценены как имеющие "неотличимое качество" (относительно оригинала) согласно определению EBU.

Два масштабируемых кодировщика, CELP-база с улучшение AAC, и TwinVQ база с улучшением AAC, работают лучше чем AAC "multicast", работающий при скорости передачи уровня улучшения, но не так хороши как кодировщик AAC, работающий при полной скорости передачи.

Широкополосное кодирующее средство CELP демонстрирует прекрасные характеристики только для голоса.

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

Узкополосный CELP, TwinVQ и индивидуальные гармонические линии и шум (HILN) все могут обеспечить очень высокое сжатие сигнала.

Средства противодействия ошибкам (ER) обеспечивают эквивалентно хорошую устойчивость к ошибкам в широком диапазоне условий канальных ошибок, и делают это с достаточно малой избыточностью по скорости передачи.

Промышленный форум MPEG-4

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

• Целью M4IF будет: продвижение MPEG-4, предоставление информации об MPEG-4, предоставление средств MPEG-4 или указание мест, где эти данные можно получить, формирование единого представления об MPEG-4.
• Цели реализуются через открытое международное сотрудничество всех заинтересованных участников.
• Деятельность M4IF не преследует целей получения финансовой прибыли.
• Любая корпорация и частная фирма, государственный орган или интернациональная организация, поддерживающая цели M4IF может являться членом форума.
• Члены не обязаны внедрять или использовать специфические технологические стандарты или рекомендации в качестве следствия своего членства в M4IF.
• Не существует каких-либо лицензионных требований, налагаемых членством в M4IF, и M4IF не налагает лицензионных ограничений на использование технологии MPEG-4.
• Начальный членский взнос равен 2,000 $ в год.

M4IF имеет свою WEB-страницу: http://www.m4if.org

Деятельность M4IF начинается там, где кончается активность MPEG. Сюда входят позиции, с которыми MPEG не может иметь дело, например, из-за правил ISO, таких как патентная чистота.

Техническое описание MPEG-4 DMIF и системы в деталях

Рисунок 3 иллюстрирует процесс, при котором потоки, исходящие из сети или устройства хранения в виде потоков TransMux, подвергаются демультиплексированию в потоки FlexMux. Затем они направляются к соответствующим демультиплексорам FlexMux, которые извлекают из них элементарные потоки. Эти элементарные потоки (ES) анализируются и направляются к соответствующим декодерам.

Процесс декодирования конвертирует данные в аудио-визуальный (AV) объект и проводит необходимые операции для восстановления первоначального AV объекта, который готов к визуализации на целевом устройстве. Аудио и визуальные объекты представлены в кодированном виде, описании которого можно найти в разделах 10 и 9 соответственно.

После реконструкции AV объект становится доступным для слоя композиции в процессе рендеринга сцены. Декодированные объекты аудио и видео, совместно с данными описания сцены, используются для создания композитной сцены, как описано создателем. При этом пользователь имеет возможность расширять функционал, определенный автором, и взаимодействовать с отображаемой сценой.

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

DMIF

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа:

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

Рис. 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 (канальной меткой), которая служит указателем для канала, через который идет поток. Определение ChannelAssociationTags для реального транспортного канала, а также управление сессией и каналами осуществляется DMIF-частью стандарта MPEG-4.

Во-вторых, входящие потоки должны быть соответствующим образом демультиплексированы, чтобы восстановить 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.

Синхронизация и описание элементарных потоков

Рис. 7. Архитектура буферов модели системного декодера

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

Чтобы элементарные потоки могли взаимодействовать с медиа-объектами в пределах сцены, используются дескрипторы объектов. Дескрипторы объектов передают информацию о номере и свойствах элементарных потоков, которые ассоциированы с конкретными медиа-объектами. Сами дескрипторы объектов передаются в одном или более элементарных потоков, так как допускается добавление и удаление потоков (и объектов) в процессе сессии MPEG-4. Для того чтобы обеспечить синхронизацию, такие модификации помечаются временными метками. Потоки дескрипторов объектов могут рассматриваться как описание потоковых ресурсов презентации. Аналогично, описание сцены также передается как элементарный поток, позволяя модифицировать пространственно-временную картину презентации со временем.

Управление буфером

Чтобы предсказать, как декодер будет себя вести, когда он декодирует различные элементарные потоки данных, которые образуют сессию MPEG-4, модель системного декодера (Systems Decoder Mode) позволяет кодировщику специфицировать и мониторить минимальные буферные ресурсы, необходимые для декодирования сессии. Требуемые буферные ресурсы передаются декодеру в объектных дескрипторах во время установления сессии MPEG-4, так что декодер может решить, может ли он участвовать в этой сессии.

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

Идентификация времени

Для операции реального времени, модель синхронизации is assumed in which the end-to-end delay from the signal output from an encoder to the signal input to a decoder is constant. Более того, передаваемые потоки данных должны содержать времязадающую информацию в явном или неявном виде. Существует два типа временной информации. Первый тип используется для передачи частоты часов кодировщика, или временной шкалы, декодеру. Второй, состоящий из временных меток, присоединенных к закодированным AV данным, содержит желательное время декодирование для блоков доступа или композиции, а также время истечения применимости композиционных блоков. Эта информация передается в заголовках SL-пакетов сформированных в слое sync. С этой временной информацией, интервалы в пределах картинки и частота стробирования аудио может подстраиваться в декодере, чтобы соответствовать интервалам частоте стробирования на стороне кодировщика.

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

Хотя допускается работа систем без какой-либо временной информации, определение модели буферизации в этом случае невозможно.

Улучшенная модель синхронизации (FlexTime)

Модель FlexTime (Advanced Synchronization Model) расширяет традиционную модель хронирования MPEG-4, чтобы разрешить синхронизацию большого числа потоков и объектов, таких как видео, аудио, текст, графика, или даже программы, которые могут иметь разное происхождение.

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

Модель FlexTime позволяет разработчику материала специфицировать простые временные соотношения для выбранных объектов MPEG-4, таких как "CoStart," "CoEnd," и "Meet." Автор материала может также специфицировать ограничения гибкости для объектов MPEG-4, как если бы объекты были растяжимыми пружинами. Это позволяет синхронизовать большое число объектов согласно специфицированным временным соотношениям.

Наибольшую эффективность внедрение этой техники может дать в случае приложений Интернет, где нужно синхронизовать большое число источников на стороне клиента.

Гибкая длительность

В среде с ненадежной доставкой может так случиться, что доставка определенного элементарного потока или частей потока, может заметно задержаться относительно требуемого времени воспроизведения.

Для того чтобы понизить чувствительность к задержке времени доставки, модель FlexTime основывается на так называемой метафоре "пружины", смотри раздел 4.2.3.

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

Относительное время начала и конца

Два или более элементарных потоков или потоков сегментов могут быть синхронизованы друг относительно друга, путем определения того, что они начинаются ("CoStart") или кончаются ("CoEnd") в одно и то же время или завершение одного совпадает с началом другого ("Meet").

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

Модель FlexTime позволяет автору материала выражать синхронизацию объектов MPEG-4 с потоками или сегментами потоков, путем установления временных соотношений между ними.

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

• Компенсировать различные сетевые задержки с помощью поддержки синхронизованной задержки прибытия потока, прежде чем действующее лицо начнет рэндеринг/воспроизведение ассоциированного с ним узла.
• Компенсировать различные сетевые разбросы задержки путем поддержки синхронизованного ожидания прибытия сегмента потока.
• Синхронизовать большое число медиа/BIFS-узлов с некоторым медиа потоком неизвестной длины или неуправляемым временем прибытия.
• Синхронизовать модификации BIFS (например, модификации полей сцены) при наличии большого числа узлов/потоков, когда некоторые потоки имеют неизвестную длину или неуправляемое время прибытия.
• Замедлять или ускорять рэндеринг/воспроизведение частей потоков, чтобы компенсировать ситуации не синхронности, вызванные неизвестной длиной, неуправляемым временем прибытия или его вариацией.

Поддержка FlexTime в MPEG-4

Модель FlexTime поддерживается в MPEG-4 двумя узлами: TemporalTransform и TemporalGroup, и дескриптором: SegmentDescriptor. Узел TemporalTransform специфицирует временные свойства объекта MPEG-4, который нуждается в синхронизации. Узел TemporalGroup специфицирует временные соотношения между объектами, которые представлены узлами TemporalTransform, а SegmentDescriptor идентифицирует доли потока, которые могут быть синхронизованы.

Узел TemporalTransform

TemporalTransform поддерживает синхронизацию узлов в пределах сцены с медиа потоком, или его сегментом, и поддерживает гибкое преобразование ко времени сцены. Этот группирующий узел может гибко поддерживать замедление, ускорение, замораживание или смещение временной шкалы сцены для рэндеринга узлов содержащихся в ней. Его дочернее поле может содержать список узлов типа SF3Dnode, а узел может влиять на замедление, ускорение, замораживание или смещение временной шкалы композитора, когда он осуществляет рэндеринг дочерних узлов, которые преобразованы этим узлом. Кроме того, этот узел имеет поле url, которое может ссылаться на элементарный поток или его сегмент и в этом случае, узел воздействует на временную шкалу потока, указанного в ссылке.

Узел TemporalGroup

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

Дескриптор сегмента (SegmentDescriptor)

Массив SegmentDescriptors добавляется в качестве составного элемента в ES_Descriptor. SegmentDescriptor идентифицирует и помечает сегмент потока, так что отдельные сегменты потока могут быть адресуемы с помощью их полей url в узле TemporalTansform.

Модель исполнения

Временное декодирование и настройка часов медиа потоков в соответствии с временными метками является функцией слоя sync. Модель FlexTime требует небольшого изменения модели буферизации MPEG-4 и декодирования. Декодирование может быть задержано у клиента, по отношению к стандартному времени.

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

Описание синтаксиса

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

Двоичный формат описания сцены BIFS (Binary Format for Scene description)

Кроме обеспечения поддержки кодирования индивидуальных объектов, MPEG-4 предоставляет также возможность создать набор таких объектов в рамках сцены. Необходимая информация композиции образует описание сцены, которая кодируется и передается вместе с медиа-объектами. Начиная с VRML (Virtual reality Modeling Language), MPEG разработал двоичный язык описания сцены, названный BIFS. BIFS расшифровывается как BInary Format for Scenes.

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

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

Рис. 8. Возможная логическая структура сцены

Как объекты позиционируются в пространстве и времени. В модели MPEG-4, аудиовизуальные объекты имеют протяженность в пространстве и во времени. Каждый медиа-объект имеет локальную координатную систему. Локальная координатная система объекта является той, в которой объект имеет фиксированное пространственно-временное положение и шкалу. Локальная координатная система служит в качестве указателя для манипулирования медиа-объектом в пространстве и во времени. Медиа-объекты позиционируются на сцене путем спецификации координатного преобразования из локальной координатной системы объекта в глобальную систему.

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

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

Продвинутый формат BIFS

BIFS версия 2 (продвинутый BIFS) включает в себя следующие новые возможности:

• Моделирование продвинутой звуковой среды в интерактивных виртуальных сценах, где в реальном времени вычисляются такие характеристики как рефлексы в комнате, реверберация, допплеровские эффекты и перегораживание звука объектами, появляющимися между источником и слушателем. Моделирование направленности источника звука позволяет осуществлять эффективное включение звуковых источников в 3-D сцены.
• Анимация тела с использованием на уровне декодера модели тела по умолчанию или загружаемой модели. Анимация тела осуществляется путем посылки анимационных параметров в общем потоке данных.
• Применение хроматических ключей, которые служат для формирования формы маски и значения прозрачности для изображения или видео последовательности.
• Включение иерархических 3-D сеток в BIFS сцен.
• Установление соответствия интерактивных команд и медийных узлов. Команды передаются серверу через обратный канал для соответствующей обработки.
• PROTOs и EXTERNPROTOs >

Взаимодействие с пользователем

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

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

Взаимодействие на стороне сервера включает в себя манипуляцию материалом на стороне отправителя в результате действий пользователя. Это, разумеется, требует наличия обратного канала.

IPR идентификация и защита

MPEG-4 предоставляет механизмы для защиты прав интеллектуальной собственности (IPR). Это достигается путем предоставления кодированных медиа-объектов с опционным набором данных идентификационной интеллектуальной собственности IPI (Intellectual Property Identification), несущим информацию о содержимом, типе содержимого и о владельцах прав на данный материал. Набор данных, если он имеется, является частью дескриптора элементарного потока, который описывает поточную информацию, ассоциированную с медиа-объектом. Номер набора данных, который ассоциируется с каждым медиа-объектом достаточно гибок; другие медиа-объекты могут использовать тот же набор. Предоставление наборов данных позволяет внедрить механизм отслеживания, мониторинга, выставления счетов и защиты от копирования.

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

Данный подход позволяет конструировать и использовать системы IPMP специфичные для доменов (IPMP-S). В то время как MPEG-4 не стандартизует сами системы IPMP, он стандартизует интерфейс IPMP MPEG-4. Этот интерфейс состоит из IPMP-дескрипторов (IPMP-Ds) и элементарных потоков IPMP (IPMP-ES).

IPMP-Ds и IPMP-ESs предоставляют коммуникационный механизм взаимодействия систем IPMP и терминала MPEG-4. Определенные приложения могут требовать нескольких систем IPMP. Когда объекты MPEG-4 требуют управления и защиты, они имеют IPMP-D, ассоциированные с ними. Эти IPMP-Ds указывают на то, какие системы IPMP следует использовать и предоставляют информацию о том, как защищать получаемый материал. (Смотри рис. 9).

Кроме предоставления владельцам интеллектуальной собственности возможности управления и защиты их прав, MPEG-4 предлагает механизм идентификации этих прав с помощью набора данных IPI (Intellectual Property Identification Data Set). Эта информация может использоваться системами IPMP в качестве входного потока процесса управления и защиты.

Рис. 9. Интерфейсы IPMP в системе MPEG-4

Информация содержимого объекта

MPEG-4 позволяет подсоединять к объектам информацию об их материале. Пользователи стандарта могут использовать этот поток данных ‘OCI’ (Object Content Information) для передачи текстовой информации совместно с материалом MPEG-4.

Формат файлов MPEG-4

Формат файла MP4 сконструирован так, чтобы информация MPEG-4 имела легко адаптируемый формат, который облегчает обмены, управление, редактирование и представление медиа-материала. Презентация может быть локальной по отношению к системе осуществляющей этот процесс, или осуществляемой через сеть или другой поточный механизм доставки (TransMux). Формат файлов сконструирован так, чтобы не зависеть от конкретного типа протокола доставки, и в тоже время эффективно поддерживать саму доставку. Конструкция основана формате QuickTime® компании Apple Computer Inc.

Формат файла MP4 сформирован из объектно-ориентированных структур, называемых атомами. Каждый атом идентифицируется тэгом и длиной. Большинство атомов описывают иерархию метаданных, несущих в себе такую информацию как индексные точки, длительности и указатели на медиа данные. Это собрание атомов содержится в атоме, называемом ‘кино атом’. Сами медиа-данные располагаются где-то; они могут быть в файле MP4, содержащемся в одном или более ‘mdat’, в медийных информационных атомах или размещаться вне файла MP4 с доступом через URL.

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

MPEG-J

MPEG-J является программной системой a programmatic system (в противоположность параметрической системе MPEG-4 версия 1), которая специфицирует API для кросс-операций медиа-проигрывателей MPEG-4 с программами на Java. Комбинируя среду MPEG-4 и безопасный исполнительный код, разработчики материала могут реализовать комплексный контроль и механизмы обработки их медиа в рамках аудио-визуальной сессии. Блок-схема плеера MPEG-J в среде системного плеера MPEG-4 показана на рис. 10. Нижняя половинка этого рисунка отображает системный параметрический плеер MPEG-4, называемый также средство презентации (ДП). Субсистема MPEG-J, контролирующая ДП, называется средством приложения (Application Engine), показана в верхней половине рис. 10.

Приложение Java доставляется в качестве отдельного элементарного потока, поступающего на терминал MPEG-4. Оно будет передано MPEG-J, откуда программа MPEG-J будет иметь доступ к различным компонентам и данным плеера MPEG-4. MPEG-J не поддерживает загружаемых декодеров.

По выше указанной причине, группой был определен набор API с различными областями применения. Задачей API является обеспечение доступа к графу сцены: рассмотрение графа, изменение узлов и их полей, и добавление и удаление узлов графа. Менеджер ресурсов API используется для управления исполнением: он обеспечивает централизованное средство управления ресурсами. API терминальных возможностей (Terminal Capability) используется, когда исполнение программы зависит от конфигурации терминала и его возможностей, как статических (которые не меняются во время исполнения) так и динамических. API медийных декодеров (Media Decoders) позволяет контролировать декодеры, которые имеются в терминале. Сетевое API предлагает способ взаимодействия с сетью, являясь прикладным интерфейсом MPEG-4 DMIF.

Рис. 10. Положение интерфейсов в архитектуре MPEG-J