Sun: системы управления цифровыми медиа-данными

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

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

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

1. Время технологий мультимедиа

Все вышесказанное прекрасно понимают в компании Sun, которая является одним из главных действующих лиц на рынке систем мультимедиа. Далее для обозначения таких систем будем использовать предложенный Sun термин - системы DMM (Digital Media Management).

Рассуждения о необходимости систем DMM будут иметь абстрактный характер, если не принимать во внимание временной фактор: насколько своевременно широкое распространение технологий мультимедиа? Приводимый ниже анализ, опирающийся на [1], выявляет множество тенденций, свидетельствующий в пользу положительного ответа.

В настоящее время к медиа-индустрии можно отнести большую группу производств с суммарным годовым доходом 300 млрд. долл. и его распределением, показанным на рисунке 1 [2].

Вся нижняя часть пирамиды (Рисунок 1), за исключением вершины - создания, представляет собой потенциальный рынок для систем DMM и иллюстрирует их финансовую базу. В табл. 1 приведены данные о годовом доходе различных отраслей медиа-индустрии [3].

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

То же самое происходит и с распространением: появились Internet, компакт-диски, кабельное телевидение, цифровое спутниковое вещание, цифровые видеодиски (DVD). Цена памяти для хранения медиа большого объема продолжает падать: жесткий диск стоит примерно 1 долл. за Мбайт, оптический диск - 4 цента за Мбайт, компакт-диск - 1 цент за Мбайт, и перезаписываемый DVD - потенциально доля цента за Мбайт. Многие предприятия создали инфраструктуру цифровых сетей для поддержки своей деятельности, но по этим же электронным каналам можно вести централизованное оперативное обслуживание цифровым медиа. Благодаря всему этому цифровые медиа-продукты в Web, на DVD и CD-ROM вошли в нашу жизнь.

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

Последнее обстоятельство состоит в том, что системы DMM рождаются снизу, из профессиональной практики, и можно привести множество примеров их успешного применения. Один из мотивов распространения DMM - возможность многократного использования медиа-документов и их частей. Пример из области кинематографа: компания Disney создала продолжение известного художественного фильма "Аладдин", используя оригинальную ленту, которая хранилась в цифровой форме. Это позволило выпустить новую часть быстро, пока публика еще не забыла начало. Другая плодотворная для DMM область - книгоиздательство. Так, в медицинском издательстве Mosby-Year Book часто используются типовые изображения, например сердце человека. Редактор книги постоянно вынужден решать проблему: заказать ли новые иллюстрации или попытаться найти их в фонде издательства. Любое из этих решений требует усилий и денег, а с библиотекой цифровых изображений можно найти требуемое за считанные минуты, и на этом экономятся недели производственного цикла.

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

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

2. Системы DMM - открытое решение

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

Некоторые медиа-организации самостоятельно разрабатывают прототипы DMM, малые DMM. Возрастает и число решений DMM масштаба предприятия, однако многие из них ограничены нишей, которую можно назвать архитектурой "силосной башни". Такие частные решения обладают узкой областью применения и недостаточной гибкостью - в результате приходится строить несколько "силосных башен", плохо согласованных друг с другом. Область управления мультимедиа - новая, и можно рассчитывать, что здесь удастся избежать ошибок и заблуждений, характерных для истории прикладных технологий, зародившихся в 70-х гг., систем CAD, например. Именно поэтому сейчас большое значение имеет выбор правильных архитектурных решений.

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

3. DMM - точка зрения Sun

Компания Sun определяет DMM, как системы и технологии для оцифровки, индексации, хранения, извлечения и обеспечения безопасности цифрового медиа в распределенной сетевой среде. Концепция DMM включает следующие основные элементы:

1. централизованное хранилище цифровой информации всех типов и форматов;
2. совокупность процессов для загрузки документов в хранилище и их каталогизации;
3. способы поиска и доставки единиц хранения.

Системы DMM должны обладать следующими свойствами.

• Интеграция: все типы данных необходимо хранить в едином логическом пространстве.
• Автоматизация накопления: ручной труд по каталогизации и индексации нужно свести к минимуму.
• Доступность: документы должны быть доступны с настольных компьютеров, снабженных надлежащим клиентским ПО.
• Извлекаемость: документ должен быть легко найден по его характеристикам.
• Стыкуемость со смежными технологиями: необходимо, чтобы клиентское ПО гладко стыковалось с популярными средствами обработки и создания содержания документов.
• Многоцелевое использование: документы нужно хранить в максимальном из применямых на практике разрешении, так чтобы их можно было легко преобразовать в различные форматы.
• Защита: единицы хранения дожны быть открыты только для лиц с надлежащими правами доступа, а где необходимо, следует обеспечить защиту интеллектуальных прав собственности.

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

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

4. Эталонная архитектура DMM

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

• Хранилище: сервер БД, на котором хранятся документы и который поддерживает различные способы доступа к ним.
• Загрузчик: множество процессов, автоматизирующих загрузку содержания в систему, включая запись, каталогизацию и индексацию.
• Сервер доставки документов: клиенту в виде файлов либо в виде битового потока.
• Браузер: по минимуму - это тонкий клиент, создающий среду для составления запросов, поиска и просмотра/проигрывания медиа-документов. Расширения браузера для "толстых" клиентов реализуются через сервисы.
• Клиентские сервисы: они являются средством расширения функциональных возможностей браузера. Основные сервисы - запросы к хранилищу и интегрирование производственного цикла, однако ими набор сервисов не ограничивается.

4.1. Хранилище

Хранилище - это локализованная на сервере подсистема, обслуживающая размещение, управление и локальный доступ к медиа-документам. Как известно, системы DMM предъявляют дополнительные, по сравнению с файл-серверами, требования к серверной стороне, которая должна иметь мощные средства БД и массовой памяти, полосе пропускания сети, управления и электронного распространения.

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

Система хранения должна обеспечивать несколько видов представления документов. Каждый документ должен иметь уменьшенную копию - миниатюру (thumbnail), которая компактно представляет его и возвращается пользователю в списке результатов запроса. Такое представление может быть заголовком (для текстовых объектов), уменьшенным изображением (для графики), пятисекундным отрывком аудио- или видеоклипа. Различные формы представления могут применяться для ограничения доступа и сохранения авторских прав. Представление "только для просмотра" дает пользователю возможность смотреть на объект, но не редактировать его. Примеры такого представления - формат Adobe Acrobat PDF, изображения в формате экрана, видео QuickTime, формат фото Kodak FlashPix.

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

4.2. База данных

База данных как по занимаемому в архитектуре месту, так и по значению является ядром DMM. Сейчас наибольшей популярностью пользуются реляционные БД (РБД), обладающие мощным потенциалом, масштабируемостью, стандартным языком запросов по атрибутам SQL. Однако при управлении медиа-данными они обнаруживают существенные недостатки.

Главный недостаток состоит в том, что РБД изначально не проектировались для хранения исходных, полных документов. Тип данных BLOB (Binary Large Object), который используется в РБД для хранения произвольных массивов двоичных неструктурированных данных, не имеет сколько-нибудь развитых методов доступа, оставляя на приложении определение всей семантики объектов хранения. Поэтому системы DMM, основывающиеся на РБД, проектируются так, что каждый документ представляется записью (кортежем), одно из полей которой отводится для указателя на отдельный файл с полным содержанием документа. По такой же схеме в DMM часто реализуется иерархический доступ.

РБД не слишком удобны для представления отношений "используется в" и "содержится". Вообще, в реляционных системах трудно представлять отношения между конкретными объектами. Структуры данных в РБД плохо подходят для полной индексации текста. По этой причине в системы DMM, опирающиеся на РБД, дополнительно включают средства полнотекстового поиска. Стоит, однако, иметь в виду, что такие разработчики, как Informix, Oracle и IBM, работают над улучшением способов работы с текстом в РБД.

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

Например, система DMM, построенная на ООБД, может иметь тип данных content-object с операцией play. На следующих уровнях иерархии могут быть подтипы для объектов со специфическим содержанием: audio-object, video-object, animation-object, и подтипы для специфических форматов: WAV-audio-object, MPEG2-video-object. Независимо можно ввести тип text-index, определив для него операции автоматической индексации и выполнения запросов. В ООБД в число атрибутов могут включаться указатели на индивидуальные объекты, что позволяет легко реализовать упомянутые выше отношения вхождения документов.

Резюмируя, можно сказать, что ООБД сами по себе имеют потенциал, чтобы стать законченным решением для систем DMM (на серверной стороне). Считается, что ООБД уступают реляционным системам в надежности, работоспособности и возможностях передачи данных - характеристиках, существенных для масштабируемости. Ожидается, однако, что новый Universal Server компании Informix, в котором объединены "объектно-реляционные" средства Illustra с масштабируемостью самой Informix, сможет преодолеть эти недостатки. Программное обеспечение DataBlade, входящее в Informix Universal Server, хорошо согласуется с предлагаемой Sun архитектурой DMM. Помимо того, что в DataBlade имеется возможность определять семантику новых типов данных непосредственно в БД, объектно-ориентированный интерфейс программиста DataBlade реализует многие из сервисов, относящихся к уровню 2 архитектуры (Рисунок 2).

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

DMM опирается на нижележащую файловую систему сервера. Чтобы реализовать стратегию хранения данных, от файловой системы требуется поддержка управления томами и иерархического управления памятью (HSM). HSM, грубо говоря, - это примерно то же самое, что виртуальная память для физической ОП: она позволяет рассматривать различные уровни памяти (жесткие и оптические диски, МЛ) как одну большую файловую систему. Если пользователь или приложение открывает файл, тогда он либо уже находится на диске, либо HSM считывает его с автоматически устанавливаемого устройства (оптического диска), либо извещает оператора о необходимости смонтировать отключенный том (МЛ с полки).

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

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

4.3. Загрузчик

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

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

До сих пор не существует возможности автоматического выделения нетривиальной информации из изображений, аудио и видео, но некоторые разработчики (Kodak, LivePicture, Virage, Excalibur) занимаются исследованиями в этой области. Иногда атрибутные метаданные могут генерироваться просто путем извлечения информации из определенных форматов данных. Лучший пример этого - некоторые форматы файлов ОС Apple Macintosh (применяемые, например, в Adobe Photoshop), которые содержат массу полезной информации.

В издательской деятельности возможна автоматическая генерация связей для отношений "содержится" и "используется в" путем разбора языка компоновки страниц и выделения элементарных объектов из составных документов. Чем более структурирован язык составления страниц, тем легче выделять информацию: форматы с высоким уровнем структуризации, подобные Adobe FrameMaker и SGML, удобнее, чем форматы со специальной структурой типа QuarkXPress и Word, хуже всего интерпретируются форматы, не имеющие структуры, - PostScript и PDF.

При загрузке добавляются не только метаданные, но и вспомогательные представления документов. В значительной степени может быть автоматизирована генерация миниатюр. Некоторые графические форматы и форматы представления изображения (тот же Adobe Photoshop) содержат свои собственные миниатюры, для других, например для изображений с высоким разрешением, можно сгенерировать их на лету. Аналогично можно спроектировать загрузчик таким образом, чтобы он, получая аудиообъекты с качеством CD, создавал клипы первых нескольких секунд в формате WAV 10 КГц. Таким же образом видео MPEG-2 может преобразовываться в клипы QuickTime. Единственный вид деятельности по созданию миниатюр, который требует ручного труда, - это текстовые объекты без заглавий.

4.4. Сервер доставки документов

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

Требования к вычислительным ресурсам, необходимым для передачи документов, качественно отличаются от требований к подсистеме хранения, к тому же они должны жестко выдерживаться. Поэтому Sun в эталонной архитектуре DMM выделяет отдельный сервер доставки. В первую очередь этот сервер должен иметь широкую пропускную полосу для доступа к объектам в БД. В идеале медиа-память должна допускать многосерверный доступ так, чтобы БД разделялась между сервером хранения и сервером доставки, как и показано на рисунке 2.

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

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

4.5. Браузер

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

Браузер создает интерфейс с сервисом запросов и должен обеспечивать следующие функции:

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

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

4.6. Сервисы клиента

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

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

5. Практические решения Sun

Каковы позиции Sun в области работы с медиа-информацией? Наиболее известны достижения компании в издательской деятельности и Web-технологиях. Настольные издательские системы на базе рабочих станций Sun представляют собой платформу для профессиональной работы с изображениями и компоновки документов. Один из стратегических принципов Sun - интероперабельность с сетями ПК и Apple Mac. Рабочая среда Apple поддерживается выпускаемыми партнерами Sun - IPT, Helios и Sonic Solutions, оптимизированными продуктами объединения сетей. Эффективная связь между серверами Sun и клиентским ПО на PC позволяет гладко интегрировать деловые и медиа-приложения в рамках единого производственного цикла предприятия.

Самые распространенные средства распределенной обработки медиа - Web-технологии. Здесь у Sun имеются авторские системы для подготовки документов в формате HTML и, конечно, фирменный продукт - Java. Sun - одна из компаний, занимающихся разработкой и продвижением на рынок Web-терминалов. Хотя эти системы и не годятся для авторской деятельности, они полностью соответствуют ориентации компании на тонкого клиента и пригодны для просмотра, проигрывания и взаимодействия по сети.

Все эти решения Sun хорошо известны, и далее рассмотрим позиции компании в области доставки видео, а также основной продукт - систему MediaCenter.

5.1. Серверы Sun MediaCenter

Система доставки цифрового медиа Sun MediaCenter состоит из семейства серверов (табл. 2) и специализированного ПО.

Рассмотрим подробнее одну из моделей сервера - Sun MediaCenter UltraSPARC. Это высокопроизводительная масштабируемая система с невысокой стоимостью базовой конфигурации. Как и все модели этой линии, она предназначается для организаций, занимающихся доставкой цифрового видео по сетевым и вещательным каналам в режиме video-on-demand. Что же для этого имеется?

MediaCenter UltraSPARC базируется на сервере Sun Ultra Enterprise 2 и имеет масштабируемую многопроцессорную архитектуру с двумя процессорами UltraSPARC 167 МГц, каждый с 512 Кбайт памяти на чипе и 2 Мбайт кэш-памяти на модуль. Обмен данными между процессорами, памятью и портами ввода/вывода осуществляется пакетным переключателем с малой задержкой. Из 50 Гбайт внешней памяти Raid-4, 42 Гбайт - это чистая память для хранения видео, и еще 8 Гбайт используются для контроля четности. Новая версия 2.0 ПО MediaCenter позволяет масштабировать внешнюю память 100 Гбайт (124 часа видео при компресии 1,5 Мбайт/с). Сетевые интерфейсы в стандартах ATM, Fast Ethernet, Ethernet обеспечивают гарантированную пропускную способность 100 Мбит/с для передачи видео.

Серверы MediaCenter конфигурируются перед продажей всеми необходимыми компонентами для хранения и доставки видео. База - это операционная система Solaris, которая дополнена ПО MediaCenter, специализированным обеспечением, превращающим файл-сервер Ultra Enterprise в медиа-сервер. Как обычно, в системах такого класса большое внимание уделяется надежности. Сервер Sun MediaCenter защищен от сбоя одного диска механизмом контроля четности Block-Interleaved Parity, соответствующим Raid Level 4. Средства системного администрирования включают горячее подключение и замену дисков без перезагрузки системы, управление размещением медиа-документов и мониторинг сети.

5.2. ПО Sun MediaCenter

Специальное ПО Sun MediaCenter включает:

• модифицированное ядро Solaris;
• модифицированные драйверы сетевых интерфейсов, настроенные на вывод мультимедиа;
• файловую система MFS, оптимизированную для доставки изохронного, - удовлетворяющего строгим временным ограничениям, битового потока;
• менеджер медиа-потока MSM, позволяющий управлять приходящими от сервера и проигрываемыми потоками;
• менеджер документов CM, используя который пользователь может загружать документы на сервер.

Оба менеджера - MSM и CM - поддерживают интерфейс с программой-клиентом на основе протокола удаленного вызова процедур RPC.

5.2.1. Файловая система и ввод/вывод

Sun MediaCenter - это не просто обычный сервер с большим количеством памяти и дискового пространства. Отличия обнаруживаются уже на нижнем уровне программного обеспечения - в системе управления медиа-файлами (MFS) и в драйверах сетевых интерфейсов. Благодаря этому сервер обладает двумя важными свойствами.

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

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

5.2.2. Модель выталкивания

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

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

Достоинства модели "выталкивания" очевидны - она более простая, а значит, принимающее устройство может быть более дешевым. Именно эту модель односторонней передачи поддерживает ПО Sun MediaCenter. Например, драйверы сетевых интерфейсов поддерживают только вывод. Клиентское API MSM имеет процедуры для определения требуемого адресата, но не позволяет установить какие-либо параметры по этому адресу.

5.2.3. Сквозное проигрывание

Сквозное проигрывание (playthrough) - это интересная особенность, дающая возможность начать проигрывание документа еще до того, как он полностью загружен в сервер. В последней версии Sun MediaCenter можно начинать проигрывание уже через 5 секунд после начала загрузки. Сквозное проигрывание необходимо для приложений с быстрым и непрерывным обновлением содержания. Этот режим не налагает никаких ограничений на тип документов - они могут быть любыми, единственное ограничение в том, что поток может проигрываться только в нормальном режиме в прямом направлении. Сквозное проигрывание поддерживается менеджером документов (CM) и менеджером потока (MSM), так что можно писать собственные программы, которые почти одновременно записывают и проигрывают документы с сервера. Утилиты CM, распознавая режим сквозного проигрывания, предотвращают преждевременное уничтожение документов. Режим playthrough развивает метод оперативной загрузки, который имелся в ранних реализациях и заключался в способности сервера одновременно загружать один и проигрывать другой документ. Теперь то же самое можно делать и с одним документом.

5.2.4. Видеофайлы

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

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

5.2.5. Загрузка титулов по FTP

Демон FTP программного обеспечения MediaCenter расширяет обычные функции протокола удаленной передачи файлов на видеофайлы. Клиент FTP может загружать их в сервер Sun MediaCenter с любой аппаратно-программной платформы. Демон FTP не только поддерживает саму передачу, но и, используя менеджер документов, выполняет преобразование в формат видеофайлов, добавляя все вспомогательные файлы. Эта фунция FTP иллюстрируется на рисунке 3.

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

5.2.6. Интерфейсы

Клиенты связываются с сервером Sun MediaCenter с помощью двух API (Рисунок 4) - MSM Client API (MSMC) и Content Migration Client API, последнее служит для перемещения документов между разными серверами Sun MediaCenter, а также между сервером и устройством третичной памяти. Для загрузки документов есть отдельное Content Manager Client API и утилиты Content Manager.

Все интерфейсы и спецификации по подготовке документов, их загрузке, управлению видеовыводом опубликованы и согласованы с общей архитектурой системы доставки видео, специфицированной в [5]. Такой уровень определения продукта открывает все возможности для использования Sun MediaCenter в качестве сервера в системах video-on-demand.

5.2.7. Клиентское API MSMC

API MSMC - это программный интерфейс пользователя для проигрывания видеопотоков с сервера Sun MediaCenter. Поддержку этого API обеспечивает менеджер потока (MSM), являющийся агентом клиента на сервере. Скрывая все детали управления и передачи видеопотоков, API MSMC предоставляет пользователю несколько абстракций: титулы (медиа-документы) и список титулов для проигрывания. Операции над титулами полностью имитируют управление обычным видеопроигрывателем: воспроизведение, быструю перемотку, обратное проигрывание.

Основные свойства API MSMC: концепция проигрывателя, списка проигрывания, титулов; различные режимы проигрывания; проигрывание титулов по расписанию; контроль доступа к проигрывателю; параллельный доступ к одному списку проигрывания нескольких клиентов.

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

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

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

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

5.2.8. Управление доступом к серверу и плейеру

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

Литература