Требования к архитектуре мультимедиа-систем

Требования реального времени в системах мультимедиа

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

Способность гарантировать время реакции является отличительным признаком систем РВ. Важно учитывать различие между гарантированностью и просто высокой производительностью и низкими накладными расходами. Далеко не все алгоритмы и технические решения, даже и обеспечивающие отличное среднее время реакции, годятся для приложений и ОС РВ. По другим признакам эти системы могут относиться как к классу ДОС (RT -11), так и к ОС (OS -9, QNX).

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

С использованием цифровых сигнальных процессоров (digital signal processors – DSP), представляющих собой эффективное средство обработки непрерывных потоков данных, аудио, видео и телекоммуникация довольно быстро переходят на цифровые технологии. Новые требования привели к появлению новых архитектур - мультимедиа-компьютеров. Эти системы предназначены для передачи непрерывных потоков данных с одновременной их обработкой. В некоторых случаях это цифровая фильтрация данных, в других – упаковка/распаковка потоков информации. В любом случае обработка выполняется специализированными прикладными программами, исполняющимися под управлением стандартных цифровых сигнальных процессоров. И хотя все используют одни и те же технические средства, сейчас появилась возможность собирать специализированные системы мультимедиа из готовых компонентов. Стандарт на интерфейс SCSA используется при разработке мощной модульной системы мультимедиа на базе VME.

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

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

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

Другой ключевой элемент – максимально возможное число информационных каналов, которые система должна обрабатывать одновременно. Нагрузка каждого канала в значительной мере зависит от типа предоставляемых системой услуг. Например, MPEG -закодированный кинофильм можно просто передавать через систему к различным портам, без декодирования. А речевую информацию, считываемую из ADPCM [11] - упакованного файла, по мере прохождения через систему нужно наоборот распаковывать.

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

· речевые сигналы с высокой степенью сжатия (2,4 Кбит/с),

· закодированные факсимильные сообщения группы G -III (от 2,4 до 28,8 Кбит/с),

· речевые ADPCM -сигналы (от 24 до 32 Кбит/с),

· монохромное видеоизображение с замедленной сменой кадров (128 Кбит/с),

· цветное MPEG -видеоизображение со стандартной частотой смены кадров (до 10 Мбит/с).

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

Вдобавок к нагрузке на обработку, потоки видеоданных могут довольно просто перегрузить системные каналы. Например, три-четыре потока, одновременно проходя по объединительной VME -магистрали, довольно быстро исчерпывают её пропускную способность.

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

· Переслать сжатую речевую информацию из устройства хранения в буферную память,

· Переслать речевую информацию из буфера в подсистему распаковки информации,

· Направить распакованный поток данных интерфейсу доставки сообщения.

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

Ввод/вывод информационных потоков. Обычно интерфейс ввода/вывода выполняет две функции:

· подтверждает обмен данными с внешними каналами информационных данных;

· производит преобразование из внутренних системных форматов данных в форматы данных внешнего информационного канала и наоборот.

Обычно протоколы внешнего интерфейса встраиваются в поток данных для того, чтобы обеспечить:

· синхронизацию;

· обмен сигналами по каналам;

· управление потоками данных;

· контроль ошибок;

· маршрутизацию по коммутируемым каналам.

Информационный поток может быть полнодуплексным (как в случае передачи факсимильного сообщения группы G -III через цифровой интерфейс телефонной сети Т 1) или симплексным (как в случае MPEG -декодера, обслуживающего один стандартный цветной SVGA -монитор).

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

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

· кодирование;

· декодирование;

· распознавание речи;

· многосторонний обмен речевыми сигналами (конференции).

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

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

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

Способов избежать конфликтов на шине – использовать все ресурсы обработки мультимедиа-данных подчиненные VME -модули. Обработка информационных потоков выполняется центральным хост-процессором или процессорами. Однако поскольку эти потоки иногда требуется обрабатывать более одного раза, может понадобиться неоднократное обращение к центральному процессору.

Необходим механизм непрерывной передачи данных с постоянной скоростью. Некоторые информационные потоки поступают в систему непрерывно и должны передаваться с определенной фиксированной скоростью. Требования цифрового сигнального интерфейса Т1 определяют скорость оцифровывания телефонного разговора в 8000 отсчётов в секунду. Аналогичным образом в видео- и сетевых устройствах предполагается, что передача соответствующих данных будет осуществляться в виде непрерывного потока кадров, при этом некоторые сетевые протоколы VME -модулей (главным образом, цифровых телефонных сетевых интерфейсов) с интерфейсом, умеющим обрабатывать непрерывные равномерные информационные потоки, существует достаточно. Однако ни один из них не соответствует какому-либо официально признанному стандарту синхронизации, которые накладывают жесткие ограничения на системы обработка мультимедиа-информации.

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

Механизм блочных передач VMEbus может не обеспечить требуемой производительности. Обеспечение непрерывного обмена данными между различными системными ресурсами сильно снижает пропускную способность хост-процессора, необходимую для выполнения важных прикладных программ. Виртуальные соединения, которые обеспечиваются шиной VMEbus при блочных передачах, приводят к задержкам, длительность которых зависит от количества поддерживаемых в данный момент соединений. Эти переменные задержки создают проблемы при работе системы. В соответствии с рекомендациями EIA -464 A общее время задержки передачи информационного потока никогда не должно превышать 2 мкс при прохождении потока вдоль всего канала передачи данных.

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

· поддержки блочной VME -передачи;

· буферизации всех одновременных блочных передач, которые могут выполняться по нескольким различным виртуальным каналам в конкретный момент времени;

· ресинхронизации каждого такого потока в соответствии с сетевым или интерфейсным стандартом.

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

Избежать буферизации данных при чтении или записи данных на диск нельзя. Эти данные обычно упакованы, поэтому потребности в буферной памяти не слишком велики. Однако через специализированные порты ввода/вывода в систему поступают и неупакованные данные (например, от сканера либо телефонного интерфейса Т 1). Коммерческие коммуникационные интерфейсные VME -модули обычно не имеют адекватного механизма буферизации для обработки таких потоков данных, поэтому требуются какие-то специальные методы.

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

Прикладная программа координирует действия подсистем ввода/вывода и модулей системы таким образом, чтобы обеспечить требуемый сервис. Уведомление центрального хост-процессора о текущем состоянии и произошедших событиях выполняется с помощью стандартизированной эффективной системы VME. В системе со многими каналами ввода/вывода может потребоваться установка дополнительных процессорных модулей с целью разгрузки основного хост-процессора. Эта мера позволяет основному процессору поддерживать необходимую реактивность системы. Однако в случае, если поступающие в один модуль ввода/вывода данные должны вернуться в исходное устройство через другой модуль, то в системе возникнут дополнительные передачи данных через магистраль VME. Эти пересылки возникают тогда, когда поток входных данных в один интерфейс ввода/вывода заставляет этот модуль прерывать хост-процессор. Хост-процессор начинает исполнять программу, которая транслирует поток данных второму интерфейсу ввода/вывода. По мере увеличения количества активных каналов возникает перегрузка хост-процессора, при этом время трансляционной реакции увеличивается и становится все более непредсказуемым. Если время реакции начинает превышать максимально допустимую величину задержки на прохождение сигналов (определяемую внешними телефонными службами), то возможно применение отключения от основной магистрали (и прекращение поступления данных).

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

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

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

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

· доступ по номеру 976;

· разговоры по кредитным карточкам (0+);

· дополнение телефонного номера *66 (автодозвон до занятого абонента).

Для упрощения состава технических средств и управления процессом оказания этих дополнительных услуг каждому абоненту используются мощные рабочие станции на базе RISC -процессоров либо круглосуточно работающие компьютеры. Список оказываемых услуг формируется и хранится на рабочей станции с помощью так называемой "Среды формирования услуг" (service creation environment). Данная рабочая станция посылает простую команду удаленной "серверной" VME -системе, которая фактически и оказывает данную услугу. Каждый серверный крейт имеет встроенный "интеллект", позволяющий системе интерпретировать и исполнять получаемые от компьютера-клиента примитивы обработки мультимедийной информации.

Для дистанционного управления мультимедийным процессором в ОС должна быть поддержка локальных сетей. Несколько ОС для VME -процессоров (UNIX SVR 4, OSF /1, HP - UX, DG - UX, AIX и Solaris 2.4) обеспечивают:

· встроенную поддержку локальных сетей;

· взаимодействия на уровне ядра (в виде вызовов удаленных процедур);

· удаленный доступ к файловой системе.

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

Системы могут выходить за рамки одного крейта. С помощью нескольких VME -крийтов строится мультимедийную систему с несколькими сотнями каналов ввода/вывода с резервированием. В такую установку может встраиваться запасная система целиком. Обычно бывает резервирование типа "1-для- N ", где N колеблется от 2 до 10 (в зависимости от величины допустимого риска и финансовых возможностей конечного потребителя).

Дата добавления: 2014-01-05