При всём многообразии
существующих сегодня систем
нелинейного видеомонтажа (NLE), немногие
из них могут похвастаться продвинутыми
сетевыми возможностями, позволяющими
объединить несколько монтажных
станций для совместной работы с единым
дисковым массивом.
Такие системы, конечно, есть, но
практически все они базируются на
специализированных дисковых массивах
и дополнительном, отмечу, весьма
недешёвом, программном обеспечении.
Вы спросите - зачем вообще нужны
функции сетевой обработки?
Отвечу – поддержка этих функций
существующими у вас станциями NLE
обеспечивает одновременную работу над
одним и тем же материалом сразу
нескольких подразделений постпродакшн.
При правильной организации процесса
это позволяет значительно (иногда в
несколько раз) сократить сроки работы
над проектом, а значит, быстрее
приступить к следующему и как итог –
увеличить прибыль. Наличие подобных
возможностей у систем NLE может быть
критично в тех случаях, когда скорость
монтажа имеет первостепенное значение,
например для ежедневных сериалов, Reality
шоу, цикловых передач, новостей и т.д.
Так в чём проблема – опять спросите вы?
Зачем нам тратить деньги на дорогое
решение? Мы просто объединим несколько
нелинейных станций высокоскоростной
сетью и, пожалуйста, получим «сетевое
решение».
Конечно, можно сделать и так. Но здесь
не всё так просто, как кажется на первый
взгляд. Просто объединив NLE станции
сетью, вы получите только возможность
пересылать между ними медиаданные и
проекты. Однако, если Вы захотите
работать совместно над одним и тем же
проектом с нескольких рабочих мест, у
вас вряд ли что-нибудь выйдет. Во-первых,
большинство программ, например Adobe
Premiere, вообще не позволяют открывать
один и тот же проект с нескольких
рабочих мест – в нем может работать
только та станция, которая открыла его
первая. Во-вторых, для доступа к одному
файлу с двух и более машин необходимо
применять специальные программные и
аппаратные решения.
Можно конечно сделать копию проекта и
открыть её на другой станции, но на
перенос материала вы потратите и
драгоценное время, и не менее дорогое
дисковое пространство. Хорошо, если это
рекламный ролик, а если это фильм, или
вообще целый сериал?
Так существуют ли системы NLE,
позволяющие полноценно работать в сети
и открывать одни и те же проекты сразу с
двух или более станций, обращаясь к
одному и тому же видеоматериалу
ОДНОВРЕМЕННО? Отвечу - Есть!
Но здесь встает вопрос выбора, как
самой нелинейной системы, так и средств
обеспечения сетевой обработки, и на
этом пути нас поджидает много «подводных
камней». Вот об этих «камнях» для
начала и поговорим.
Первая проблема техническая –
необходимо обеспечить одновременный
доступ со всех станций к одному и тому
же видеоматериалу, причём с
гарантированным потоком. Эту проблему
можно решить несколькими способами –
например, с помощью организации NAS (Network
Attached Storage) или SAN (Storage Aria Network).
Для тех, кто не знает или не помнит,
немного расскажу, что это за технологии
и какая между ними разница. Определимся
в терминологии – SAN-ом чаще всего
называют всю систему, состоящую из
массива, рабочих станций, программного
обеспечения и даже FC-коммутатора. NAS-ом
же обычно называют собственно дисковый
массив, в комплекте с NAS-сервером.
Фактически, SAN - это комбинация
аппаратных средств и ПО, позволяющая
большому числу пользователей хранить и
совместно использовать информацию. При
этом данные не хранятся на сервере сети.
Доступ к данным в SAN осуществляется на
уровне блоков (в отличие от NAS, где
доступ реализован на уровне файлов).
Основная идея SAN состоит в отделении
устройств хранения данных от сервера и
сетевой ОС. Средой передачи в SAN могут
быть как медный Fibre Channel кабель (длиной
до 25 м), так и оптоволоконный кабель
длиной до 10 км, интерфейс позволяет
передавать данные со скоростью 1 Гб/с и 2
Гб. При этом, возможно разделить потоки
– пустить медиаданные по Fibre Channel, а
метаданные – по обычному Ethernet. За счёт
исключения из трафика служебных
пакетов скорость передачи данных в SAN
гораздо ближе, по сравнению с NAS, к
своему теоретическому максимуму.
Надо упомянуть так же о том, что SAN можно
создать и с использованием обычного SCSI
интерфейса, вместо FC. Это решение будет
значительно дешевле Fibre Channel, при
сохранении той же скорости, однако
обладает рядом недостатков. В
частности, расстояние между станциями
и массивом не может превышать 5 метров,
что обусловлено ограничениями
интерфейса SCSI. Поэтому решения на
основе SCSI пригодны там, где при
ограниченном бюджете нужно объединить
небольшое количество станций,
находящихся близко друг от друга.
Технология NAS в качестве интерфейса
передачи данных использует Gigabit Ethernet (рис
1). Однако это не просто локальная сеть.
Как известно, при традиционной схеме
прямого подключения систем хранения
данных (DAS) универсальный сервер
перегружен функциями файл-сервера (функциями
работы с файлами). NAS-серверы снимают
эту нагрузку с универсального сервера,
что повышает его производительность
при работе с приложениями. Они отвечают
за организацию совместного доступа к
данным (хранящимся в NAS-серверах в виде
файлов) и управляют передачей данных
между подключенными к ним устройствами
хранения и рабочими станциями.
Рис.1 Сетевая структура нелинейного
монтажа при использовании NAS
например, им не нужны монитор,
клавиатура или "мышь").
Характерной особенностью NAS-серверов
является также их независимость от
операционной системы (ОС) и работа под
управлением ОС, оптимизированных для
работы с файлами в сетевом окружении (или
специализированной микрооперационной
системы реального времени). NAS-серверы
работают со встроенными ОС MS Windows, Unix,
Linux или собственной ОС от производителя.
Как видим, помимо интерфейса (и среды
передачи данных), существенным
отличием NAS является то, что основной
его частью является пусть
специализированный, но всё же файл-сервер.
В SAN же, в общем случае, сервера может и
не иметь, но тем не менее, каждая из
рабочих станций будет видеть этот
массив как «свой». При использовании
технологии NAS локальная сеть
используется как для обмена данными
между устройствами хранения, так и для
передачи пользовательского трафика на
рабочие станции, так как обмен данными
между клиентскими ПК и NAS-серверами
осуществляется в той же сети. Так как
передача данных идёт через сети Ethernet,
общая производительность NAS не очень
высокая (из-за ограничений, характерных
для технологии Ethernet).
Таким образом, в приложении к
видеомонтажным пакетам, SAN имеет то
преимущество, что позволяет получить в
среднем больший гарантированный (если
надо – выделенный) поток для каждой
отдельной станции. Зато построение NAS
обходится значительно дешевле. Поэтому
Выбор между двумя технологиями
определяется, прежде всего, задачами,
стоящими перед системой и выделенным
бюджетом, с учетом того, что их можно
комбинировать. Кроме этого,
понадобиться программное обеспечение,
называемое «Sharing software» которое
позволит вам иметь одновременный
доступ к одним и тем же материалам. В
случае NAS оно, как правило, уже встроено
в NAS-сервер, и на рабочую станцию ничего
дополнительно ставить не надо, если же
мы имеем дело с SAN, то данное ПО
необходимо установить дополнительно.
Предположим что с большими или
меньшими затратами аппаратная
проблема решена - мы имеем дисковое
пространство, доступное одновременно с
двух станций (Рис. 2). Теперт мы садимся
за работу, оцифровываем материал на
одной из машин и начинаем монтаж
Рис.2 Сетевая структура систем
нелинейного монтажа на базе SAN
В какой-то момент возникает
необходимость воспользоваться этим же
материалом на другой рабочей станции.
Казалось бы никаких проблем – доступ к
файлу мы имеем, воспроизвести его можем,
вставить в таймлинию – без проблем…
Без проблем? А как быть с метаданными?
Поясню на примере, о чём идёт речь:
пусть мы имеем видеофайл в формате *.AVI,
а этот видеоформат (как впрочем, и все
другие компьютерные форматы, исключая
DV) не содержит ни информацию о таймкоде
оригинальной кассеты, ни номер кассеты,
следовательно, экспортированный таким
образом файл нельзя будет
автоматически «переоцифровать» при
необходимости, используя кассету-исходник.
А эта возможность – абсолютно
необходимая вещь, как для чернового
монтажа, так и вообще при работе с
большими проектами. Дело всё в том, что
вся эта информация, называемая «метаданные»
хранится не в медиафайле (не важно AVI
или Quick Time), а в самом проекте и
добраться до неё можно только, открыв
этот самый проект. Наиболее простой
выход напрашивается сам собой - надо
сделать копию проекта и открыть её на
второй станции, поскольку все
метаданные и ссылки на материал там
есть, то проблем возникнуть не должно.
Но если этот проект открыт на второй
рабочей станции, то в результате первых
же монтажных действий мы получаем уже
два РАЗНЫХ проекта, изменения в которых
несогласованны. Такая схема имеет
право на жизнь в случае, если
функционально разделить назначение
станций – например, одна из них
занимается только вводом материалов, а
другие только монтажом (Рис.3).
Алгоритм следующий – вводим кассету
или несколько кассет на станции ввода,
закрываем проект, открываем новый и
продолжаем ввод. Станция монтажа
открывает проект, в котором
производилась «оцифровка» и начинает
работу, в то время как первая
продолжает ввод, то есть налицо
экономия времени. Однако во многих
случаях такая схема неудобна, а в
некоторых – неприемлема. Во-первых, она
превращает в «неполноценную», по
крайней мере, одну из монтажных станций
поскольку используется только
небольшая часть её возможностей,
конкретно - ввод. Во-вторых, есть
существенная задержка по времени от
начала процесса ввода до начала
монтажа. В-третьих, такая схема работы
приводит к генерации огромного
количества проектов, которые тяжело
администрировать.
Надо отметить, что некоторые
нелинейные пакеты имеют специальные
дополнительные программные (иногда
программно-аппаратные) решения,
которые позволяет сильно облегчить
ситуацию. Яркий пример – Discreet JobNet - этот
пакет позволял объединять несколько
станций Discreet edit в единую систему,
копировать из проекта в проект
метаданные, клипы, таймлинии, папки с
клипами и т.п. а так же выполнял ряд
других важных функций по
администрированию и мониторингу
системы. Однако, являясь надстройкой
над системой нелинейного монтажа Discreet
edit, пакет разделил её участь – был снят
с производства. Кроме всего прочего он
стоил весьма немалых денег, и в тоже
время не позволял открывать один
проект с нескольких машин. Некоторые
современные нелинейные системы также
имеют нечто похожее на JobNet , однако все
это пока далеко от совершенства и также
стоит очень дорого. Подобные решения
предлагают, например AVID, InCite и
некоторые другие производители.
Ситуация на мой взгляд, в корне
изменилась с появлением последних
версий монтажных систем из линейки Liquid.
«Старшим» продуктом линейки является
Liquid Chrome. В качестве платформы
используется один из самых мощных на
сегодня инструментов – TARGA3000 в
комплекте с 3D-модулем K2. Такая
платформа позволяет системам Chrome
работать с любыми аналоговыми и
цифровыми интерфейсами, в том числе YUV,
SDI, DV и т.д. А также вводить данные в
форматах MPEG2, native DV, Uncompression, то есть
обеспечивать практически любые
требования пользователя – от
сохранения исходного качества до
максимального сжатия материалов. Кроме
Liquid Chrome стоит обратить внимание на её «младшего
брата» - Liquid Editoin (бывший Purple), который
правда может работать только с DV
форматом, зато по стоимости гораздо
доступнее, а по пользовательскому
интерфейсу практически неотличим от
Liquid Chrome.
Главная особенность этих продуктов с
точки зрения использования в сетевых
технологиях – это возможность без
всяких дополнительных программных
ухищрений работать в одном и том же
проекте на нескольких рабочих станциях,
естественно при наличии общего
дискового пространства.
Итак, для построения сетевой монтажной
среды нам как минимум необходим NAS, к
которому мы можем подсоединить нужное
нам количество рабочих станций. На
сегодня производительность подобных
систем, даже с использованием Gigabit Ethernet,
позволяет работать не более чем с двумя
не компрессированными потоками, каждый
около 20МБ/с (для PAL), а при работе с
длинными файлами поток ещё меньше.
Поскольку Liquid Chrome позволяет работать с
4-мя потоками одновременно, этого явно
недостаточно. Минимум, что нам надо –
это обеспечить запись/воспроизведение
двух не компрессированных потоков для
каждой станции Chrome. Арифметика тут
простая – 20+20=40МБ/с – именно столько
надо выделить на общем массиве для
каждой станции. Предположим, для начала,
что станции у нас три, получаем 40х3=120МБ/с
– минимальный гарантированный поток,
который требуется обеспечить в данном
массиве – типичная задачка для SAN. Итак,
всё же придётся использовать SAN…
Хорошо. Пусть мы построили SAN с
необходимой производительностью и
подключили к нему три станции Chrome (Рис.1).
Какие преимущества мы получим?
Рис.1
Первое: мы можем спокойно открывать
один и тот же проект на всех трёх
станциях, более того все изменения в
нём будут сразу «видны» всем
пользователям, то есть все вновь
появляющиеся клипы, титры, эффекты,
заставки и т.д. можно использовать
СОВМЕСТНО.
Второе: мы можем на двух станциях
начать ввод, а на третьей практически
сразу начинать монтаж. Более того,
используя инструмент, называемый Ingest
Tool, можно начинать работать с файлом,
который ещё не полностью «оцифрован».
Как только вы начали «вгонять», скажем,
получасовую кассету, у вас в проекте
появится клип, длительностью 30 минут, у
которого есть начало, но пока нет
окончания (там черное поле). Тем не
менее, та его часть, которая уже
оцифрована, становится доступной и
может быть смонтирована, оттитрована
или подвергнута цветокоррекции. При
правильном распределении задач всё это
позволяет ускорить работу над проектом
в несколько раз. Есть масса областей
применения, где скорость монтажа имеет
первостепенное значение, среди них и
ежедневные сериалы, и Reality шоу, и
цикловые передачи, новости и т.д.
Хорошо, а если надо для ещё большей
скорости обрабатывать одну и ту же
таймлинию с нескольких рабочих станций.
Приведем пример. Допустим, существует
предмонтаж фильма, надо его
подвергнуть цветокоррекции. Можно было
бы для ускорения обработки, особенно
если не вся она может быть выполнена в
реальном времени, разбить тайм-линию на
несколько частей, и обрабатывать
каждую из них на отдельной станции. И
здесь Chrome не подкачал – такой способ
работы возможен. Конечно же, не
напрямую - помните басню «Лебедь, рак и
щука», а теперь представляете что
начнётся, если несколько монтажёров не
сговариваясь, начнут пытаться
корректировать одни и те же клипы?... По
этой причине только тот, кто вошёл в
таймлинию первым, назовем его «Мастер»,
имеет на неё «все права», остальные
могут только просматривать таймлинию,
наблюдать за изменениями в ней, но сами
вносить изменения не могут. Однако «Мастеру»
достаточно разделить тайм-линию на
несколько так называемых «контейнеров»*,
тогда его коллеги, войдя каждый в «свой»
контейнер, без проблем могут работать с
его содержимым. Мастер также может
обрабатывать свою часть, просматривать
текущее состояние любой части
материала, контролируя весь процесс и,
по окончании обработки сбросить
готовый фильм на внешний носитель -
магнитофон, сервер и т.п.
*«Контейнер» позволяет объединить в
выделенной области таймлинии любое
количество клипов вместе с эффектами и
титрами в один «виртуальный клип».
Дальше с ним можно работать как с
обычным клипом.
Хорошо, а если мне не по карману иметь
насколько таких мощных монтажных
станций как Chrome? Скажем, я хочу в
качестве станций чернового монтажа
использовать что-нибудь «полегче». Вот
и настало время вспомнить о «младшем
брате» Chrome - Liquid Edition, недорогой (около 495
$) системе видеомонтажа, обладающей
отличными возможностями и всеми
преимуществами семейства Liquid.
Почему именно о Liquid Edition? Всё очень
просто – проекты, созданные в Edition
полностью совместимы с Chrome и без
проблем открываются в нём. Конечно, по
сравнению с Chrome, станции Edition обладают
урезанными возможностями, однако для
предмонтажа более чем достаточно их
профессионального интерфейса и
корректной работы с тайм-кодом.
Теперь надо решить, как в этом случае
рациональнее построить систему.
Поскольку внутренний формат Edition – это
DV, то нет таких жёстких требований по
потоку как для Chrome, то вполне разумно
будет использование NAS, к которому
будет подключено необходимое
количество «черновых» станций и одна «чистовая»
для окончательной сборки и доводки (Рис.2).
Рис.2
Я тестировал такой NAS, собранный на
основе массива SanStream от компании Huge Systems.
Надо сказать, вещь очень удобная и
представляет собой корпус высотой 2U, в
котором уже встроен Unix-сервер, диски и
сетевые порты. В моём случае это была
конфигурация с массивом на 480 ГБ, с 6-ю
встроенными портами Gigabit Ethernet. Не
требуется никаких настроек, установок
– достаточно его просто включить и
подождать пару минут, чтобы все станции,
подключённые к нему, «увидели» сетевой
диск.
А вот для того, чтобы сохранить все
возможности реального времени Chrome,
обеспечить воспроизведение четырёх не
компрессированных потоков и не
перегружать трафик NAS, разумно
оснастить станцию дополнительным (локальным)
дисковым массивом достаточной
производительности. В этом случае
алгоритм работы следующий: сначала
вводим материал с тайм-кодом на одной (нескольких)
станциях Edition на общий массив, делаем
совместный предварительный (черновой)
монтаж проекта. По окончании монтажа
данный проект «прозрачно» открывается
на станции Chrome, причем весь материал
без проблем «видится» и
воспроизводится с общего массива NAS. На
станции Chrome материал, вошедший в
окончательный вариант таймлинии
автоматически (ведь мы работаем с тайм-кодом)
заново вводится, но уже с «чистовым»
качеством, например баз компрессии, при
этом материал кладётся уже не на NAS, а на
локальный массив. После этого
производится окончательная сборка,
доводка и сброс на мастер-кассету. Как
видим, такая схема организации работы
позволяет:
• Получить большое количество
монтажных мест, при незначительных
затратах.
• Экономить дисковое пространство за
счёт использования DV компрессии при
черновом монтаже
• Значительно ускорить производство
за счёт совместной работы над проектом
на станциях Edition
• При необходимости, работать на
станции Chrome независимо от общей сети
Подчеркну – это не просто
теоретические рассуждения – это
реально работающая схема, проверенная
вашим покорным слугой. И, к слову
сказать, уже работающая на некоторых
российских телеканалах и в частных
телекомпаниях.
Кстати, если возникает необходимость в
дополнительной обработке, то для
интеграции между монтажными и
графическими приложениями, такими как
After Effects, у систем Liquid есть специальный
инструмент, называемый Xsend. Он
позволяет помещать материал
непосредственно в графические
приложения, минуя операции экспорта/импорта.
При этом сохраняется
последовательность клипов, взаимное
расположение слоёв, эффекты и проч.
Важная деталь – во время просчёта в
графической программе, можно
продолжать работу в Liquid.
Системы Liquid также позволяют
комбинировать две технологии - SAN и NAS (Рис.3).
При этом в NAS объединяются все станции,
а в SAN - только станции чистового
монтажа Liquid Chrome. Основное отличие от
предыдущей структуры заключается в том,
что она даёт возможность совместной
работы и с черновым и с чистовым
материалом.
Для организации сетевого монтажного
комплекса у компании Pinnacle есть своё
собственное достаточно мощное решение,
называемое Palladium Store. Это комплекс, в
который помимо массива с сервером
включён также сервер базы данных,
называемый Project Server. Основное отличие
от описанных мной «самодельных»
решений состоит именно в нём, а также в
специализированном программном
обеспечении, устанавливаемом на
клиентских станциях. Помимо совместной
работы над проектами, данное решение
позволяет осуществлять
централизованный менеджмент системы.
Например, входящий в его состав
инструмент X-Find, может осуществлять «глобальный»
поиск материала во всех проектах и
станциях по множеству различных
признаков. Кроме того, Palladium может
стыковаться с большинством
вещательных продуктов от Pinnacle, таких
как видеосерверы, титровальные машины
и т.д. Palladium также осуществляет
мониторинг системы и распределяет
задачи по степени их важности. Например,
если определить видеозахват, как
приоритетную задачу, то при нехватке
потока на общем массиве (такое
теоретически вполне возможно) отказ в
трафике получит монтажная станция, а
станция, которая в данный момент
занимается вводом материала ничего «не
заметит». Единственный недостаток
этого решения – его достаточно высокая
стоимость.
В заключение надо сказать, что для
построения сетевых видеомонтажных
комплексов можно реализовать великое
множество схем, всё будет зависеть от
многих факторов, таких как задачи,
бюджет, необходимость использования
существующего оборудования и т.п.. В
каждом конкретном случае надо
подходить индивидуально.
И конечно надо иметь в виду, что в тех
схемах, которые были описаны выше, есть
масса дополнительных технических
деталей, о которых просто не имеет
смысла говорить в рамках данной статьи.
Однако даже при самом беглом взгляде на
эти схемы, становится очевидным, что
продукты семейства Liquid - это те самые
кирпичики, из которых умелый
архитектор может построить прекрасное
здание сетевого видеомонтажного
комплекса.
Автор Олег Бондарев
|
