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

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

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

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

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

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

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

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

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

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

Для операции реального времени предполагается модель синхронизации, в которой задержка от выхода кодировщика до входа декодера остается постоянной. Более того, передаваемые потоки данных должны содержать времязадающую информацию в явном или неявном виде. Существует два типа временной информации. Первый тип используется для передачи декодеру временной шкалы или частоты часов кодировщика. Второй, состоящий из временных меток, присоединенных к закодированным AV (аудио-видео) данным, содержит желательное время декодирования для блоков доступа или композиции, а также время истечения применимости композиционных блоков. Эта информация передается в заголовках SL-пакетов, сформированных в слое sync. С такой временной информацией интервалы в пределах картинки и частота стробирования аудио могут подстраиваться в декодере, чтобы соответствовать интервалам частоты стробирования на стороне кодировщика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. компенсировать различные сетевые задержки с помощью ожидания прибытия потока, прежде чем действующий объект активизирует рэндеринг/воспроизведение ассоциированного с ним узла;
2. компенсировать различные сетевые разбросы задержки путем ожидания прибытия сегмента потока;
3. синхронизовать большое число медиа/BIFS-узлов с некоторым медиа-потоком неизвестной длины или неуправляемым временем прибытия;
4. синхронизовать модификации BIFS (например, модификации полей сцены) при наличии большого числа узлов/потоков, когда некоторые потоки имеют неизвестную длину или неуправляемое время прибытия;
5. замедлять или ускорять рэндеринг/воспроизведение частей потоков, чтобы компенсировать ситуации несинхронности, вызванные неизвестной длиной, неуправляемым временем прибытия или его вариацией.

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

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

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

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

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

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

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

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

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

Двоичный формат описания сцены BIFS

Кроме обеспечения поддержки кодирования индивидуальных объектов, MPEG-4 предоставляет также возможность создать набор таких объектов в рамках сцены. Необходимая информация композиции образует описание сцены, которая кодируется и передается вместе с медиаобъектами. Начиная с VRML (Virtual Reality Modeling Language), MPEG разработал двоичный язык описания сцены, названный BIFS. BIFS расшифровывается как BI nary F ormat for S cenes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MPEG-J

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

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

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

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