В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Media eXchange Format предназначен для упрощения процесса переноса материалов из одной системы в другую, независимо от того, кем они были произведены. MXF (Media eXchange Format) на данный момент столь широко употребляемая аббревиатура, что интересоваться вопросами технической поддержки MXF у фирмы-производителя стало как-то неловко, словно спрашивать: "Можно ли ваше оборудование включать в сеть на 220 вольт?". На самом деле "замыливание" термина скрывает как его преимущества, так и недостатки до такой степени, что теряется изначальный смысл того, ради чего и был придуман сам формат
Если производитель некоего оборудования и/или программного обеспечения заявляет, что его изделие поддерживает MXF (или даже он является "родным"), то это, конечно, вносит некую уверенность в душу потенциального пользователя. Но наиболее "продвинутые" из них предпочтут уточнить: какие варианты MXF поддерживаются при операциях импорта/экспорта файлов. И вот тут-то и начинается самое интересное: выясняется, что поддерживаться могут далеко не все варианты, причем необходимой комбинации может и не быть. Получается забавная ситуация, напоминающая "базарный день": вроде как все с грехом пополам говорят на одном языке, но со столь разными акцентами, что понять друг друга можно только с переводчиком. В реальной ситуации это означает следующее: чтобы "подружить" между собой две системы разных фирм, может понадобиться третья, постоянно занятая "высокоинтеллектуальной" работой по преобразованию MXF в MXF. Далее я попытаюсь объяснить, в чём же состоят различия между вариантами.
MXF - контейнер для аудио-, видеоматериалов
В самых общих чертах структура файла MXF достаточно универсальна для того, чтобы объединять в единое целое как собственно аудио-, видеоматериалы, так и связанные с ними данные, тексты, различные описания - все, что в просторечии называется словом "метаданные". При переносе MXF-файла из одной системы в другую каким-либо стандартным способом (например, по FTP) все метаданные сохраняются и должны корректно восприниматься и обрабатываться на приемной стороне. MXF не зависит от операционных систем, процессоров, порядков бит и других низкоуровневых "тонкостей". Внутри "организма" систем MXF-файл может как "распиливаться" на составляющие части, так и обрабатываться непосредственно. MXF-файл представляет собой некий контейнер, объединяющий разнородные данные в единый блок.
Всё казалось бы очень хорошо, но если присмотреться к деталям, то возникает довольно много вопросов.
Проблема стандартизации данных
И чем дальше, тем больше вопросов. Некоторые из них, к счастью, были решены на начальном этапе. В частности, проблема стандартизации данных, которые могут храниться в MXF-файле, так называемые "тэги". Их стандартизовано более 1500, если кому-то их окажется недостаточно, то формат позволяет добавлять свои собственные типы данных. Текст может сохраняться в Unicode, но синхронизация версий на разных языках остается на совести пользователя, вносящего изменения. Аудио- и видеоданные могут храниться как целиком, так и перемежающимися блоками, что очень удобно для стриминговых приложений.
Для упаковки аудио-, видео- и метаданных используется метод KLV (Key-Length-Value),относящийся к Unix-системам.
Возникает вопрос: а почему, например, не "вездесущий" XML? Метод KLV относительно прост, но менее универсален, чем XML, он позволяет легко внедрять в контейнер блоки бинарных данных (видео, аудио). С другой стороны, XML очень хорош для хранения структурированных цифровых и текстовых данных и максимально расширяем, но не слишком хорошо приспособлен для хранения бинарных данных большого размера, которые и составляют большую часть MXF-файла. Для взаимного преобразования XML<->MXF разработана стандартная схема, которая должна использоваться при кодировании/декодировании метаданных.
Для оптимизации MXF под различные цели были разработаны так называемые паттерны (Operational Patterns), которые существенно различаются между собой. С одной стороны, они упрощают использование MXF для конкретных применений, с другой - вносят "разброд и шатание" в общее стремление к стандартизации способов обмена материалами. Паттерны нумеруются в порядке "от простого к сложному", и каждый последующий паттерн включает в себя функциональность предыдущего. Ниже мы рассмотрим их основные параметры.
Самый "простой" способ сохранения разнородной информации - это "слить" все в одну папку " Мои документы". Примерно эта же идея используется в паттерне OPAtom - метаданные хранятся в MXF-файле, видео и аудио могут храниться как "внутри", так и "снаружи". Ограничение состоит в том, что одному материалу соответствует один MXF-файл, в котором упаковано либо только видео, либо только аудио в единственном варианте. MXF-файлы могут содержать "зашитые" ссылки друг на друга, что обеспечивает их логическую связь. Все-таки было проще и надежней иметь возможность переносить материал в виде единственного файла, который мог бы содержать все составные части готового материала и все возможные метаданные вместе, поэтому разработчики MXF на этом не остановились и создали еще целый набор "продвинутых" паттернов.
OP1-3
Для более сложных случаев имеются другие паттерны, различия между которыми проще показать на рисунке.
Рис. 1 требует некоторого пояснения. MP (Material Package) - это логические "блоки" готового материала, a FP (File Package) - это "блоки" файлов, из которых собирается готовый материал. Паттерны OPla, OPlb всегда содержат один программный материал, созданный из одного набора исходных аудио-, видеофайлов. Паттерны ОР2Ь, ОР2с целиком "заглатывают" исходные файлы при формировании материала, а ОРЗЬ и ОРЗс формируют материал из произвольных "кусков" исходных файлов. Паттерны OPlc, OP2c и ОРЗс предназначены только для "законченных" материалов (не подлежащих дальнейшему редактированию) и не содержат "исходников". Проще говоря, "младшие" паттерны позволяют упаковать в контейнер один-единственный материал (возможно, в нескольких разрешениях), "старшие" позволяют хранить плейлисты и EDL даже в нескольких вариантах, что может быть важно при переносе между системами нелинейного монтажа. Паттерны старшей версии совместимы с предыдущими и как бы поглощают их функциональность. Не секрет, что MXF - это "урезанный" вариант AAF (Advanced Authoring Format), и "старшие" паттерны ближе по возможностям к "прародителю", то есть MXF - это частный случай AAF-файла. Но есть и существенные различия. В частности, AAF использует для этого MSS (Microsoft Structured Storage) для "упаковки"; в MXF-файлах используется метод KLV.
Объять необъятное...
Распространение MXF также сдерживается его довольно сложной структурой. Объять необъятное непросто, поэтому здесь не обойтись без помощи различных SDK, таких, как MXF::SDK (MOG Solutions), MXF Toolkit (OpenCube), MXF Express (Snell&Wilcox). Для преобразования паттернов может использоваться специализированное ПО, созданное с помощью упомянутых выше SDK. Было бы хорошо обойтись безо всяких промежуточных преобразований. Но что же делать, если, например, есть 2 системы с поддержкой MXF, но одна из них "понимает" только OPAtom, a другая только OPla, и требуется некая "прослойка" для их интеграции. Прекрасное цифровое и безленточное будущее, где виды оборудования "дружат" между собой, практически уже совсем близко, но однако же еще не наступило.
Главный специалист Snell & Wilcox
Дмитрий Иванов
Опубликовано: Журнал "Broadcasting. Телевидение и радиовещание" #5, 2005
Посещений: 30884
Статьи по теме
Автор
| |||
В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
