a и b иллюстрируют временные

Рисунок 16a и 16b иллюстрируют временные и пространственные сегменты, содержащие один связный компонент. Рисунок 16c и 16d иллюстрирует временной и пространственный сегменты, состоящие из трех связанных компонент. Заметим, что в последнем случае, дескрипторы и DS, привязанные к сегменту, являются глобальными по отношению к объединению связанных компонент, образующих сегмент. На этом уровне, невозможно индивидуально описать связанные компоненты сегмента. Если связанные компоненты должны быть описаны индивидуально, тогда сегмент разделяется покомпонентно.

DS Сегмента является рекурсивным, то есть, он может быть поделен на субсегменты, и, таким образом, образовать древовидную структуру. Результирующее сегментное дерево используется для определения медиа-источника, временной и/или пространственной структуры аудио-визуального материала. Например, видео программа может быть временно преобразована в ряд сцен различного уровня, снимков, и микро-сегментов; оглавление может, таким образом, генерироваться на основе этой структуры. Подобные стратегии могут использоваться для пространственных и пространственно-временных сегментов.

a и b описывают два примера

Рисунок 15a и 15b описывают два примера декомпозиции без зазоров или перекрытий. В обоих случаях объединение дочерних объектов соответствует в точности временному продолжению родительского, даже если родитель сам не является связанным (смотри пример на Рисунок 15b). Рисунок 15c демонстрирует пример декомпозиции с зазорами, но без перекрытий. Наконец, Рисунок 15d иллюстрирует более сложный случай, где родитель состоит из двух связанных компонентов и его декомпозиция создает три дочерних объекта: первый сам состоит из двух связанных компонентов, остальные два состоят из одного связанного компонента. Декомпозиция допускает зазоры и перекрытия. Заметим, что в любом случае декомпозиция означает, что объединение пространственно-временного пространства, определенного дочерними сегментами, включается в пространство, определенное его сегментом-предшественником (дочерние объекты содержатся в предшественниках).

Рисунок 3. Абстрактное представление возможных

Рисунок 3. Абстрактное представление возможных приложений на основе MPEG-7

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

Главной задачей MPEG-7 будет предоставление новых решений для описания аудио-визуального материала. Таким образом, чисто текстовые документы не являются объектами MPEG-7. Однако аудио-визуальный материал может содержать и сопряженный с ним текст. MPEG-7 будет, следовательно, рассматривать и поддерживать существующие решения, разработанные другими организациями стандартизации для текстовых документов.

Помимо самих дескрипторов на рабочие характеристики системы довольно сильно влияют DB-структуры. Чтобы быстро решить, представляет ли данный материал какой-то интерес, нужно структурировать индексную информацию, например, иерархическим или ассоциативным способом.

1.4. Область применения MPEG-7

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

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

Все области применения, базирующиеся на мультимедиа, выиграют от использования MPEG-7. Ниже предлагается список возможных приложений MPEG-7, которые любой из читателей без труда сможет дополнить:





Архитектура, недвижимость и интерьерный дизайн (например, поиск идей)

Выбор широковещательного медийного канала (например, радио, TV)

Услуги в сфере культуры (исторические музеи, картинные галереи и т.д.)

Цифровые библиотеки (например, каталоги изображений, музыкальные словари, биомедицинские каталоги изображений, фильмы, видео и радио архивы)

E-коммерция (например, целевая реклама, каталоги реального времени, каталоги электронных магазинов)

Образование (например, депозитарии мультимедийных курсов, мультимедийный поиск дополнительных материалов)

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

Исследовательские услуги (например, распознавание человеческих особенностей, экспертизы)

Журнализм (например, поиск речей определенного политика, используя его имя, его голос или его лицо)

Мультимедийные службы каталогов (например, Желтые страницы, туристская информация, географические информационные системы

Мультимедийное редактирование (например, персональная электронная служба новостей, персональная медийная среда для творческой деятельности)

Удаленное опознавание (например, картография, экология, управление природными ресурсами)

Осуществление покупок (например, поиск одежды, которая вам нравится)

Надзор (например, управление движением, транспортом, неразрушающий контроль в агрессивной среде)

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

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

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



Определите объекты, включая цветовые пятна или текстуры и получите образцы, среди которых вы выберете интересующие вас объекты.

Опишите действия и получите список сценариев, содержащих эти действия.

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

1.5. План и метод работы

Метод разработки совместим с тем, что регламентировано в предыдущих стандартах MPEG. Работа над MPEG обычно выполнялась в три этапа: определение, соревнование и сотрудничество. На первой фазе определяется область действия и требования, предъявляемые к стандарту MPEG-7. На следующем этапе участники работают над различными технологиями самостоятельно. Результатом этого этапа является выработка документа CfP (Call for Proposals). В разработке стандарта участвовало около 60 коллективов, было получено 400 предложений.

Выбранные элементы различных предложений на завершающей фазе инкорпорированы в общую модель (eXperimentation Model или XM) стандарта. Целью являлось построение наилучшей модели, которая по существу представляла собой проект стандарта. На завершающей фазе, XM последовательно актуализовалась до тех пор, пока MPEG-7 в октябре 2000 года не достиг уровня CD (Committee Draft). Дальнейшее усовершенствование XM осуществлялось посредством базовых экспериментов (CE - Core Experiments). CE призваны протестировать существующие средства с учетом новых возможностей и предложений. Наконец все части XM (или рабочего проекта), которые соответствуют нормативным элементам MPEG-7, были стандартизованы.

1.6. Части MPEG-7

Стандарт MPEG-7 состоит из следующих частей:

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

Язык описания определений MPEG-7. Язык для определения новых схем описания и, возможно, новых дескрипторов.



MPEG-7 Audio – дескрипторы

и схемы описания, имеющие отношение исключительно к описанию аудио материала.

MPEG-7 Visual – дескрипторы

и схемы описания, имеющие отношение исключительно к описанию визуального материала

MPEG-7 Multimedia Description Schemes - дескрипторы и схемы описания, имеющие отношение к общим характеристикам описаний мультимедиа.

MPEG-7 Reference Software – программные реализации соответствующих частей стандарта MPEG-7

MPEG-7 Conformance – базовые принципы и процедуры тестирования рабочих характеристик практических реализаций MPEG-7.

1.7. Структура документа

Данный обзорный документ делится на 4 части, не считая введения и приложений. Каждая часть делится на несколько секций, характеризующих различные стороны MPEG-7 [2].

секция 2 описывает основные функции,

секция 3 содержит детальное техническое описание, а

секция 4 содержит список FAQ (Frequently Asked Questions).

2. Главные функции MPEG-7

2.1. Системы MPEG-7

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

2.2. Язык описания определений MPEG-7

Согласно определению в MPEG-7 язык описания определений DDL (Description Definition Language) представляет собой:

“... язык, который позволяет формировать новые схемы описания и, возможно, дескрипторы. Он также позволяет расширение и модификацию существующих схем описания”.

В качестве основы DDL был выбран язык XML. Как следствие, DDL может быть поделен на следующие логические нормативные компоненты:

-Структурная схема языковых компонентов XML;

-Компоненты типа данных схемы;

-Специфические расширения MPEG-7.

2.3. Аудио MPEG-7

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



2.4. Визуальный MPEG-7

Средства визуального описания MPEG-7, включенные в CD/ XM состоят из базовых структур и дескрипторов, которые характеризуют следующие визуальные характеристики:

Цвет

Текстура

Форма

Движение

Локализация

Прочие

Каждая категория состоит из элементарных и сложных дескрипторов.

2.5. Основные объекты и схемы описания мультимедиа MPEG-7

Базисом схем описания мультимедиа MDS (Multimedia Description Schemes) является стандартизация набора средств описания (дескрипторы и схемы описания), имеющие дело с общими и мультимедийными объектами.

Общими объектами являются характеристики, которые используются в аудио, видео и текстовых описаниях и, следовательно, характеризуют все медийные типы материала. Такими характеристиками могут быть, например, вектор, время и т.д.

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

Описание материала: представление воспринимаемой информации;

Управление материалом: информация о характере медийного материала, формирование и использование АВ материала;

Организация материала: представление анализа и классификации нескольких AВ материалов;

Поиск и доступ: спецификация кратких характеристик и изменений АВ-материала;

Взаимодействие с пользователем: описание предпочтений пользователя и истории использования мультимедийного материала.

2.6. Эталонные программы MPEG-7: модель экспериментов (eXperimentation Model)

Программное обеспечение модели XM (eXperimentation Model) представляет собой систему моделирования для дескрипторов

MPEG-7 (D), схем описания (DS), схем кодирования (CS), языка описания определений (DDL). Кроме нормативных компонентов, системе моделирования необходимы некоторые дополнительные элементы, существенные при исполнении некоторых процедурных программ.


Структуры данных и процедурные программы образуют приложения. Приложения XM образуют две разновидности: приложения клиента и сервера.

3. Детальное техническое описание стандарта MPEG-7

3.1. Системы MPEG-7

Системы MPEG-7 в настоящее время определяет архитектуру терминала и нормативных интерфейсов.

3.1.1. Архитектура терминала

Представление информации, специфицированное в стандарте MPEG-7 предоставляет средства описаний кодированного мультимедийного материала. Объект, который использует такое кодовое представление мультимедийного материала, называется "терминалом". Этот терминал может соответствовать отдельно стоящему приложению или быть целой прикладной системой. Архитектура такого терминала изображена на Рисунок 4, а его работа описана ниже.

Анимация лица

2.4.7. Анимация лица

Часть стандарта, связанная с ‘анимацией лица’, позволяет посылать параметры, которые помогают специфицировать и анимировать синтезированные лица. Эти модели не являются сами частью стандарта MPEG-4, стандартизированы только параметры.

• Определение и кодирование анимационных параметров лица (модельно независимое):

• Позиции характерных деталей и их ориентация для определения сеток при анимации лица.

• Визуальные конфигурации губ, соответствующие фонемам речи.

• Определение и кодирование параметров описания лица (для калибровки модели):

• 3-D позиции характерных признаков (деталей)

• 3-D калибровочные сетки для анимации головы.

• Текстурная карта лица.

• Персональные характеристики.

• Кодирование лицевой текстуры.

9.8.1. Анимация лица

‘Лицевой анимационный объект’ может использоваться для представления анимированного лица. Форма, текстура и выражения лица управляются параметрами определения лица FDP (Facial Definition Parameters) и/или параметрами анимации лица FAP (Facial Animation Parameters). Объект лица содержит базовый вид лица с нейтральным выражением. Это лицо может уже отображено. Оно может также получить немедленно анимационные параметры из потока данных, который осуществит анимацию лица: выражения, речь и т.д. Между тем, могут быть посланы параметры определения, которые изменять облик лица от некоторого базового к заданному лицу со своей собственной формой и (опционно) текстурой. Если это желательно, через набор FDP можно загрузить полную модель лица.

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

Двоичный формат систем для сцены BIFS (Systems Binary Format for Scenes), предоставляет возможности поддержки анимации лица, когда нужны обычные модели и интерпретации FAP:

Параметры определения лица FDP (Face Definition Parameters) в BIFS (модельные данные являются загружаемыми, чтобы конфигурировать базовую модель лица, запомненную в терминале до д екодирования FAP, или инсталлировать специфическую модель лица в начале сессии вместе с информацией о том, как анимировать лицо).

Анимация тела

3.2.2. Анимация тела

В версии 2 к анимации лица, существовавшей в версии 1, добавлена анимация тела.

9.8.2. Анимация тела

Тело является объектом способным генерировать модели виртуального тела и анимации в форме наборов 3-D многоугольных сеток, пригодных для отображения (rendering). Для тела определены два набора параметров: набор параметров определения тела BDP (Body Definition Parameter), и набор параметров анимации тела BAP (Body Animation Parameter). Набор BDP определяет параметры преобразования тела по умолчанию в требующееся тело с нужной поверхностью, размерами, и (опционно) текстурой. Параметры анимации тела (BAP), если интерпретированы корректно, дадут разумно высокий уровень результата выражаемого в терминах позы и анимации для самых разных моделей тела, без необходимости инициализировать или калибровать модель.

Конструкция объекта тело содержит обобщенное виртуальное человеческое тело в позе по умолчанию. Это тело может быть уже отображено. Объект способен немедленно принимать BAP из потока данных, который осуществляет анимацию тела. Если получены BDP, они используются для преобразования обобщенного тела в конкретное, заданное содержимым параметров. Любой компонент может быть равен нулю. Нулевой компонент при отображении тела заменяется соответствующим значением по умолчанию. Поза по умолчанию соответствует стоящей фигуре. Эта поза определена следующим образом: стопы ориентированы в фронтальном направлении, обе руки размещаться вдоль тела с ладонями повернутыми внутрь. Эта поза предполагает также, что все BAP имеют значения по умолчанию.

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

Стандарт анимации тела был разработан MPEG в сотрудничестве с Рабочей группой анимации гуманоидов (Humanoid Animation Working Group) в рамках консорциума VRML.

Анимируемые D сетки

9.8.3. Анимируемые 2-D сетки

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

Узловые точки динамической сетки отслеживают особенности изображения во времени с помощью соответствующих векторов перемещения. Исходная сетка может быть регулярной, или адаптироваться к характеру изображения, которая называется сеткой, адаптируемой к изображению. Моделирование 2-D сетки, адаптируемая к изображению, соответствует неоднородному стробированию поля перемещения в некотором числе узловых точек вдоль контура и внутри видео объекта. Методы выбора и отслеживания этих узловых точек не является предметом стандартизации.

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

Моделирование 2-D сетки привлекательно, та как 2-D сетки могут сформированы из одного вида объекта, сохраняя функциональность, обеспечиваемую моделированием с привлечением 3-D сеток. Подводя итог можно сказать, что представления с объектно-ориентированными 2-D сетками могут моделировать форму (многогранная апроксимация контура объекта) и перемещение VOP в неоднородной структуре, которая является расширяемой до моделирования 3-D объектов, когда имеются данные для конструирования таких моделей. В частности, представление видео-объектов с помощью 2-D-сетки допускает следующие функции:

A. Манипуляция видео-объектами

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

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

Пространственно-временная интерполяция. Моделирование движения сетки представляет более надежную временную интерполяцию с компенсацией перемещения.

B. Сжатие видео-объекта

Моделирование 2-D сеток может использоваться для сжатия, если выбирается передача текстурных карт только определенных ключевых кадров и анимация этих текстурных карт для промежуточных кадров. Это называется само преображением выбранных ключевых кадров с использованием информации 2-D сеток.

C. Видео индексирование, базирующееся на содержимом

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

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

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

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

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

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

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

Архитектура коммуникаций DMIF

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

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

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

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

к нижнему уровню инфраструктуры доставки

Рисунок 4. Архитектура MPEG-7

В нижней части Рисунок 4 размещена система передачи/записи. Это относится к нижнему уровню инфраструктуры доставки (сетевой уровень и ниже). Эти уровни передают мультиплексированные потоки данных уровню доставки. Транспортная среда MPEG-7 базируется на многих системах доставки данных. Это включает, например, транспортные потоки MPEG-2, IP или MPEG-4 (MP4) файлы или потоки. Уровень доставки реализует механизмы, позволяющие выполнять синхронизацию, формирование кадров и мультиплексирование материала MPEG-7. Материал MPEG-7 может быть доставлен независимо или вместе с данными, которые он описывает. Архитектура MPEG-7 позволяет передавать данные (например, запросы) назад из терминала к отправителю или серверу.

Уровень доставки предоставляет уровню сжатия MPEG-7 элементарные потоки. Элементарные потоки MPEG-7 состоят из последовательности индивидуально доступных порций данных, называемых блоками доступа (Access Units). Блок доступа является наименьшим информационным объектом, к которому может относиться временная информация. Элементарные потоки MPEG-7 содержат данные различной природы:

Схемная информация: эта информация определяет структуру описания MPEG-7;

Информация описаний: эта информация является либо полным описанием мультимедийного материала или фрагментами такого описания.

Уровень доставки приложения может также по запросу доставлять мультимедийный материал. Для этих целей могут использоваться существующие средства доставки.

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



Синтаксис текстуального формата определен в части 2 (DDL - Description Definition Language) стандарта. Синтаксис двоичного формата (BiM - двоичный формат для данных MPEG-7) определен в части 1 (системы) стандарта. Схемы определены в частях 3, 4 и 5 (визуальная, аудио и схемы описания мультимедиа) стандарта.

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

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

3.1.2. Нормативные интерфейсы

3.1.2.1. Описание нормативных интерфейсов

MPEG-7 имеет два нормативных интерфейса, как это показано на Рисунок 5.

Аудио-кодирование с малыми задержками

10.2.2. Аудио-кодирование с малыми задержками

В то время как универсальный аудио кодировщик MPEG-4 очень эффективен при кодировании аудио сигналов при низких скоростях передачи, он имеет алгоритмическую задержку кодирования/декодирования, достигающую нескольких сот миллисекунд и является, таким образом, неподходящим для приложений, требующих малых задержек кодирования, таких как двунаправленные коммуникации реального времени. Для обычного аудио кодировщика, работающего при частоте стробирования 24 кГц и скорости передачи 24 кбит/с, алгоритмическая задержка кодирования составляет 110 мс плюс до 210 мс дополнительно в случае использования буфера. Чтобы кодировать обычные аудио сигналы enable с алгоритмической задержкой, не превышающей 20 мс, MPEG-4 версии 2 специфицирует кодировщик, который использует модификацию алгоритма MPEG-2/4 AAC (Advanced Audio Coding). По сравнению со схемами кодирования речи, этот кодировщик позволяет сжимать обычные типы аудио сигналов, включая музыку, при достаточно низких задержках. Он работает вплоть до частот стробирования 48 кГц и использует длину кадров 512 или 480 значений стробирования, по сравнению с 1024 или 960 значений, используемых в стандарте MPEG-2/4 AAC. Размер окна, используемого при анализе и синтезе блока фильтров, уменьшен в два раза. Чтобы уменьшить артифакты предэхо в случае переходных сигналов используется переключение размера окна. Для непереходных частей сигнала используется окно синусоидальной формы, в то время как в случае переходных сигналов используется так называемое окно с низким перекрытием. Использование буфера битов минимизируется, чтобы сократить задержку. В крайнем случае, такой буфер вообще не используется.

Аудио профайлы

5.2. Аудио профайлы

Определены четыре аудио-профайла в MPEG-4 V.1:

Разговорный профайл предоставляет HVXC, который является параметрическим кодером голоса, рассчитанным на очень низкие скорости передачи, CELP узкополосным/широкополосным кодером голоса, или интерфейсом текст-голос.

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

Масштабируемый профайл, супер набор профайла речи, удобен для масштабируемого кодирования речи и музыки для таких сетей, как Интернет и NADIB (Narrow band Audio DIgital Broadcasting). Диапазон скоростей передачи лежит в пределах от 6 кбит/с до 24 кбит/с, при ширине полосы 3.5 и 9 кГц.

Главный профайл является расширенным супер набором всех других профайлов, содержащий средства для синтетического и естественного аудио.

Еще четыре профайла добавлено в MPEG-4 V.2:

Профайл высококачественного аудио содержит кодировщик голоса CELP и простой кодировщик AAC, содержащий систему долгосрочного предсказания. Масштабируемое кодирование может быть выполнено с помощью AAC масштабируемого объектного типа. Опционно, может использоваться синтаксис потока, устойчивый к ошибкам (ER).

Профайл аудио с низкой задержкой (Low Delay Audio) содержит HVXC и CELP кодировщики голоса (опционно использующие синтаксис ER), AAC-кодеры с низкой задержкой и интерфейс текст-голос TTSI.

Профайл натурального аудио содержит все средства кодирования натурального аудио, доступные в MPEG-4.

Профайл межсетевого мобильного аудио (Mobile Audio Internetworking)

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

Аудио-система

2.3. Аудио-система

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

Речь: Кодирование речи может производиться при скоростях обмена от 2 кбит/с до 24 кбит/с. Низкие скорости передачи, такие как 1.2 кбит/с, также возможны, когда разрешена переменная скорость кодирования. Для коммуникационных приложений возможны малые задержки. Когда используются средства HVXC, скорость и высота тона могут модифицироваться пользователем при воспроизведении. Если используются средства CELP, изменение скорости воспроизведения может быть реализовано с помощью дополнительного средства.

Синтезированная речь: TTS-кодировщики с масштабируемой скоростью в диапазоне от 200 бит/с до 1.2 кбит/с которые позволяют использовать текст или текст с интонационными параметрами (вариация тона, длительность фонемы, и т.д.), в качестве входных данных для генерации синтетической речи. Это включает следующие функции.

Синтез речи с использованием интонации оригинальной речи

Управление синхронизацией губ и фонемной информации.

Трюковые возможности: пауза, возобновление, переход вперед/назад.

Международный язык и поддержка диалектов для текста (т.е. можно сигнализировать в двоичном потоке, какой язык и диалект следует использовать)

Поддержка интернациональных символов для фонем.

Поддержка спецификации возраста, пола, темпа речи говорящего.

Поддержка передачи меток анимационных параметров лица FAP (facial animation parameter).

Общие аудио сигналы. Поддержка общей кодировки аудио потоков от низких скоростей до высококачественных. Рабочий диапазон начинается от 6 кбит/с при полосе ниже 4 кГц и распространяется до широковещательного качества передачи звукового сигнала для моно и многоканальных приложений.

Синтезированный звук: Поддержка синтезированного звука осуществляется декодером структурированного звука (Structured Audio Decoder), который позволяет использовать управление музыкальными инструментами с привлечением специального языка описания.

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

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

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

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

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

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

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

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

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

x8 DCT или DCT адаптирующийся

Рисунок 12. Базовая блок-схема видео-кодировщика MPEG-4

Базовая структура кодирования включает в себя кодирование формы (для VO произвольной формы), компенсацию перемещения и кодирование текстуры с привлечением DCT (используя стандарт 8> x8 DCT или DCT адаптирующийся к форме).

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

• Стандартная оценка и компенсация перемещения, базирующаяся на блоках 8x8 или 16x16 пикселей.

• Глобальная компенсация перемещения, базирующаяся на передаче статического “образа”. Статическим образом может быть большое статическое изображение, описывающее панораму фона. Для каждого изображения в последовательности, кодируются для реконструкции объекта только 8 глобальных параметров перемещения, описывающих движение камеры. Эти параметры представляют соответствующее афинное преобразование образа, переданного в первом кадре.

Базовые моменты при посылке почтовых сообщений

2. Базовые моменты при посылке почтовых сообщений

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

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

1)	При некоторых обстоятельствах кодирование, использованное для данных, может изменить работу почтового шлюза или агента пользователя. В частности, может потребоваться преобразование из base64 в закавыченную печатную форму и обратно. Это может вызвать искажения для последовательностей CRLF, определяющих границы строк в тексте.
2)	Многие системы могут выбрать для хранения и представления текста другое локальное соглашение для обозначения начала новой строки. Это локальное соглашение может не согласовываться с RFC-822, где для этого используется CRLF. Известны системы, где для этой цели применяют один символ CR, один LF, CRLF, или нечто совсем другое. В результате получается, что изолированные CR и LF символы не вполне надежны; они могут быть потеряны или преобразованы некоторыми системами в другие разделители, следовательно, на них нельзя положиться.
3)	Передача нулей (US-ASCII значение 0) проблематична в Интернет-почте. Это по большей части результат введения нулей, используемых в качестве завершающего символа во многих стандартных программных библиотеках реального времени в языке Си. Практика использования нулей в качестве завершающего символа настолько распространена, что нельзя рассчитывать на то, что эти нули будут сохранены в сообщении.
4)	TAB (HT) символы могут быть неверно интерпретированы или автоматически преобразованы в переменное число пробелов. Это неизбежно в некоторых условиях, в особенности тех, которые базируются на символьном наборе US-ASCII. Такое преобразование не рекомендуется, но может случиться и форматы почты не должны полагаться на сохранение символов TAB (HT).
5)	Строки длиннее 76 символов могут быть разорваны или укорочены некоторыми почтовыми агентами. Разрыв строк или укорочение при транспортировке почты не рекомендуется, но избежать этого иногда невозможно. Приложения, которые требуют длинных строк, должны каким то образом делать различие между "мягким" и "жестким" разрывом строки. Простым способом решить эту проблему является применение кодирования с помощью закавыченных строк печатных символов.
6)	Завершающие символы строки (SP и HT) могут быть отброшены некоторыми транспортными агентами, в то время как другие могут дополнить строки этими символами так, что все строки почтового файла обретают равную длину. На присутствие завершающих символов SP или HT рассчитывать не приходится.
7)	Многие почтовые домены используют вариации символьного набора US-ASCII, или работают с символьными наборами типа EBCDIC, который содержит большинство но не все символы из US-ASCII. Корректная трансляция символов в не инвариантный набор не может быть зависимой от конвертирующих шлюзов по дороге. Например, возникает проблема при пересылке информации, обработанной программой uuencodE, через сеть BITNET. Аналогичные проблемы могут возникнуть без прохода через шлюз, так как многие ЭВМ в Интернет используют символьный набор отличный от US-ASCII. Определение печатной строки в X.400 добавляет новые ограничения в некоторых специфических случаях. В частности, символами, которые могут быть пропущены через любые шлюзы, считаются 73 символа. В их число входят прописные и строчные буквы A-Z и a-z, 10 цифр - 0-9 и следующие одиннадцать специальных символов. "'" (US-ASCII десятичное значение 39) "(" (US-ASCII десятичное значение 40) ")" (US-ASCII десятичное значение 41) "+" (US-ASCII десятичное значение 43) "," (US-ASCII десятичное значение 44) "-" (US-ASCII десятичное значение 45) "." (US-ASCII десятичное значение 46) "/" (US-ASCII десятичное значение 47) ":" (US-ASCII десятичное значение 58) "=" (US-ASCII десятичное значение 61) "?" (US-ASCII десятичное значение 63) Максимально переносимое почтовое сообщение имеет короткие строки, содержащие только эти 73 с имвола. Кодирование base64 отвечает этому правилу.
(8)	Некоторые почтовые транспортные агенты искажают данные, которые содержат определенные символьные строки. В частности, одиночный символ точка (".") на строке может быть поврежден в некоторых SMTP реализациях, а строки, которые начинаются с пяти символов "From " (пятым символом является пробел), также могут быть повреждены. Хорошие агенты-отправители могут предотвратить эти искажения путем кодирования данных (например, в закавыченных строках печатных символов в начале строки вместо "From " используется "=46rom " и "=2E" вместо одиночной ".").

Заметим, что приведенный выше список не является рекомендацией для почтовых транспортных агентов. В документе RFC-821 не запрещается заменять символы или разрывать длинные строки. Более того, данный список отражает негативную практику для существующих сетей и программные реализации должны быть устойчивы против таких эффектов, с которыми им придется столкнуться.

DAI-синтаксис на языке СИ

3.4.5. DAI-синтаксис на языке СИ

DMIF V.2 вводит информативное дополнение, который предоставляет синтаксис C/C++ для прикладного интерфейса DMIF, как это рекомендуется API-синтаксисом.

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

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

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

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

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

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

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

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

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

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

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

Детальное техническое описание визуальной секции

9. Детальное техническое описание визуальной секции MPEG-4



Визуальные объекты могут иметь искусственное или натуральное происхождение.

DMIF

2.1. DMIF

DMIF поддерживает следующие функции:

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

Контроль установления каналов FlexMux

Использование однородных сетей между интерактивными партнерами: IP, ATM, мобильные, PSTN, узкополосные ISDN.

3.4. DMIF

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

8.1. 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 ниже.

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

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

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

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

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

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

Доставка потоков данных

1.4. Доставка потоков данных

Синхронизованная доставка потока данных отправителя получателю, использующая различные QoS, доступные в сети, специфицирована в терминах слоя синхронизации и доставки, которые содержат двухслойный мультиплексор (см. Рисунок 2).

Первый слой мультиплексирования управляется согласно спецификации DMIF (Delivery Multimedia Integration Framework). Это мультиплексирование может быть реализовано определенным в MPEG мультиплексором FlexMux, который позволяет группировать элементарные потоки ES (Elementary Streams) с низкой избыточностью. Мультиплексирование на этом уровне может использоваться, например, для группирования ES с подобными требованиями по QoS, чтобы уменьшить число сетевых соединений или значения задержек.

Слой "TransMux" (Transport Multiplexing) на Рисунок 2 моделирует уровень, который предлагает транспортные услуги, удовлетворяющие требованиям QoS. MPEG-4 специфицирует только интерфейс этого слоя, в то время как остальные требования к пакетам данных будут определяться транспортным протоколом. Любой существующий стек транспортных протоколов, например, (RTP)/UDP/IP, (AAL5)/ATM, или MPEG-2 Transport Stream поверх подходящего канального уровня может стать частным случаем TransMux. Выбор оставлен за конечным пользователем или серис-провайдером, и позволяет использовать MPEG-4 с широким спектром операционного окружения.

DS структуры коллекции

Рисунок 24. DS структуры коллекции описывает коллекции аудио-визуального материала, включая отношения (то есть, R AB, RBC, RAC) внутри и между кластерами коллекций

3.5.5.2. Модели

DS моделей

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

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

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

DS UserInteraction

описывает предпочтения пользователей имеющих отношение к использованию AВ-материала, а также историю его использования. Описания АВ-материала в MPEG-7 может быть приведено в соответствие с описаниями предпочтений для того, чтобы выбрать и персонализовать АВ-материал для более эффективного доступа, презентации и использования. DS UserPreference описывает предпочтения для различных типов материала и моделей просмотра, включая зависимость от контекста в терминах времени и места. DS UserPreference описывает также вес относительной важности различных предпочтений, характеристики конфиденциальности предпочтений и будут ли предпочтения изменяться в процессе взаимодействия, агента с пользователем. DS UsageHistory описывает историю действий, предпринятых пользователем мультимедийной системы. Описания истории использования могут пересылаться между клиентами, их агентами, провайдерами материала и оборудованием, и могут быть в свою очередь использованы для определения предпочтений пользователей с учетом характера АВ-материала.

3.6. Эталонные программы: экспериментальная модель

3.6.1. Цели

Программы XM являются основой для эталонных кодов стандарта MPEG-7. Они используют нормативные компоненты MPEG-7:

Дескрипторы (D),

Схемы описания (DS),

Схемы кодирования (Cs),

Язык описания определений DDL (description definition language)

Компоненты систем BiM.

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

3.6.4.4. Класс дескрипторов

Классы дескрипторов несут в себе описательные данные. В программах XM классы для каждого D или DS представляют непосредственно нормативную часть стандарта. Имеются также функции для элементов реализации описаний.

В программах XM имеется два различных способа конструирования классов D или DS. В случае визуальных D, этот класс использует простой подход класса C++. Во всех других случаях этот класс реализуется с помощью общего модуля, который в XM называется GenericDS. Этот класс является интерфейсом между программами C++ XM и реализацией парсера DDL. Здесь используется XML парсер, предоставляющий DOM-API (Data Object Model - Application Programming Interface - прикладной программный интерфейс объектной модели данных). Следовательно, GenericDS является интерфейсом между XM и парсером DOM-API. Управление памятью для описательных данных выполняется посредством библиотеки парсера DOM. Оба подхода могут комбинироваться с помощью функций ImportDDL и ExportDLL

реализованных классов дескриптора C++.

3.6.4.5. Схема кодирования

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


Описание запоминается, с использованием класса GenericDS, который является оболочкой для DOM-API. Следовательно, мы можем использовать библиотеку парсера DOM-API для кодирования и декодирования. Эти функции встроены XM с помощью класса GenericDSCS (CS = схема кодирования). Помимо ASCII-представления XML-файла MPEG-7 стандартизует также двоичное представление описаний (BiM).

Другим подходом является использование визуальной группы MPEG-7. Здесь, каждый D имеет также индивидуальное двоичное представление. Это позволяет специфицировать число бит, которое следует использовать для кодирования индивидуальных элементов описания. Примером может служить число бит, используемых для кодирования каждой ячейки гистограммы.

3.6.4.6. Средство поиска

В качестве средств извлечения и поиска используется ненормативное средство стандарта. Оно берет одно описание из базы данных и одно описание запроса, причем запрос может не соответствовать нормативам MPEG-7 D или DS. Средство поиска анализирует описание и обрабатывает нужные входные данные так, как это требуется для специфицированного приложения.

Средства поиска используются во всех клиентских приложениях, которые являются приложениями поиска и доставки (search & retrieval) и приложениями медиа-транскодирования (media transcoding). В случае приложений поиска и доставки, средство поиска сравнивает два входных описания и вычисляет величину их отличия. Для приложения медиа-транскодирования обрабатываются медиа-данные, то есть, медийная информация модифицируется на основе описания и запроса. Так как медиа данные обрабатываются, средство поиска вызывается из приложения транскодирования.

3.6.5. Типы приложений в XM-программах

3.6.5.1. Извлечение из среды

Выборка из медиа приложения относится к типам приложений выборки. Обычно, все D или DS низкого уровня должны иметь класс приложения этого типа. Как показано на Рисунок 25 это приложение извлекает тестируемые D/DS (DUT) из входных медиа данных. Сначала медиа файл загружается медиа-декодером в мультимедиа-класс, то есть, память.На следующем шагу с помощью средства выборки описание может быть извлечено из мультимедиа-класса. Затем описание проходит через кодировщик и закодированные данные записываются в файл. Этот процесс повторяется для всех мультимедийных файлов медийной базы данных.

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

8.5. Двоичный формат описания сцены 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. Три структуры не обязательно являются статическими; атрибуты узла (например, позиционирующие параметры) могут быть изменены, в то время как узлы могут добавляться, замещаться, или удаляться.

Формат файла MP4 сконструирован так,

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



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

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

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

Формат тела Интернет сообщений

Формат тела Интернет сообщений

Стандарт STD 11, RFC 822 определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII. Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.

Передача текстовых сообщений с символьным набором, отличным от US-ASCII.

Передача сообщений нетекстового формата (например, звукового письма).

Использование комбинированных сообщений, содержащих разнородные части.

Размещение в заголовке информации в символьном наборе, отличном от US-ASCII.

Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию.

Формат записи маршрутной таблицы в MIB

Рисунок 4.4.13.1.3 Формат записи маршрутной таблицы в MIB

Поле место назначения представляет собой IP-адрес конечной точки маршрута. Поле индекс интерфейса определяет локальный интерфейс (физический порт), через который можно осуществить следующий шаг по маршруту. Следующие пять полей (метрика 1-5) характеризуют оценку маршрута. В простейшем случае, например для протокола RIP, достаточно было бы одного поля. Но для протокола OSPF необходимо 5 полей (разные TOS). Поле следующий шаг представляет собой IP-адрес следующего маршрутизатора. Поле тип маршрута имеет значение 4 для опосредованного достижения места назначения; 3 - для прямого достижения цели маршрута; 2 - для нереализуемого маршрута и 1 – для случаев отличных от вышеперечисленных.

Поле протокол маршрутизации содержит код протокола. Для RIP этот код равен 8, для OSPF - 13, для BGP - 14, для IGMP - 4, для прочих протоколов - 1. Поле возраст маршрута описывает время в секундах, прошедшее с момента последней коррекции маршрута. Следующее поле - маска маршрута используется для выполнения логической побитовой операции И над адресом в IP-дейтограммы перед сравнением результата с кодом, хранящимся в первом поле записи (место назначения). Последнее поле маршрутная информация содержит код, зависящий от протокола маршрутизации и обеспечивающий ссылки на соответствующую информацию в базе MIB.

Новым расширением MIB является система удаленного мониторинга сетей (RMON; RFC-1513, -1271). RMON служит для мониторирования сети в целом, а не отдельных сетевых устройств. В RMON предусмотрено 9 объектных групп (см. табл. 4.4.13.1.8).

Функции, зависящие от содержимого (Content-Based)

2.4.3. Функции, зависящие от содержимого (Content-Based)

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

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

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

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

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

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

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

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

в декабре 1999. Существующие средства

3. Главные функции в MPEG-4 версия 2



Версия 2 была зафиксирована в декабре 1999. Существующие средства и профайлы из версии 1 в версии 2 не заменены; новые возможности будут добавлены в MPEG-4 в форме новых профайлов. Системный слой версии 2 обладает обратной совместимостью с версией 1.

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

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

Графические профайлы сцены

5.4. Графические профайлы сцены

Графические профайлы сцены (или профайлы описания сцены), определенные в системной части стандарта, допускают аудио-визуальные сцены только аудио, 2-мерным, 3-мерным или смешанным 2-D/3-D содержимым.

Графический профайл аудио сцены предоставляется для набора графических элементов сцены BIFS для применение исключительно в аудио приложениях. Графический профайл аудио сцены поддерживает приложения типа широковещательного аудио.

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

Графический профайл полной 2-D сцены предоставляется для всех элементов описания 2-D сцены средства BIFS. Он поддерживает такие возможности, как 2-D преобразования и alpha-сглаживание. Графический профайл полной 2-D сцены делает возможными 2-D приложения, которые требуют широкой интерактивности.

Графический профайл полной сцены предоставляет полный набор графических элементов сцены средства BIFS. Графический профайл полной 2-D сцены сделает возможными приложения типа динамического виртуального 3-D мира и игр.

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

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

8.2.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-данных, из-за временного наезда (относительное растяжение или сжатие временных шкал).

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

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

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

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

Интерфейсная модель ключевых

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

Помимо уже используемых выходов, предполагается, что будет также тип выхода, соответствующий входному запросу. На Рисунок 29 этот выход имеет название прочий выход. Возможными приложениями для этого могут быть уточняющие запросы, например, для просматривающих приложений. Однако использование этого выхода все еще не ясно и нуждается в дальнейших исследованиях.

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

3.6.7. Ключевые приложения против приложений реального мира

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

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

8.7. 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 в качестве входного потока процесса управления и защиты.

Использование кодировочных слов в заголовках сообщений

5. Использование кодировочных слов в заголовках сообщений

'encoded-word' может появиться в заголовке сообщения или в заголовке тела секции в соответствии со следующими правилами:

(1)

'encoded-word' может заменить текстовую лексему (как это определено в RFC-822) в любом из полей заголовка Subject или Comments, в любом поле расширения заголовка, или любом поле секции тела MIME, для которого поле тела определено как '*text'. 'encoded-word' может также появиться в любом поле сообщения или секции тела, определенном пользователем ("X-"). Обычный ASCII-текст и 'кодировочные слова' могут появляться совместно в пределах одного и того же поля заголовка. Однако 'кодировочное слово', появляющееся в поле заголовка, определенное как '*text', должно быть отделено от любого смежного 'encoded-word' или 'текста' с помощью LWS (HT|SP|CRLF).

(2)

'encoded-word' может появляться внутри 'комментария', ограниченного "(" и ")", т.е., там, где допустим 'ctext'. Более точно, ABNF-определение (RFC-822) для 'comment' следует скорректировать как:

comment = "(" *(ctext | quoted-pair | comment | encoded-word) ")"

"Q"-кодированное 'encoded-word', которое появляется в комментарии не должно содержать символов "(", ")" или ". 'Кодировочное слово', появляющееся в комментарии должно отделяться от смежного 'encoded-word' или 'ctext' с помощью LWS.

Важно заметить, что комментарии распознаются только внутри структурированных полей тела. В полях, чьи тела определены как '*text', "(" и ")" обрабатываются как обычные символы, а не как разделители комментариев, и применимо правило (1) этой секции. (См. RFC-822, секции 3.1.2 и 3.1.3)

(3)	В качестве замены для объекта 'word' во 'фразе', например, перед адресом в заголовке From, To или Cc. ABNF-определение для 'phrase' RFC-822 приобретает вид: phrase = 1*( encoded-word / word)

В этом случае набор символов, который можно использовать с "Q"-кодированным 'encoded-word' ограничивается до: < ASCII-буква верхнего и нижнего регистров, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_" (ASCII 95.)>. 'Кодировочное слово', которое появляется внутри 'фразы', должно быть отделено от любого смежного 'слова', 'текста' или специального символа ('special') посредством LWS.
Это единственные места, где может появиться 'encoded-word'. В частности:

+ 'encoded-word' не должно появляться в любой части 'addr-spec'.

+ 'encoded-word' не должно появляться в пределах 'quoted-string'.

+ 'encoded-word' не должно использоваться в поле заголовка Received.

+ 'encoded-word' не должно использоваться в параметре MIME поля Content-Type или Content-Disposition, или в любом структурированном поле тела, за исключением 'comment' или 'phrase'.

'Кодированный текст' не должен продолжаться от одного 'encoded-word' к другому. Это предполагает, что секция кодированного текста 'B-encoded-word' будет иметь длину кратную 4 символам; для 'Q-encoded-word', за любым символом "=", который появляется в секции кодированного текста, следуют две шестнадцатеричные цифры.

Каждое 'encoded-word' должно кодировать полное число октетов. 'Кодированный текст' в каждом 'encoded-word' должен быть хорошо оформлен согласно специфицированному кодированию. 'Кодированный текст' не может продолжаться в следующем 'encoded-word'. (Например, "=?charset?Q?=?= =?charset?Q?AB?=" было бы нелегальным, так как два шестнадцатеричные числа "AB" должны следовать за "=" в одном и том же 'encoded-word'.)

Каждое 'encoded-word' представлять собой целое число символов. Многооктетные символы не могут расщепляться между смежными 'кодировочными словами'.

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

Использование этих методов для кодирования нетекстовых данных (напр., изображения или голоса) в данном документе не определено. Применение 'кодировочных слов' для представления строк ASCII-символов допустимо, но не рекомендуется.

и произвольной формы. Введены две

9.11.1. Эффективность кодирования в V.2



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

• Глобальная компенсация перемещения GMC (Global Motion Compensation). Кодирование глобального перемещения для объекта, использующего малое число параметров. GMC основано на глобальной оценке перемещения, деформации изображения, кодировании траектории перемещения и кодировании текстуры для ошибок предсказания.

• Четверть-пиксельная компенсация перемещения улучшает точность схемы компенсации, за счет лишь небольшого синтаксической и вычислительной избыточности. Точное описание перемещения приводит к малым ошибкам предсказания и, следовательно, лучшему визуальному качеству.

В области текстурного кодирования DCT (SA-DCT – адаптивный к форме) улучшает эффективность кодирования объектов произвольной формы. Алгоритм SA-DCT основан на предварительно определенных ортонормальных наборах одномерных базисных функций DCT.

Субъективные оценочные тесты показывают, что комбинация этих методик может дать экономию в необходимой полосе канала до 50% по сравнению с версией 1, в зависимости от типа содержимого и потока данных.

Эффективность сжатия

2.4.2. Эффективность сжатия

Эффективное сжатие видео будет поддерживаться для всех скоростей обмена. Сюда входит компактное кодирование текстур с качеством, регулируемым от уровня “приемлемо” (для высоких сжатий данных) вплоть до “практически без потерь”.

Эффективное сжатие текстур для 2-D и 3-D сеток.

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

Электронная почта

4.5.10 Электронная почта

Электронная почта - наиболее популярный и быстро развивающийся вид общения. Широко используются протоколы электронной почты UUCP (unix-to-unix copy protocol, RFC-976) и SMTP (simple mail transfer protocol; RFC-821, -822, -1351, -1352). Один из протоколов (RFC-822) определяет формат почтовых сообщений, второй (RFC-821) управляет их пересылкой. Имея механизмы промежуточного хранения почты (spooling) и механизмы повышения надежности доставки, протокол smtp базируется на TCP-протоколе в качестве транспортного и допускает использование различных транспортных сред. Он может доставлять сообщения даже в сети, не поддерживающие протоколы TCP/IP. Протокол SMTP обеспечивает как транспортировку сообщений одному получателю, так и размножение нескольких копий сообщения для передачи по разным адресам. Обычно в любом узле Интернет имеется почтовый сервер (MX), который принимает все сообщения и устанавливает их в очередь. Далее производится раскладка сообщений по почтовым ящикам ЭВМ пользователей. Если какая-то ЭВМ не включена, сервер попытается доставить почту позднее (например, через 30 мин). После заданного числа неудачных попыток или по истечении определенного времени (> 4-5 дней) сообщение может быть утрачено. При этом отправитель должен получить уведомление об этом. Над SMTP располагается почтовая служба конкретных вычислительных систем (например, POP3(RFC-1460), IMAP (RFC-2060), sendmail (UNIX), pine, elm (надстройка над sendmail), mush, mh и т.д.). Схема пересылки электронных почтовых сообщений (RFC-821) показана на Рисунок 4.5.10.1.

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

Адреса электронной почты уникальны и однозначно определяют адресата, обладая иногда даже некоторой избыточностью. Символьные адреса электронной почты вполне соответствуют IP-нотации. Электронный почтовый адрес содержит две части, местную и доменную, например, vanja.ivanov@itep.ru (vanya.ivanov - местная). Доменная часть обычно совпадает с символьным IP-именем домена.

Если между отправителем и приемником имеется непосредственная связь, адрес имеет вид имя_пользователя@имя_ЭВМ. Когда приемник находится на ЭВМ, которая не поддерживает SMTP и передача происходит через промежуточный почтовый сервер, то адрес может иметь вид, например, ivanov%имя_удаленной_ЭВМ@имя_сервера (благодаря быстрому развитию Интернет в мире и даже в России такая схема используется сейчас крайне редко). Местная часть адреса определяется пользователем и часто совпадет с его именем или фамилией. Электронный адрес несравненно компактнее традиционных почтовых адресов, которые мы пишем на конвертах. Да и сами возможности электронной почты несравненно богаче почты традиционной. По этой причине можно утверждать, что традиционная почта постепенно будет в ближайшем будущем вытеснена ее электронным аналогом. Схема взаимодействия различных объектов электронной почты показана на Рисунок 4.5.10.1

Каналы пейджерной (слева) и мобильной телефонной сети (справа)

Рисунок 4.1.8.1.2. Каналы пейджерной (слева) и мобильной телефонной сети (справа).

В небольших системах все базовые станции соединены с MTSO(mobile telephone switching office). В больших сетях может потребоваться несколько MTSO, которые в свою очередь управляются mtso следующего уровня и т.д.. Узловая MTSO соединена со станцией коммутируемой телефонной сети. В любой момент времени каждый мобильный телефон логически находится в одной определенной ячейке и управляется одной базовой станцией. Когда телефон покидает ячейку, базовая станция обнаруживает падение уровня сигнала и запрашивает окружающие станции об уровне сигнала для данного аппарата. Управление аппаратом передается станции с наибольшим входным сигналом. Телефон информируется о смене управляющей станции, при этом предлагается переключиться на новый частотный канал (в смежных ячейках должны использоваться разные частотные каналы). Процесс переключения занимает около 300 мсек (handoff), что должно быть практически незаметно для пользователя. Присвоением частот управляет MTSO. Сигнал передатчика падает по мере удаления от центра ячейки, где он должен быть расположен. Там же должен находиться и приемник. В пределах ячейки предусмотрено несколько каналов для приема/передачи, разнесенные по частоте. Эти каналы управляются центральным коммутатором ячейки (MSC – mobile-service switching centre).

В рамках американского стандарта первого поколения AMPS (advanced mobile phone service; 1982) формируется 40 МГц канал в интервале 800-900 МГц. Система использует 832 полнодуплексных каналов. Данный частотный диапазон делится пополам, 20 МГц выделяется для передачи и столько же для приема. Данные диапазоны делятся в свою очередь на 666 двусторонних каналов, каждый по 30 кГц. Эти каналы расщепляются на 21 субканал, сгруппированные по 3. Обычно, как показано на Рисунок 4.1.8.1.1, гексагональные ячейки группируются по 7 (центральная и 6 ее соседей). Имея 666 каналов, можно выделить три набора по 31 каналу для каждой ячейки.
Такая схема удобна в случае возникновения необходимости увеличения числа каналов, для этого достаточно уменьшить размер ячейки – число ячеек увеличится и, как следствие, увеличится число каналов на единицу площади. В хорошо спланированной сети плотность ячеек пропорциональна плотности пользователей. AMPS для разделения каналов использует метод мультиплексирования по частоте.

Каждый мобильный телефон в amps имеет 32-битовый серийный номер и телефонный номер, характеризуемый 10 цифрами. Телефонный номер представляется как код зоны (3 десятичные цифры) и номер подписчика (7 десятичных цифр). Когда телефон включается, он сканирует список из 21 управляющих каналов и находит тот, у которого наиболее мощный сигнал. Управляющая информация передается в цифровой форме, хотя сам голосовой сигнал является аналоговым. При нормальной работе мобильный телефон перерегистрируется в MTSO (mobile telephone switching office) каждые 15 мин.

При осуществлении вызова пользователь набирает номер телефона и нажимает кнопку send. Аппарат посылает набранный номер и свой идентификационный код. Базовая станция принимает вызов и передает его MTSO. Если звонящий является клиентом mtso или ее партнером, ишется свободный канал и мобильный телефон переключается на него, ожидая когда адресат снимет трубку.

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

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

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


В последнее время аналоговая модуляция повсеместно вытесняется цифровой. В Европе принят единый стандарт для систем мобильной связи GSM (groupe special mobile, второе поколение мобильных средств связи). gsm использует диапазоны 900 и 1800 МГц. Это довольно сложный стандарт, его описание занимает около 5000 страниц. Идеологически система имеет много общего с ISDN (например, переадресацию вызовов). GSM имеет 200 полнодуплексных каналов на ячейку, с полосой частот 200 кГц, что позволяет ей обеспечить пропускную способность 270,833 бит/с на канал. Каждый из 124 частотных каналов делится в GSM между восемью пользователями (мультиплексирование по времени). Теоретически в каждой ячейке может существовать 992 канала, на практике многие из них недоступны из-за интерференции с соседними ячейками.

Система мультиплексирования по времени имеет специфическую структуру. Отдельные временные домены объединяются в мультифреймы. Упрощенная схема структуры показана на Рисунок 4.1.8.1.3.

Каноническая модель кодирования

3. Каноническая модель кодирования

Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.

(1)	Создание локальной формы.

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

(2)	Преобразование в каноническую форму.

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

Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.

(3)	Применение транспортного кодирования.

Применяется подходящее для данного тела транспортное кодирование. Заметим, что не существует жесткой связи между типом среды и транспортным кодированием.
В частности, может оказаться вполне приемлемым выбор base64 или закавыченных строк печатных символов.

(4)	Вставление в объект.

Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

(1)	Во многих вариантах преобразование к канонической форме предваряется некоторой трансляцией в самой кодирующей программе, которая непосредственно работает с локальным форматом. Например, локальное соглашение о разрывах строк для текста тел может реализоваться с помощью самого кодировщика, который владеет информацией о характере локального формата.
(2)	Выходные данные кодировщика могут проходить через один или более дополнительных ступеней прежде чем будут переданы в виде сообщения. Выход кодировщика как таковой может не согласовываться с форматами, специфицированными в RFC-822. В частности, если это окажется удобно преобразователю, разрыв линии может обозначаться каким то иным способом, а не CRLF, как этого требует стандарт RFC-822.

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

Content-type: text/foo; charset=bar

Content-Transfer-Encoding: base64

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

Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.

и средства для приложений, работающих

Рисунок 11. Классификация средств и алгоритмов кодирования звука и изображения MPEG-4

"Ядро VLBV" (VLBV - Very Low Bit-rate Video) предлагает алгоритмы и средства для приложений, работающих при скоростях передачи между 5 и 64 кбит/с, поддерживающие последовательности изображений с низким пространственным разрешение (обычно ниже разрешения CIF) и с низкими частотами кадров (обычно ниже 15 Гц). К приложениям, поддерживающим функциональность ядра VLBV относятся:

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

Операции "произвольный доступ", "быстрая перемотка вперед" и " быстрая перемотка назад" для запоминания VLB мультимедиа ДБ и приложений доступа.

Та же самая функциональность поддерживается при высоких скоростях обмена с высокими параметрами по временному и пространственному разрешению вплоть до ITU-R Rec. 601 и больше – используя идентичные или подобные алгоритмы и средства как в ядре VLBV. Предполагается, что скорости передачи лежат в диапазоне от 64 кбит/с до 10 Мбит/с, а приложения включают широковещательное мультимедиа или интерактивное получение сигналов с качеством, сравнимым с цифровым телевидением.

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

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

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

Кодирование

4. Кодирование

Первоначально легальными значениями кодирования являются "Q" и "B". Эти кодировки описаны ниже. Кодирование "Q" рекомендуется для использования, когда большинство символов, которые нужно преобразовать, представлены в наборе ASCII; в противном случае, следует использовать "B"-кодирование. Несмортя ни на что программа, читающая почту, которая воспринимает кодировочные слова, должна быть способна обрабатывать любые кодировки для любых символьных наборов, которые она поддерживает.

В кодированном тексте может использоваться только субнабор печатных ASCII-символов. Символы SP и HT не допустимы, чтобы начало и конец кодировочного слова были выделены однозначно. Символ "?" используется в “кодировочном слове” для разделения различных частей этого слова друг от друга. По этой причине "?" не может появляться в секциях “кодировочного слова”. Другие символы могут также оказаться нелегальными в определенном контексте. Например, 'encoded-word' во 'фразе', предшествующей адресу в поле заголовка From не может содержать какие-либо специальные символы ("specials"), определенные в RFC-822. Наконец, некоторые другие символы также недопустимы в определенных контекстах, это связано с необходимостью обеспечить надежность пересылки сообщений через почтовые шлюзы.

"B"-кодирование автоматически отвечает этим требованиям. "Q"-кодирование допускает использование широкого перечня печатных символов в некритических позициях заголовка сообщения (например, в Subject), с ограниченным списком символов, допустимых в других полях.

4.1. "B"-кодирование

"B"-кодирование идентично "BASE64", описанному RFC-2045.

4.2. "Q"-кодирование

"Q"-кодирование подобно закавыченным строкам печатных символов ("Quoted-Printable"), описанным в RFC-2045. Оно создано, для того чтобы позволить читать текст, содержащему по большей части ASCII-символы, а алфавитно-цифровом терминале без декодирования.

(1)	Любой 8- битовый код может быть представлен с помощью символа "=", за которым следуют два шестнадцатеричных числа. Например, если бы используемый символьный набор был ISO-8859-1, символ "=" кодировался как "=3D", а пробел (SP) как "=20". (Для шестнадцатеричных чисел следует использовать верхний регистр "A" - "F".)
(2)	8-битовое шестнадцатеричное число 20 (напр., ISO-8859-1 SPACE) может быть представлено как "_" (знак подчеркивания, ASCII 95.). (Этот символ может не пройти через некоторые почтовые шлюзы, но его использование существенно улучшает читаемость "Q"-кодированных данных в почтовых системах, которые поддерживают этот вид кодирования). Заметим, что "_" всегда представляется шестнадцатеричным кодом 20, даже если символ пробел (SPACE) занимает другую кодовую позицию в используемом символьном наборе.
(3)	8-битовые значения, которые соответствуют печатным ASCII-символам, отличным от "=", "?" и "_", могут быть представлены самими собой. Об ограничениях см. раздел 5. В частности, SP и HT не должны представляться самими собой в пределах кодировочных слов.

Кодирование D полигональных сеток

3.2.3. Кодирование 3-D полигональных сеток

Версия 2 MPEG-4 предоставляет набор средств для кодирования многогранных 3-D сеток. Многогранные сетки широко используются для представления 3-D объектов.

Кодирование D сеток с нечетко выраженной структурой

2.4.8. Кодирование 2-D сеток с нечетко выраженной структурой

• Предсказание, базирующееся на сетке, и трансфигурация анимационных текстур

• 2-D-формализм с регулярной сеткой и отслеживанием перемещения анимированных объектов

• Предсказание перемещения и отложенная передача текстуры с динамическими сетками.

• Геометрическое сжатие для векторов перемещения:

• 2-D сжатие сетки с неявной структурой и реконструкция в декодере.

Кодирование формы и Alpha-представление

2.4.5. Кодирование формы и Alpha-представление

Кодирование формы будет поддерживаться, чтобы помочь описанию и композиции изображений и видео, а также видео-объектов произвольной формы. Приложения, которые используют двоичные побитовые карты изображения, служат для презентаций баз данных изображений, интерактивных игр, наблюдения, и анимации. Предлагаются эффективные методы кодирования двоичных форм. Двоичная альфа-маска определяет, принадлежит или нет пиксель объекту. Она может быть включена (‘on’) или выключена (‘off’).

‘Серая шкала’ или ‘alpha’ кодирование формы

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

Кодирование нескольких видов и большого числа вспомогательных компонентов

9.8. Кодирование нескольких видов и большого числа вспомогательных компонентов

В MPEG-4 видео версии 1 поддерживается до одного альфа-канала на видео канальный слой и определены три типа формы. Все три типа формы, т.е. двоичная форма, постоянная форма и форма с серой шкалой, допускают прозрачность видео объекта. При таком определении MPEG-4 не может эффективно поддерживать такие вещи как многовидовые видео объекты (Multiview Video Objects). В версии 2 введено применение множественных альфа-каналов для передачи вспомогательных компонент.

Базовой идеей является то, что форма с серой шкалой не является единственной для описания прозрачности видео объекта, но может быть определена в более общем виде. Форма с серой шкалой может, например, представлять:

Форму прозрачности

Форму несоразмерности (Disparity shape) для многовидовых видео объектов (горизонтальных и вертикальных)

Форму глубины (Depth shape) (получаемую посредством лазерного дальномера или при анализе различия)

Инфракрасные или другие вторичные текстуры

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

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

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

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

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

Кодирование текстур и статические изображения

9.7. Кодирование текстур и статические изображения

Следующие три новых средства кодирования текстур и статических изображений предлагается в версии V.2:

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

Масштабируемое кодирование формы позволяет кодировать текстуры произвольной формы и статические изображения с привлечением масштабируемости. Используя это средство, декодер может преобразовать изображение произвольной формы с любым желательным разрешением. Это средство позволяет приложению использовать объектно-ориентированную пространственную и качественную масштабируемость одновременно.

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

Упомянутые выше средства используются в двух новых ‘продвинутых масштабируемых текстурах’ и продвинутом центральном профайле (advanced core profile).

Кодирование текстур в статических изображениях

9.12. Кодирование текстур в статических изображениях

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

"Локальная" и "интегрированная" координатная система

Рисунок 7. "Локальная" и "интегрированная" координатная система

3.4.1.5. Временная интерполяция

TemporalInterpolation D описывает временную интерполяцию, использующую связанные многогранники. Это может использоваться для аппроксимации многомерных значений переменных, которые меняются со временем, такие как положение объекта в видео. Размер описания временной интерполяции обычно много меньше, чем описание всех величин. На Рисунок 8 25 реальных величин представлены пятью линейными интерполяционными функциями и двумя квадратичными интерполяционными функциями. Начало временной интерполяции всегда привязывается ко времени 0.

Маршрутная политика

4.4.11.7 Маршрутная политика

Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики:

оповещение (announce) и

восприятие (accept).

Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (AS) может работать только один внутренний протокол маршрутизации (IGP), а обмен маршрутной информацией между автономными системами происходит в соответствии с внешним протоколом маршрутизации (EGP). Эта идея продемонстрирована на Рисунок 4.4.11.4.1. ЭВМ (или узлы) A1,B1,C1,D1 и маршрутизатор G-1 составляют одну автономную систему, а A2,B2,C2,D2,E2 и маршрутизатор G-2 - вторую.

Масштабируемое кодирование видео-объектов

9.4. Масштабируемое кодирование видео-объектов

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

9.13. Масштабируемое кодирование видео-объектов

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

• уменьшенной сложностью декодера и следовательно ухудшенным качеством

• уменьшенным пространственным разрешением

• уменьшенным временным разрешением

• равным временным и пространственным разрешением, но с ухудшенным качеством.

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

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

Масштабируемость гранулярности

10.2.3. Масштабируемость гранулярности

Масштабируемость скорости передачи, известная как встроенное кодирование, является крайне желательной функцией. Обычный аудио кодировщик версии 1 поддерживает масштабируемость с большими шагами, где базовый уровень потока данных может комбинироваться с одним или более улучшенных уровней потока данных, чтобы можно было работать с высокими скоростями и, таким образом, получить лучшее качество звука. В типовой конфигурации может использоваться базовый уровень 24 кбит/с и два по 16 кбит/с, позволяя декодирование с полной скоростью 24 кбит/с (моно), 40 кбит/с (стерео), и 56 кбит/с (стерео). Из-за побочной информации передаваемой на каждом уровне, малые уровни-добавки поддерживаются в версии 1 не очень эффективно. Чтобы получить эффективную масштабируемость с малыми шагами для стандартного аудио кодировщика, в версии 2 имеется средство побитового арифметического кодирования BSAC (Bit-Sliced Arithmetic Coding). Это средство используется в комбинации с AAC-кодированием и замещает бесшумное кодирование спектральных данных и масштабных коэффициентов. BSAC предоставляет масштабируемость шагами в 1 кбит/с на аудио канал, т.е. шагами по 2 кбит/с для стерео сигнала. Используется один базовый поток (уровень) данных и много небольших потоков улучшения. Базовый уровень содержит общую информацию вида, специфическую информацию первого уровня и аудио данные первого уровня. Потоки улучшения содержат только специфические данные вида и аудио данные соответствующего слоя. Чтобы получить масштабируемость с небольшими шагами, используется побитовая схема a квантования спектральных данных. Сначала преобразуемые спектральные величины группируются в частотные диапазоны. Каждая из этих групп содержит оцифрованные спектральные величины в их двоичном представлении. Затем биты группы обрабатываются порциями согласно их значимости. Таким образом сначала обрабатываются все наиболее значимые биты (MSB) оцифрованных величин в группе и т.д. Эти группы бит затем кодируются с привлечением арифметической схемы кодирования, чтобы получить энтропийные коды с минимальной избыточностью. Представлены различные модели арифметического кодирования, чтобы перекрыть различные статистические особенности группировок бит.

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

Масштабируемость текстур изображений и видео

2.4.4. Масштабируемость текстур изображений и видео

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

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

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

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

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

Масштабируемость, зависящая от изображения

9.8.5. Масштабируемость, зависящая от изображения

Масштабируемость, зависящая от вида, делает возможными текстурные карты, которые используются реалистичных виртуальных средах. Она состоит в учете точки наблюдения в виртуальном 3-D мире для того чтобы передать только видимую информацию. Только часть информации затем пересылается, в зависимости от геометрии объекта и смещения точки зрения. Эта часть вычисляется как на стороне кодировщика, так и на стороне декодера. Такой подход позволяет значительно уменьшить количество передаваемой информации между удаленной базой данных и пользователем. Эта масштабируемость может работать с кодировщиками, базирующимися на DCT.

Менеджмент и идентификация интеллектуальной собственности

1.6. Менеджмент и идентификация интеллектуальной собственности

Важно иметь возможность идентифицировать интеллектуальную собственность в MPEG-4 медиа-объектах. Полный перечень требований для идентификации интеллектуальной собственности можно найти на базовой странице MPEG в разделе ‘Management and Protection of Intellectual Property’.

MPEG-4 включает в себя идентификацию интеллектуальной собственности путем запоминания уникальных идентификаторов, которые выданы международными системами нумерации (например ISAN, ISRC, и т.д. [ISAN: International Audio-Visual Number, ISRC: International Standard Recording Code]). Эти числа могут использоваться для идентификации текущего владельца прав медиа-объекта. Так как не все содержимое идентифицируется этим числом, MPEG-4 версия 1 предлагает возможность идентификации интеллектуальной собственности с помощью пары ключевых значений (например:”композитор“/”John Smith“). Кроме того, MPEG-4 предлагает стандартизованный интерфейс, который тесно интегрирован с системным слоем для людей, которые хотят использовать системы, контролирующие доступ к интеллектуальной собственности. С этим интерфейсом системы контроля прав собственности могут легко интегрироваться со стандартизованной частью декодера.

Многоцелевое расширение почты Интернет (MIME)

4.4.14.4 Многоцелевое расширение почты Интернет (MIME)

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

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

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

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

Модель материала, профайла и копии

Рисунок 14. Модель материала, профайла и копии

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

Медиа информация. Физический формат материала описывается DS медиа информации. Одна копия описания DS будет ассоциирована с одним материалом.

Медиа профайл. Один объект может иметь один или более профайлов, которые соответствуют различным схемам кодирования. Один из профайлов является оригинальным, он называется мастерным профайлом, который соответствует первоначально созданному или записанному материалу. Другие будут получаться перекодированием из мастерного. Если материал закодирован тем же кодирующим средством, но с другими параметрами, формируется другой медиа-профайл.

Медиа копия. Медиа-объект может быть поставлен в соответствие физическому объекту, называемому медиа-копией. Медиа-копия специфицируется идентификатором или локатором.>

CreationInformation. Информация о процессе формирования материала описывается DS CreationInformation. Одна копия описания DS будет ассоциирована с одним материалом.

UsageInformation. Информация об использовании материала описывается DS UsageInformation. Одна копия описания DS будет ассоциирована с одним материалом.

Единственной частью описания, которая зависит от среды записи или формата кодирования является MediaInformation, описанная в этом разделе. Остальная часть описания MPEG-7 не зависит от профайлов или копий и, как следствие, может использоваться, чтобы описать все возможные копии материала.

3.5.2.1. Средства описания среды

Описание среды включает в себя один элемент верхнего уровня, DS MediaInformation. Оно состоит из опционного MediaIdentification D и одного или нескольких MediaProfile D

Идентификация среды (Media Identification) D содержит средства описания, которые являются специфическими по отношению к идентификации аудио-визуального материала вне зависимости от имеющихся различных копий.

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

MediaFormat D содержит средства описания, которые являются специфическими для формата кодирования медиа-профайла.

MediaInstance D содержит средства описания, которые идентифицируют и локализуют различные копии медиа-профайлов.

MediaTranscodingHints D содержит средства описания, которые специфицируют рекомендации по транскодированию для описываемого материала. Целью этого D (дескриптора) является улучшение качества и сокращение сложности транскодирующих приложений. Рекомендации по транскодированию могут использоваться в виде схем оценки кодирования с целью снижения вычислительной сложности.

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

3.5.2.2. Создание и производство средств описания

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

Описание формирования и производства материала содержит в качестве элемента верхнего уровня, DS CreationInformation, который состоит из одного Creation D, нуля или одного Classification D, и нуля или нескольких RelatedMaterial D.

Creation D содержит средства описания, имеющие отношение к формированию материала, включая место, дату, действия, материалы, персонал (технический и творческий) и организации, участвовавшие в процессе.



Classification D содержит средства описания, которые позволяют классифицировать аудио-визуальный материал. Classification D используется для описания классификации аудио-визуального материала. Это позволяет осуществлять поиск и отбор на основе предпочтений пользователя, ориентируясь на классификации пользователя (например, по языку, стилю, жанру и т.д.) и на классификации услуг (например, на цель, патентную защиту, сегментацию рынка, медиа ревью и т.д.).

Related Material D содержит средства описания, имеющие отношение к дополнительной информации о аудио-визуальном материале, имеющемся в других материалах.

3.5.2.3. Средства описания использования содержимого

Средства описания информации об использовании материала предоставляют данные о процессе использования аудио-визуального материала.

Описание данных об использовании обеспечивается посредством DS UsageInformation, который может включать один Rights D, нуль или один Financial D и нуль или несколько Availability D и UsageRecord D.

Важно заметить, что описание DS UsageInformation предполагает добавление новых описаний, каждый раз, когда материал используется (например, DS UsageRecord, доход в Financial D), или когда имеются другие способы доступа к материалу (например, Availability D).

Rights D предоставляет доступ к информации о правах владельцев и правах доступа.

Financial D содержит информацию, относящуюся к издержкам и доходам от полученного аудио-визуального материала. Понятия частичных издержек и доходов позволяют классифицировать различные издержки и доходы, в зависимости от их типа. Итоговые издержки и доходы вычисляются приложением на основе указанных выше составляющих.

Availability D содержит средства описания, относящиеся к доступности использования материала.

DS UsageRecord содержит средства описания, относящиеся к прошлому использованию материала.

3.5.3. Описание содержимого

3.5.3.1. Описание структурных аспектов содержимого

Основным элементом этой части описания является DS сегмента.


Она относится к описанию физического и логического аспектов аудио- визуального материала. DS сегмента может использоваться для формирования сегментных деревьев. MPEG-7 специфицирует также DS графа,

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

Сегмент представляет собой секцию аудио-визуального материала. DS сегмента является абстрактным классом (в смысле объектно-ориентированного программирования). Она имеет девять основных подклассов: DS мультимедийного сегмента, DS аудио-визуальной области, DS аудио-визуального сегмента, DS аудио сегмента, DS статической области, DS статической 3D-области, DS подвижной области, DS видео сегмента и

DS электронной раскраски. Следовательно, она может иметь как пространственные, так и временные свойства. Временной сегмент может быть набором фрагментов аудио-визуальной последоватеьности, представленным DS аудио сегмента, набором кадров видео последовательности, представленным DS

видео сегмента или комбинацией аудио и видео информации, охарактеризованной DS аудио-визуального сегмента. Пространственный сегмент может быть областью изображения или кадром в визуальной последовательности, представленным DS статической области для 2D-областей и DS статической области 3D для 3D-областей. Пространственно временной сегмент может соответствовать подвижной области в видеопоследовательности, представленной DS подвижной области

или более сложной комбинацией визуального и аудио материала, представленного, например, DS аудио-визуальной области. InkSegment DS описывает временной интервал или сегмент электронной раскраски, который соответствует набору чернильных капель, выбрасываемых из сопла. Наконец, наиболее общим сегментом является DS мультимедийного сегмента, который описывает составные сегменты, образующие мультимедийную презентацию. DS сегмента

является абстрактным и не может быть отображен сам по себе: он используется для определения общих свойств его подклассов.


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

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

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

На Рисунок 16 проиллюстрированы несколько примеров временных или пространственных сегментов и их связности.

Рисунок 2. Модель системного слоя

Рисунок 2. Модель системного слоя MPEG-4

Использование мультиплексора FlexMux является опционным и, как показано на Рисунок 2, этот слой может быть пустым, если нижележащий TransMux предоставляет все необходимые функции. Слой синхронизации, однако, присутствует всегда. С учетом этого возможно:

идентифицировать модули доступа, транспортные временные метки и эталонную временную информацию, а также регистрировать потерю данных.

опционно выкладывать данные от различных элементарных потоков в потоки FlexMux

передавать управляющую информацию:

индицировать необходимый уровень QoS для каждого элементарного потока и потока FlexMux;

транслировать данные требования QoS в действительные сетевые ресурсы;

ассоциировать элементарные потоки с медиа-объектами

передавать привязку элементарных потоков к FlexMux и TransMux каналам

Модемы

4.3.7 Модемы

Само название этого прибора происходит от имеющихся в нем модулятора и демодулятора. Современный модем можно отнести к числу устройств с наибольшим числом современных технологий на кубический сантиметр. Разнообразие модемов огромно. Они различаются по конструкции, по используемым протоколам, по характеру интерфейсов и т.д. Основное назначение модема оптимальное преобразование цифрового сигнала в аналоговый для передачи его по каналу связи и, соответственно, обратное преобразование на принимающей стороне. Под “оптимальным преобразованием” понимается такое, которое обеспечивает надежность связи, улучшает отношение сигнал шум и как следствие пропускную способность канала. Это преобразование необходимо для обеспечения улучшения отношения сигнал-шум. В качестве канала передачи данных может быть использована городская телефонная сеть, выделенная линия или радио-канал. Схема взаимодействия модемов показана на Рисунок 4.3.7.1.

Мониторирование QoS

3.4.2. Мониторирование QoS

DMIF V.2 вводит концепцию мониторирования качества обслуживания (QoS). Реализуемого в сети. Интерфейс DMIF-приложения был соответственно расширен. Модель допускает до трех различных режимов мониторирования QoS: непрерывное мониторирование, контроль специфических очередей, и наблюдение за нарушениями QoS

MPEG-J

8.10. 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.

Мультикастинг и MBONE

4.4.9.1 Мультикастинг и MBONE

MBONE - это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются "туннелями". Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году.

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

Мультикастинг-маршрутизатор при посылке пакета через туннель подготавливает IP-пакет с заголовком, который содержит адрес маршрутизатора-партнера на другом конце туннеля, при этом поле IP-протокола содержит код 4 (IP). Маршрутизатор-приемник извлекает вложенный мультикастинг-пакет и направляет далее, если это требуется.

MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с.

Каждый туннель имеет определенный порог для переменной времени жизни пакета (time-to-live - TTL). Согласно договоренности (IETF) широкополосная видео-информация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видео-пакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, существующему в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами. Следует помнить, что маршрутизатор не откликнется ICMP-сообщением "время истекло", когда TTL достигнет нуля, так как вообще дейтограммы с мультикастинг-адресами не вызывают ICMP-откликов. Увеличивая TTL, прикладной процесс может расширять "зону взаимодействия". Сначала дейтограмма может посылаться с TTL=1, если отклика не получено, c TTL=2 и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает.

Конфигурация системы в режиме мультикастинга производится автоматически. Для того чтобы изменить конфигурацию системы, или добавить еще один туннель используются специальные конфигурационные команды, которые записываются в /etc/mrouted.conf. Существует два типа таких команд:

phyint <local-addr> [disable] [metric <m>] [threshold <t>]

tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>]

Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<local-addr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Последняя команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1.

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

Надежность в средах, подверженных ошибкам

2.4.6. Надежность в средах, подверженных ошибкам

Устойчивость к ошибкам будет поддерживаться, чтобы обеспечить доступ к изображениям и видео через широкий спектр систем памяти и передающих сред. Это включает в себя операции алгоритмов сжатия данных в среде, подверженной сбоям при низких скоростях передачи (т.e., меньше чем 64 Кбит/с).

Натуральные текстуры, изображения и видео

9.2. Натуральные текстуры, изображения и видео

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

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

Эффективного сжатия изображений и видео

Эффективного сжатия текстур для их отображения на 2-D и 3-D сетки

Эффективного сжатия для 2-D сеток

Эффективного сжатия потоков, характеризующих изменяющуюся со временем геометрию (анимация сеток)

Эффективного произвольного доступа ко всем типам визуальных объектов

Расширенной манипуляции изображениями и видео последовательностей

Кодирования, зависящего от содержимого изображений и видео

Масштабируемости текстур, изображений и видео

Пространственная, временная и качественная масштабируемость

Обеспечения устойчивости к ошибкам в среде предрасположенной к сбоям

Натуральный звук

10.1. Натуральный звук

MPEG-4 стандартизирует кодирование естественного звука при скоростях передачи от 2 кбит/с до 64 кбит/с. Когда допускается переменная скорость кодирования, допускается работа и при низких скоростях вплоть до 1.2 кбит/с. Использование стандарта MPEG-2 AAC в рамках набора средств MPEG-4 гарантирует сжатие аудио данных при любых скоростях вплоть до самых высоких. Для того чтобы достичь высокого качества аудио во всем диапазоне скоростей передачи и в то же время обеспечить дополнительную функциональность, техники кодирования голоса и общего аудио интегрированы в одну систему:

• Кодирование голоса при скоростях между 2 и 24 кбит/с поддерживается системой кодирования HVXC (Harmonic Vector eXcitation Coding) для рекомендуемых скоростей 2 - 4 кбит/с, и CELP (Code Excited Linear Predictive) для рабочих скоростей 4 - 24 кбит/с. Кроме того, HVXC может работать при скоростях вплоть до 1.2 кбит/с в режиме с переменной скоростью. При кодировании CELP используются две частоты стробирования, 8 и 16 кГц, чтобы поддержать узкополосную и широкополосную передачу голоса, соответственно. Подвергнуты верификации следующие рабочие режимы: HVXC при 2 и 4 кбит/с, узкополосный CELP при 6, 8.3, и 12 кбит/с, и широкополосный CELP при 18 кбит/с.

• Для обычного аудио кодирования при скоростях порядка и выше 6 кбит/с, применены методики преобразующего кодирования, в частности TwinVQ и AAC. Аудио сигналы в этой области обычно стробируются с частотой 8 кГц.

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

это данные, которые должны быть

Рисунок 5. Нормативные интерфейсы MPEG-7

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

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

Интерфейс текстового формата. Этот интерфейс описывает формат текстуальных блоков доступа. Текстовый декодер MPEG-7 воспринимает поток таких блоков доступа и реконструирует описание материала нормативным способом.

Интерфейс двоичного формата. Этот интерфейс описывает формат двоичных блоков доступа. Двоичный декодер MPEG-7 воспринимает поток таких блоков доступа и реконструирует описание материала нормативным способом.

Двоичный/текстовый декодер MPEG-7.

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

3.1.2.2. Верификация стандарта

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

---

---