Предпосылки создания стандарта

Эталон МРЕG-4 базируется на 3-х китах:

1) цифровое телевидение;

2) интерактивные графические приложения;

3) интерактивные мультимедийные приложения.

Тенденция последних лет — сближение, слияние этих источников аудиовизуальной инфы, возникновение новых источников как натурального, так и синтезированного контента (содержания). До недавнешнего времени в вещании преобладала концепция «телевидения» - программка готовилась в студии и передавалась как повторяющаяся последовательность Предпосылки создания стандарта строк изображения и сопутствующих звуков. Все усовершенствования, включая возникновение цифрового вещания и эталона МРЕG-2, не изменили эту концепцию в корне, хотя добавили к ней некие новые нюансы — многопрограммность, подписку, дополнительные услуги, зачатки интерактивности. Но похоже на то, что на данный момент обычная концепция телевидения не удовлетворяет уже юзеров аудиовизуальных услуг. Зрители Предпосылки создания стандарта желают иметь доступ к видео- и аудиопрограммам, как они уже имеют доступ к мультимедийному контенту через Веб и World Wide Web - «Всемирную паутину».

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

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

Основное отличие МРЕG-4 от ранее принятых эталонов — объектно-ориентированное представление медиа-информации. В эталоне вводится ключевое понятие медиа-объекта — единицы звукового, зрительного либо Предпосылки создания стандарта аудиовизуального контента. Неважно какая сцена делится на объекты, которые соотносятся в пространстве и времени и описываются отдельными простыми потоками (ES). Объекты могут быть натуральными — записанными с камеры либо микрофона, и синтетическими — синтезированными в компьютере. Таковой подход имеет ряд преимуществ: более экономично расходуются биты для описания сцены, отдельные объекты просто Предпосылки создания стандарта использовать в других сценах, упрощается построение масштабируемых объектов и взаимодействие с объектами, возникают широкие способности взаимодействия юзера с избранным объектом, к примеру, вывод дополнительной инфы об объекте, изменение его характеристик (цвета, текстуры, громкости звучания либо языка), исключение объекта из сцены, создание юзером новых сцен из объектов, приобретенных от различных Предпосылки создания стандарта источников либо хранящихся в памяти терминала. Все эти операции требуют только поменять описание сцены, а это полностью под силу микропроцессору абонентского терминала.

Описание сцены

Для описания сцены и ее динамического конфигурации в МРЕG-4 употребляется разработанный специально двоичный язык BIFS (Вinаrу Format for Sсеnеs — двоичный формат описания сцен). Описание сцены показывает декодеру Предпосылки создания стандарта, где и когда воспроизводить объекты, входящие в сцену, и как реагировать на воздействие юзера. Чтоб увязать ЭП с медиа-объектами в сцене, употребляются дескрипторы объекта. Они переносят информацию о числе и свойствах ЭП, связанных с определенными медиа-объектами. Сами дескрипторы также переносятся в одном либо нескольких ЭП, потому Предпосылки создания стандарта несложно добавить либо удалить объект во время сеанса. Потоки дескрипторов могут рассматриваться как описания потоковых ресурсов для представления, а описание сцены служит для конфигурации пространственно-временного размещения объектов в сцене. МРЕG-4 обусловил особый язык синтаксических описаний для четкого описания синтаксиса потоков, переносящих информацию о медиа-объектах и описания сцен. Он Предпосылки создания стандарта представляет собой расширение языка С++ и позволяет дать четкое описание синтаксиса и в то же время упростить проверку на соответствие.

BIFS оперирует 2-мя протоколами модификации сцены во времени — командным (BIFS-Command) и анимированным (BIFS-Anim). Командные потоки BIFS позволяют загружать новейшую сцену, изменять характеристики объектов, вводить и уничтожать Предпосылки создания стандарта объекты. Потоки BIFS-Anim управляют процессами анимации сцены, к примеру, конфигурацией точки взора, перемещением, трансформацией размера, плавным конфигурацией цвета, освещенности и т.д. Синхронизация потоков осуществляется методом временной привязки. Как и в прошлых эталонах МРЕG, один вид временной метки обеспечивает синхронизацию тактовых частот кодера и декодера, метки другого Предпосылки создания стандарта вида, привязанные к многофункциональным единицам аудиовизуальных данных, содержат хотимое время декодирования (для единиц доступа) либо время окончания сборки (для компоновочных единиц).

Главные принципы BIFS взяты из языка VRML (Virtual Reality Modelling Language — язык моделирования виртуальной действительности), разработанного для сотворения 3D графики. Это обширно всераспространенный и в значимой степени бесплатный язык программирования, поточнее Предпосылки создания стандарта, действенный 3D формат обмена, вроде бы большой аналог НТМL. Дело в том, что некие виды инфы лучше воспринимаются в объемном виде — игры, результаты исследований, строительные решения. VRML обеспечивает интеграцию трехмерных, двумерных, текстовых и мультимедийных объектов в связную модель. Он оперирует объектами, любой из которых имеет разные аттрибуты. Объект именуется Предпосылки создания стандарта узлом, а аттрибуты — полями. Число полей находится в зависимости от типа узла. Полный список узлов и полей известен как граф (разветвленная древообразная структура). VRML включает большая часть применяемых в 3D приложениях средств: иерархические трансформации, источники света, выбор точки взора, анимацию, характеристики материала, отображение текстуры и т.д Предпосылки создания стандарта.

Язык BIFS взял в долг у VRML структуру описания сцены в виде графа, модели поведения, графические примитивы для построения 3D-изображений: конусы, сферы, сетки, текстовые примитивы, текстурирование и подсветку (всего их 36). В то же время BIFS имеет значительные отличия от VRML, в него внесены новые решения:

1) VRML — язык высочайшего уровня Предпосылки создания стандарта, BIFS — двоичный, благодаря этому объем сообщений в нем в 10-15 раз меньше, чем в VRML; хотя объем описаний сцены обычно меньше, чем аудиовизуальной инфы, эти описания передаются безпрерывно и могут в итоге составить приметную часть передаваемых данных, потому сжатие потоков BIFS довольно животрепещуще;

2) VRML работает с файлами, за ранее загружаемыми Предпосылки создания стандарта в микропроцессор, а BIFS предназначен сначала для потоковой передачи в реальном времени;

3) BIFS позволяет работать как с 2D, так и с 3D объектами, производить масштабирование, перемещение, вращение, более того, в первый раз решена задачка представления в одной сцене и 2D, и 3D объектов.

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

Приобретенные в итоге кодировки Предпосылки создания стандарта простые потоки нужно доставить к декодеру. Для этого МРЕG-4 предлагает двухуровневый механизм мультиплексирования, показанный на рисунке 3.1. Простые потоки поступают на мультиплексирование, пройдя уровень синхронизации SL (Sync Layer), где в заглавия пакетированных простых потоков (PES) вводятся временные метки.

Набросок 3.1 - Двухуровневый механизм мультиплексирования цифрового потока в эталоне МРЕG-4

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

2-ой уровень, TransMuх (Тrаnspоrt Мultiрlеxing), предлагает транспортные услуги по передаче потоков с данным качеством обслуживания. Условия передачи подразумевают нужную пропускную способность, допустимый уровень ошибок, наибольшее время задержки, ценность и т.д. TransMuх не является транспортным протоколом как таким, он представляет собой быстрее интерфейс меж Предпосылки создания стандарта кодером МРЕG-4 и стандартным транспортным протоколом. В качестве такого могут употребляться протокольные стеки RТР/UDP/IР, ААL5/АТМ, транспортный поток МРЕG-2.

Взаимодействие с транспортной средой управляется протоколом DMIF (Delivery Multimedia Integration Framework — мультимедийная встроенная система доставки). DМIF, как его определяет эталон, — сеансовый протокол для управления потоковой передачей в Предпосылки создания стандарта случайных средах. После пуска он устанавливает соединение с удаленным абонентом, выбирает подлежащие передаче потоки и отправляет запрос на их передачу. Порт DMIF отправляет отметки к тем точкам, откуда будут передаваться потоки, и устанавливает соединение. Функции DMIF по связи с транспортными протоколами реализуются через интерфейс DAI (DMIF Аррliсаtiоn Interface), который получает PES от Предпосылки создания стандарта уровня синхронизации и переводит запросы DMIF в команды, воспринимаемые определенным протоколом. Команды для различных протоколов могут быть разными.


На приемном конце личные ES выделяются из пришедшего

Набросок 3.2 - Структура терминала МРЕG-4

транспортного потока методом демультиплексирования (набросок 3.2).

На этом шаге DMIF не отвечает за работу транспортного протокола, он подключается только при Предпосылки создания стандарта наличии потоков FlехМuх. Выделенные после демультиплексирования пакеты PES обрабатываются с целью извлечения из их инфы о синхронизации. Эта информация переносится в заголовках пакетов, генерируемых на уровне синхронизации.

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

2-ой механизм — интерфейс программных приложений МРЕG-4 с кодами известного языка Предпосылки создания стандарта программирования Jаvа — призван облегчить интеграцию Jаvа-приложений в структуру МРЕG-4. Он будет принимать ЭП Jаvа-приложений, обрабатывать их и направлять к подходящим компонентам МРЕG-4 плейера. Усовершенствование протокола DMIF во 2-ой версии эталона касается введения способности работы с мобильными средствами связи, обеспечения более широкого класса характеристик свойства обслуживания (Q0S),

2-ой Предпосылки создания стандарта механизм — интерфейс программных приложений МРЕG-4 с кодами известного языка программирования Jаvа — призван облегчить интеграцию Jаvа-приложений в структуру МРЕG-4. Он будет принимать ЭП Jаvа-приложений, обрабатывать их и направлять к подходящим компонентам МРЕG-4 плейера.

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


predotvrashenie-rasprostraneniya-pozhara.html
predotvrashenie-vozniknoveniya-i-rasprostraneniya-pozhara-v-vagonah-passazhirskih-poezdov.html
predperevodcheskij-analiz-ligvokulturnoj-specifiki-nemeckih-reklamnih-tekstov-topik.html