Сегодня ни один из ведущих производителей RISC- компьютеров не остался равнодушным к рынку мультимедиа. Если компания располагает достаточно мощным аппаратным потенциалом, она выпускает специализированные программно-аппаратные решения для работы с мультимедиа. В этой связи не является исключением и корпорация IBM, о продукции которой пойдет речь в этой статье.
Несмотря на обилие различных подходов, можно заметить, что все разработчики практически единодушны в принципиальных решениях, базовая архитектура, т. е. состав и организация мультимедиа-комплексов, по-видимому, сложилась. Если говорить о составе, то можно выделить две основные части. К первой относятся локальные средства для просмотра, создания, оцифровки, преобразования и редактирования мультимедиа, предназначенные либо для потребителей, либо для авторов медиа-документов. Во вторую группу входят средства централизованного хранения и доставки документов по сети. Такое разделение естественно вытекает из многообразия решаемых системами мультимедиа-задач и позволяет рассматривать их в значительной мере независимо. Современными средствами интеграции технологий обработки и доставки, оставляющими широкое пространство выбора, являются клиент-серверная архитектура и стандарты открытых систем, которые дают возможность создавать распределенные вычислительные комплексы из разнородных платформ. Однако, несмотря на это, полная оценка конкретной платформы должна учитывать обе группы функций.
1. Мультимедиа-продукты IBM
В качестве основной платформы для систем мультимедиа IBM предлагает семейство серверов RS/6000 на процессорах PowerPC с базовой операционной системой AIX. Начиная с AIX Version 4 компания IBM, как и многие другие производители рабочих станций, включает свое программное обеспечение (ПО) мультимедиа - оно называется Ultimedia Services - в стандартный комплект поставки [1].
В пакет Ultimedia Services входят следующие приложения: вьюверы/плейеры; ПО для захвата и компрессии/декомпрессии аудио, видео и изображений; средства редактирования всех видов мультимедиа и преобразования форматов; видеоконференции; распределенное обучение; распространение новостей в реальном времени.
ПО Ultimedia Services построено в объектной технологии, и поэтому все приложения обладают рядом общих свойств. Так, все они поддерживают наиболее распространенные форматы мультимедиа, используемые в системах Unix, OS/2 и Windows, а графические интерфейсы имитируют кнопочное управление реальными устройствами проигрывания. Ultimedia Services глубоко интегрировано с базовой ОС AIX. В среде рабочего стола, например, многие типы данных распознаются автоматически: для них запускаются подходящие вьюверы и ПО декомпрессии. Через Ultimedia Services осуществляется управление мультимедиа-аппаратурой, к примеру дисководом CD для поиска нужного фрагмента или платой оцифровки для установки параметров.
Кроме традиционных для многих платформ средств работы с мультимедиа в состав Ultimedia Services входят средства доставки. Два приложения, UMSRadio и UMSTV, поддерживают захват живого аудио или видео, которые снимаются с любых внешних источников (камеры, видеопроигрывателя, ТВ, радио), и передачу их по сети. Информация может распространяться либо по схеме точка-точка одному клиенту, либо в широковещательном режиме одновременно многим потребителям.
UMS VideoPhone - средство организации видеоконференций. Это приложение имеет два режима использования. В непосредственном режиме пользователь одновременно может присутствовать в нескольких сессиях, получая на свой экран текущую съемку всех удаленных участников и посылая им свою. В отложенном режиме он может просматривать накопленные видеопослания, а также отправлять по нужным адресам собственные.
Ultimedia Services наделен очень важным свойством, которым обладают далеко не все системы мультимедиа: он открыт, благодаря входящему в его состав API C/C++. Это API включает объекты двух типов: мультимедиа-устройства и готовые мультимедиа-приложения. На основе такого API прикладной программист может интегрировать приложения из Ultimedia Services, добавлять мультимедиа-поддержку к существующим приложениям и, конечно, создавать собственные, включая в них работу со всеми имеющимися в системе медиа-устройствами.
Не все модели серверов RS/6000 полностью готовы к работе с мультимедиа. Так, специальная аппаратура может потребоваться для записи или проигрывания звуковых файлов. В тех моделях RS/6000, в которых шина - PCI, эта поддержка встроена, а для модели с шиной Micro Channel требуется дополнительный аудио-адаптер. Дополнительной видеоплаты для Ultimedia Services не требуется: с проигрыванием файлов AVI (в кодировке MJPEG, UltiMotion, Indeo), Video CD и MPEG-1 справляется центральный процессор сервера, причем в системах на базе PCI Ultimedia Services способно динамически менять размер изображения. Однако для мониторинга, т. е. захвата живого видео с камеры, CD или видеоплейера, нужен дополнительный адаптер - Ultimedia Video или Ultimedia Video Capture.
2. Решение для вещания
MediaStreamer ПО Ultimedia Services способно работать на любом сервере RS/6000, но оно, конечно, не может справиться с задачей масштабной доставки мультимедиа: для этого требуется специализированное программно-аппаратное решение - медиа-сервер. IBM предлагает несколько типов медиа-серверов: Multimedia Server, VideoCharger Server и MediaStreamer. Далее мы рассмотрим последний, самый мощный и спроектированный для массового профессионального вещания.
Медиа-сервер IBM MediaStreamer можно охарактеризовать как комплекс для эффективного хранения и распространения аудио/видеоматериалов в аналоговой и цифровой форме. Предназначенный для работы с большими объемами данных, он существенно облегчает администрирование, гарантирует высокую работоспособность и качество доставляемого видео. Позволяя хранить медиа-документы в сыром или сжатом виде, сегодняшние конфигурации MediaStreamer способны поддерживать одновременную передачу 42 независимых каналов в аналоговых форматах (NTSC, PAL) либо до 75 цифровых по технологии ATM. Высокую степень масштабируемости аппаратуры и программного обеспечения иллюстрирует такой вполне реальный режим функционирования MediaStreamer, в котором множество медиа-потоков, формируемых из одного и того же файла, параллельно направляются по адресам различных потребителей, и в то же время производится ввод и запись в систему хранения сервера информации со спутника.
Хотя комплекс MediaStreamer и базируется на сервере RS/6000, они далеко не тождественны. То же самое можно сказать о программном обеспечении - базовая операционная система AIX существенно расширена собственным ПО MediaStreamer.
В архитектуре MediaStreamer можно выделить две главные части: первая занимается передачей медиа-потоков, а вторая - управлением. Каждая часть располагает своими аппаратными компонентами и соответствующим программным обеспечением. Аппаратная часть передачи потока включает процессор, диски и кэш-память для видео. Аппаратура управления состоит из управляющей системы, коммуникационных адаптеров и декодеров.
Чтобы понять роль каждого компонента и их взаимодействие, рассмотрим функционирование системы в целом (рис. 1). Все начинается с того, что пользователь со своего удаленного компьютера или ТВ-приставки посылает в MediaStreamer видеозапрос. Клиентское ПО, работающее на пользовательской системе, оформляет запрос в виде вызова удаленной процедуры (RPC), направляя его по адресу Управляющей системы MediaStreamer. Управляющей системой может служить любой компьютер, соединенный с сервером MediaStreamer сетью TCP/IP и способный поддерживать с ним связь по протоколу RPC. Посылая сигнал в процессор MediaStreamer, Управляющая система инициирует передачу запрошенного потока видеоданных. Происходит переписывание данных с диска в видео кэша. Поскольку кэш один, одновременно передаваемые потоки в нем смешиваются, а разбирается с ними плата контроллера, в которую смешанные потоки попадают из кэша. Контроллер разделяет их и посылает в декодеры. Принимая цифровой сигнал, обычно сжатый по MPEG-1 или MPEG-2, декодер преобразует его со скоростью 15 Мбайт/с в аналоговый сигнал (NTSC, PAL), подготовленный для доставки на телевизионные приемники. Собственно приемом и передачей потоков видеоданных по сети занимается коммуникационный адаптер с максимальной шириной пропускной полосы 96 Мбайт/с, которая делится между параллельными потоками.
Рисунок 1.
Компоненты MediaStreamer.
Описанная схема немного видоизменяется при приеме видеопотоков. Поступающие аналоговые видеоданные могут быть преобразованы в цифровой формат без сжатия (D1) или сжаты в MPEG-1 либо MPEG-2. Для сжатия требуется дополнительное внешнее устройство, например IBM Power Visualization System (PVS). После сжатия данные вводятся в MediaStreamer через ленту, CD, диск или сеть.
3. Архитектура MediaStreamer
Главным компонентом ПО, который отличает архитектуру MediaStreamer от стандартной для семейства RS/6000 ОС AIX, является система управления медиа-файлами. На нее возложена задача выполнения оптимизированного сетевого ввода/вывода через порты сервера. В этом разделе вводятся основные понятия, используемые в файловой системе: протокол сетевого ввода/вывода, порт и титул.
MediaStreamer поддерживает два варианта сетевого ввода/вывода - поточный и файловый. Поточный ввод/вывод перемещает данные по разомкнутой схеме передачи: данные может получать множество клиентов, но в процессе передачи у них практически нет обратной связи. В этом варианте передачи MediaStreamer поддерживает два протокола: композитный аналоговый и цифровой поточный ATM AAL-5. Первый протокол поддерживает только файлы MPEG, а последний - любые цифровые файлы, но оптимизирован он также на файлы MPEG.
Второй вариант сетевого ввода/вывода, файловый, передает данные по замкнутой схеме, в которой каждый клиент имеет возможность полностью контролировать получаемые данные, выполняя их проверку и запрашивая при необходимости повторную передачу. Поскольку клиенты могут взаимодействовать с сервером независимо друг от друга, этот способ обычно не применяется в случае массового вещания.
И поточный, и файловый методы могут применяться для передачи в любом направлении, как для импорта (записи) данных, так и для их экспорта (проигрывания). В файловой системе MediaStreamer команды Record/Play используются для потока, а команды Write/Read - для файлов. Следует отметить, что оба протокола могут быть задействованы одновременно для работы с одним файлом, например файл может загружаться и параллельно проигрываться.
Поточный метод передачи данных опирается на понятие порта, который абстрагирует представление о сетевых интерфейсах MediaStreamer. Перед использованием для проигрывания или записи производится выбор и открытие порта, при этом не обязательно задавать точное соответствие интерфейса и клиента - как правило, достаточно определить только тип порта. Порты в MediaStreamer бывают двух типов: ATM или аналоговый. Аналоговый порт поддерживает один поток, и только для проигрывания, однозначно соответствуя физическому интерфейсу. Напротив, порты ATM - виртуальные, каждый из них является абстрактным путем передачи данных в адаптер ATM. На одном физическом адаптере ATM в MediaStreamer имеется 75 портов этого типа.
Кроме передачи данных ПО Media-Streamer решает задачу локального управления медиа-файлами на более высоком, по сравнению с возможностями базовой ОС AIX, уровне. В качестве единицы хранения (или титула) рассматривается содержание медиа-файла вместе с его атрибутами: стандартом сжатия (MPEG-1, MPEG-2), форматом (транспортный поток, программный поток, системный поток), разрешением (SIF, CCIR601, HHR), выходным форматом (NTSC, PAL) и скоростью передачи (средняя скорость проигрывания в битах/с). При всех изменениях физического размещения титула поддерживается единство файла и его атрибутов. Титулы могут объединяться в группы, что упрощает доступ к ним из приложений различных типов.
3.1. Сервер управления
Удаленные приложения и клиенты осуществляют управление сервером MediaStreamer с помощью команд, совокупность которых составляет прикладной программный интерфейс (API). Как уже было сказано, обращения поступают в MediaStreamer от Управляющей системы по протоколу RPC. Cервер управления реализует эти обращения, "перекидывая мостик" между приложениями и остальными компонентами MediaStreamer.
API MediaStreamer состоит из следующих групп команд: управление сессией - устанавливает связь с MediaStreamer; управление соединением - определяет порты для потоков и их статус; управление потоками - связывает порты с аудио/видеофайлами и контролирует передачу; управление ресурсами - работа с титулами в MediaStreamer (добавление, удаление и т. д.).
В первую очередь выполняются команды открытия сессии, устанавливающие контекст и связывающие приложение с определенной группой ресурсов системы. После открытия сессии клиентское приложение может посылать команды для выделения портов, проигрывания видео и доступа к другим сервисам MediaStreamer в рамках прав, определяемых контекстом сессии. При желании приложение может зарегистрировать функцию обратной связи (callback). В этом случае ему не нужно будет периодически опрашивать статус при выполнении длинных команд, например при проигрывании двухчасового фильма. Существенная информация, к примеру сбой выделенного порта, завершение операционного шага, будет передаваться в приложение асинхронно.
Кроме интерфейсных функций по обработке API на Сервер управления возложены функции распределения ресурсов сетевых адаптеров. Для данной конфигурации системы Сервер управления оценивает, исходя из мощности процессора и выделенного для доставки видео пула памяти, реальную пропускную полосу. Когда клиент делает запрос на загрузку или проигрывание, Сервер управления выделяет необходимую часть полосы пропускания и закрепляет ее за клиентом на все время выполнения операции. Такой способ управляемого выделения пропускной полосы называется резервированием качества обслуживания (QoS - Quality of Service).
В архитектуре MediaStreamer резервирование QoS необходимо для любых типов поточного ввода/вывода и является опцией для файловых операций. При файловой передаче есть две возможности. Можно либо точно также резервировать полосу пропускания, либо получать полосу, "оставшуюся" от клиентов, которые выполняют резервирование QoS. Естественно, что остающаяся незанятой полоса может изменяться во времени. Вообще, резервирование QoS предназначено для операций в реальном времени, таких, например, как ввод файлов со сжатием прямо в MediaStreamer или проигрывание, а для операций типа перемещения титулов или копирования данных из памяти кодировщика резервирование обычно не применяется.
Сервер управления, интерпретируя команды, поступающие на интерфейс MediaStreamer, для их выполнения обращается к двум другим главным компонентам архитектуры: Менеджеру Файл/Память и Экспортеру Данных (рис. 2), которые вместе образуют "насос данных". Использование такой архитектуры с выделением Сервера управления в отдельный компонент преследует далеко идущие цели: тем самым открывается способ создания перспективных конфигураций с множественными "насосами данных", которые все работают под управлением единственного сервера. В системе с такой архитектурой для большого числа передаваемых потоков требуется единственный пункт управления, а подобная конфигурация способна упростить управление сверхбольшими комплексами и дает возможность эффективно использовать кластеры и платформы с многопроцессорной обработкой.
Рисунок 2.
Архитектура ПО MediaStreamer.
3.2. Экспортер Данных
Функция Экспортера Данных - обеспечить доставку потоков к связанным с ними портам. Поскольку API MediaStreamer предполагает работу как с портами аналогового преобразователя, так и с виртуальными портами ATМ, Экспортер Данных устанавливает реальные пути перемещения данных. Он также управляет выходной полосой пропускания в соответствии с резервированием QoS.
Экспортер Данных различает потоки видеоданных трех типов: потоки проигрывания, потоки записи и конвейерные потоки. Поток проигрывания - это такой поток, который читает один или более файлов и записывает данные в отведенный им порт. Поток записи, наоборот, получает данные из порта и записывает их в файл. Конвейерный поток читает данные из одного порта и записывает их в другой заданный порт. Этот тип передачи подходит, например, для преобразования входящего потока ATM в выходной аналоговый формат. Первые два типа поточной передачи Экспортер Данных выполняет, взаимодействуя с Менеджером Файл/Память, а с конвейерными потоками он справляется самостоятельно.
Большая часть функций Экспортера Данных связана с потоками проигрывания, поскольку входные потоки данных не управляемы - они поступают на постоянной скорости. Набор команд для управления потоками проигрывания включает запуск, паузу, перемотку и окончание. Дополнительные команды проигрывания позволяют построить список проигрывания, объединив в нем сразу несколько файлов в одну программу показа. В ходе сеанса клиент полностью контролирует список проигрывания, располагая командами для удаления, замены или добавления отдельных титулов.
3.3. Менеджер Файл/Память
Менеджер Файл/Память занимается распределением данных по дисковому пулу таким образом, чтобы поточные операции могли выполняться непрерывно без нарушения временных ограничений. Кроме того, он реализует поступающие от Сервера управления команды управления титулами, а также вместе с Экспортером координирует передачу данных.
К особенностям Менеджера следует отнести его способность обеспечивать многократное открытие файла и возможность читать файл, в который одновременно происходит запись. Эти полезные свойства составляют базу для организации многоэтапных технологических цепочек, имеющих низкую задержку на стыках. Благодаря этому MediaStreamer способен, например, удовлетворять запросы на просмотр файла, который параллельно копируется. Еще большую ценность эти возможности приобретут в перспективных конфигурациях из нескольких, обменивающихся между собой данными, серверов MediaStreamer.
Менеджер Файл/Память оптимально размещает данные, используя все ресурсы конкретной конфигурации MediaStreamer. Поэтому, когда память добавляется (или удаляется), Менеджер соответственно перераспределяет все данные. По сути дела во время реконфигурации происходит чтение и перезапись всей информации в пуле памяти. В типичной ситуации, когда наполовину заполненный пул памяти емкостью 200 Гбайт удваивается, требуется около семи часов для реорганизации данных.
3.4. Пул Памяти
Используемая в MediaStreamer технология подключения дисков SSA дает возможность образовывать пул видеопамяти колоссальной емкости (свыше терабайта). С другой стороны, большое количество дисков в конфигурации заставляет всерьез задуматься о механизмах повышения надежности, так как диски являются активными механическими компонентами, которые в значительно большей степени подвержены сбоям, чем другие компоненты в системе. Конструкция стойки дисков в RS/6000 предусматривает защиту от сбоев несколькими способами: технология RAID, горячий резервный диск, избыточное энергопитание, избыточный вентилятор и горячая замена сбойного диска.
В MediaStreamer диски конфигурируются в группы по пять. Каждая такая группа составляет массив RAID. Далее три таких массива могут быть установлены в одну дисковую стойку, которая всего вмещает 16 дисков - одно посадочное место резервируется для горячего резерва. Количество дисковых массивов в конфигурации зависит от необходимой емкости памяти, объема потоков и допусков надежности. Есть два варианта конфигураций дискового пула: безотказная и с временной деградацией. В конфигурации с временной деградацией сбой диска вызывает падение системной полосы пропускания, и это может привести к разрушению видеовывода, если в момент аварии загрузка системы высока. Однако потери в пропускной полосе продолжаются только в течение интервала времени, необходимого на реконструирование данных сбойного диска на одном из дисков горячего резерва. Внешняя память в безотказной конфигурации имеет большую пропускную полосу, и сбой диска не разрушает видеовывода. Сама замена сбойного диска не приводит к потере данных в обеих конфигурациях.
Количество требующихся RAID-массивов зависит от планируемой пропускной полосы. Если исходить из максимальной полосы, необходимо иметь 7 RAID-массивов для безотказной конфигурации и 2 для временно деградирующей.
4. Цифровые библиотеки
Располагая полным серверным решением, ведущие производители, в том числе и IBM, подбираются к следующему уровню медиаобслуживания. В IBM это называют цифровой библиотекой - собранием материалов в машино-читаемой форме, которые хранятся вместе с организующей информацией, необходимой для их поиска. В отличие от традиционных библиотек здесь идет речь о мультимедиа-материалах. Поэтому одной из главных задач, стоящих перед создателями цифровых библиотек, является хранение и доступ к большому количеству неоднородных объектов данных. Решение этой задачи дает IBM Server Solution Offering (SSO), построенное на основе MediaStreamer.
Ключевым элементом архитектуры SSO служит мультимедиа-узел. Каждый мультимедиа-узел состоит из четырех компонентов: библиотечный сервер; один или несколько серверов для объектов, отличных от видео; один или несколько видеосерверов; одна или несколько подсистем памяти для вышеперечисленных компонентов. На библиотечном сервере хранится индекс всех объектов, находящихся в мультимедиа-узле, серверы объектов занимаются их доставкой. Таким образом, библиотечный сервер может служить аналогом картотеки, а серверы объектов, физически их храня, выполняют роль библиотечных полок. Каждая из вышеперечисленных компонентов может конфигурироваться и масштабироваться независимо от других.
В распределенной архитектуре SSO один узел выбирается в качестве главного, и на нем размещается уникальный мастер-индекс всех данных системы. Если другие узлы имеют собственные локальные библиотечные серверы, то на них хранятся изменяющиеся подмножества мастер-индекса. Главный узел может содержать еще основную копию всех элементов данных, и в этом случае остальные узлы могут рассматриваться просто как локальные кэши. Когда локальный кэш переполняется, из него удаляются объекты с истекшими сроками хранения, а вместо них загружаются новые.
Таким образом, IBM SSO представляет собой реализацию клиент-серверной модели, которая позволяет организовать гибкую иерархию серверов и дает механизмы для централизованного управления большими распределенными цифровыми библиотеками.
5. Среда автоматизированного вещания
В качестве примера построения распределенных систем на базе MediaStreamer рассмотрим среду автоматизированного вещания. Использование цифровых медиа-серверов в индустрии телевещания позволяет получить ряд преимуществ по сравнению с традиционными способами. Главные из них - абсолютная точность цифровой формы медиа-документов и основанная на компьютерах автоматизация производственных процессов. Постепенно традиционные аналоговые видеоленты, требующие больших затрат на распространение, заменяются дисковой памятью и передачей файлов.
Сам по себе MediaStreamer не дает готового решения для какого-либо вида доставки видео, широковещательного или, например, Video-on-demand, но, поскольку его архитектура соответствует стандартам открытых систем, серверы MediaStreamer могут использоваться как базовые блоки в различных решениях и дополняться продуктами и IBM, и других поставщиков. Среди таких продуктов - IBM MediaStreamer Archive, автоматизированная память для хранения больших объемов мультимедиа в роботизированной ленточной системе. Второй продукт - IBM Master Automation Bridge - позволяет построить систему вещания, используя на верхнем уровне известные системы автоматизации вещания, такие как Alamar или Louth System, а на нижнем - серверы MediaStreamer и MediaStreamer Archive, что показано на рис. 3.
Рисунок 3.
Среда автоматизированного вещания.
В такой среде вещательная система осуществляет все содержательное управление, посылая команды, например, проигрывания или остановки, через последовательный интерфейс в интегрирующий Broadcasting Bridge, который переадресует их в MediaStreamer и возвращает любую требуемую статусную информацию. Вещательная система организует и всю вспомогательную работу. Так, Менеджер Сеанса отслеживает список проигрывания и выдает команды для копирования титулов из MediaStreamer Archive в MediaStreamer.
6. Опыт применения MediaStreamer
В заключение интересно привести мнение представителей Graff Pay-Per-View, одного из заказчиков системы MediaStreamer. Эта компания является поставщиком ПО для систем Pay-Per-View и других новых видеотехнологий. В область интересов Graff входят как разработка мультимедиа, так и сетевые средства его доставки.
В начале 1995 года компания приступила к созданию центра доставки видео в Нью-Йорке. Обращаясь к технологии MediaStreamer, разработчики Graff исходили из того, что в современных условиях телевизионные сети, основанные на видеолентах, имеют весьма ограниченные возможности. Опыт последующего развития в целом подтвердил правильность выбранного пути. Опора на MediaStreamer позволила наращивать сеть быстро, эффективно и с меньшими затратами, чем при традиционных подходах, использующих аналоговый сигнал. Сейчас Graff располагает тремя сетями, и, как особо отмечает вице-президент компании Рич Кирби, все они по-прежнему обслуживаются одним сервером MediaStreamer. Для используемого режима доставки Pay-Per-View особенно важно, что сервер параллельно передает сразу множество разных титулов, а смена программы и запуск нового фильма происходит практически мгновенно.
Литература
[1] RS/6000 Newsletter. IBM Austria, Central Europe&Russia, May 1997.
