В первом ознакомительном материале читатель узнал об основных изменениях и улучшениях, увидевших свет в новой версии видеоредактора Adobe Premiere Pro CS5. Теперь пора придвинуться поближе к мониторам и изучить программу и её новый движок изнутри. Разумеется, с помощью тестов. Но "гонять синтетику" мы не станем, а используем вполне реальные проекты.
Прежде всего приведём конфигурацию тестового стенда: четырёхъядерный Intel Core i5 750, работающий с частотой 2,67 ГГц; материнская плата MSI P55-CD53 с восемью гигабайтами памяти DDR3, и три отдельных жёстких диска. Также в тестировании примет участие профессиональная видеокарта NVIDIA Quadro FX 4800, которая позже, в финальном эксперименте, будет заменена "игровой" XFX GeForce GTX 285.
Проигрывание таймлинии
Данный тест проводится в целях оценки комфорта работы со сложными проектами в Adobe Premiere Pro CS5 (буквально слышится: — Ага, и как же это комфорт измерять собрались? Кардиограмму у несчастного монтажёра снимать удумали или соцопрос на улице проведёте?).
Первый проект, который участвует в тестировании, является официальным проектом Adobe, предназначенным и рекомендованным бета-тестерам пакета CS5. Он представляет собой компиляцию из четырёх видеофайлов, уложенных на таймлинии в шесть слоёв, каждый из которых обильно снабжён фильтрами, поддерживаемыми аппаратно (т.е. обрабатываемыми движком Adobe Mercury Playback). Общая длительность проекта — 2 минуты. Видео, использованное в этом проекте, получено в результате 3D-рендеринга. Это AVCIntra P2 Movie — файлы с расширением *.MXF со следующими характеристиками: 1440x1080, глубина цвета 30 бит/пикс, частота кадров 23,976, битрейт 44 Мбит/сек, соотношение сторон 1,3333. AVCIntra означает, что в таком файле каждый кадр является I-кадром, то есть ключевым.
Второй проект представляет собой точную копию первого, с одним лишь исключением: исходное видео было заменено другим, полученным путём перекодирования исходного MXF в MPEG2 1440x1080 с битрейтом 18 мбит/сек. Что же касается всех фильтров — не беспокойтесь, они на месте, и продолжительность проекта в точности та же самая.
Третий проект — снова всё то же самое, лишь на этот раз видео представляет собой AVCHD-файлы с разрешением 1440x1080 и битрейтом 18 Мбит/сек.
Для чего мы хотим использовать два последних проекта, являющихся, по сути, клонами первого? А для того, чтобы читатель, как потенциальный пользователь программы, мог судить о скорости работы в ней не только лишь по одному какому-то признаку, не только по её работе с одним видеоформатом (тем более с таким, мягко говоря, профессиональным форматом).
Любой, кто хоть однажды плотно работал с видео, понимает, что обработка разных форматов всегда приводит к разным же результатам. Высокий битрейт видео приводит к трудностям с жёсткими дисками. Низкий битрейт файла чаще всего означает высокую степень сжатия видео, что влечёт за собой трудности иного рода — вычислительные. А в этом случае впросак попадаёт процессор, декодирующий такое видео.
В "оригинальном" проекте используется видео AVC-Intra, имеющее довольно высокий битрейт (около 44 мбит/сек). Следовательно, во время проигрывания и/или просчёта такого проекта мы рискуем получить "тормоза" по причине непоспевания жёсткого диска — очень трудно, согласитесь, считывать с одного обыкновенного диска данные одновременно из четырёх разных файлов со скоростью 22 мегабайта в секунду (таков получается общий битрейт всех четырёх видеофайлов). Второй проект (с файлами MPEG-2) значительно уменьшит обращение к жёсткому диску, а также разгрузит и процессор, декодирующий видео — MPEG2 не отличается сильным сжатием. Последний же проект также не будет сильно тревожить диски, зато заставит прогреться электронные мозги, поскольку видео, сжатое в AVC — это довольно суровое испытание для вычислительных мощностей любого компьютера.
Теперь осталось настроить программу так, чтобы иметь возможность мониторить процесс проигрывания таймлинии, а именно — в реальном времени видеть FPS во время проигрывания, а также подсчитать количество пропущенных кадров. В командной консоли (Ctrl+F12) включим режим отладки базы данных (Debug Database View). Здесь в строке EnableDogEars необходимо активировать собачьи уши, напечатав слово true (dog ear — это идиома, обозначающая загнутый край книжной странички).
Теперь, после этой операции, в окне Program поверх видео мы можем наблюдать подробную информацию о текущем состоянии работающего движка:
К сожалению, от идеи захвата видео с экрана пришлось отказаться после нескольких неудачных попыток проделать это. Уж слишком непредсказуемые помехи вносит процесс захвата и записи, спонтанно нагружая центральный процессор и жёсткие диски, тем самым портя всю картину тестирования. Будем надеяться, что чистоту будущих экспериментов обеспечат следующие тщательно созданные условия:
- оба проекта и все файлы, составляющие их содержание, расположены на отдельном (не системном), дефрагментированном жёстком диске, имеющем скорость вращения шпинделей 7200 оборотов в минуту
- все служебные файлы Premiere Pro CS5 (Cashe, Scratch Disks) также вынесены на отдельный (не системный) жёсткий диск с такой же скоростью вращения шпинделей
- никакие системные процессы к данным дискам не обращаются
- текущее расположение звёзд гарантирует достоверный результат работы
Теперь остаётся лишь наблюдать. Нажатием кнопки Play в окне Monitor запускается воспроизведение таймлинии, при этом технические данные в реальном времени отрисовываются поверх проигрываемой картинки. Заголовки OpenCL Display и CUDA Display обозначают работу программного и аппаратного рендера соответственно.
По окончании воспроизведения мы запишем результат, который нас больше всего интересует: он содержится в строке Dropped. Эти цифры — те самые пропущенные при воспроизведении кадры, количество которых обратно пропорционально мощности аппаратной начинки компьютера, а, соответственно, и эффективности используемого движка.
Проигрывание каждого из трёх проектов проводилось трижды, после чего из трёх полученных показаний вычислялось среднее арифметическое число. Оно-то и вошло в итоговую диаграмму.
Возникает справедливый вопрос: отчего проект с файлами AVCIntra проигрывается с таким трудом? Может, в силу особенностей сжатия, или из-за "веса" файлов? Следует также отметить загрузку обоих процессоров: во время аппаратного просчёта центральный процессор напрягается едва ли наполовину, в то время как загрузка графического процессора достигает порой ста процентов. Во время же программного рендеринга картина иная — графический процессор полностью отдыхает, но центральный уверенно занят на сто процентов.
Просчёт и кодирование
Перейдём к кодированию. К счастью, в новой версии программы Adobe здорово помогла пользователю, неискушённому в хитростях с разрешением, частотой кадров, и прочими интерлейсами. Каждый формат видео, предназначенный для конечного использования (FLV, H.264 Blu-ray, MPEG2 Blu-ray и MPEG2-DVD), теперь имеет несколько чертовски полезную предустановку. Называется она Match Source Attribute, что означает максимально точное соответствие характеристикам оригинала. При выборе такой предустановки кодировщик автоматически подберёт все нужные значения для будущего файла, так, чтобы сохранить исходные частоту кадров, соотношение сторон и т.д.
Воспользуемся этими шаблонами, и проведём кодирование в следующие форматы:
 |  |
H.264 Blu-ray Match Source Attribute (High Quality) | MPEG2 Blu-ray Match Source Attribute (High Quality) |
 MPEG2-DVD Match Source Attribute (High Quality) |
Просчёт в каждый из форматов проводился дважды: с включённой аппаратной поддержкой и с отключённой. В итоге было получено шесть результатов, все они сведены в одну диаграмму.
Десятикратная разница в скорости просчёта столь сложного проекта не просто впечатляет, а заставляет воскликнуть: как они этого добились? Помимо эмоций, диаграмма также показывает серьёзное ускорение при просчёте в MPEG-2, которое, однако, пропадает во время аппаратного рендеринга.
Качество кодирования
Известно, что качество кодирования целиком и полностью зависит от используемого кодека и его настроек, а зачастую даже от способа реализации — программного или аппаратного. Мы уже встречались со случаями, когда аппаратное и программное кодирование давало разное качество результата. Чаще, увы, проигрывало именно аппаратное кодирование (произведённое силами графических процессоров). Прежде это удобно было объяснять "сыростью" технологий, трудностями внедрения аппаратной поддержки и прочими трудностями, совершенно неинтересными для страждущего пользователя.
Прошло время. Давайте взглянем, преодолены ли трудности, и не появились ли за это время какие-то новые проблемы.
Для оценки качества кодирования воспользуемся специальной заготовкой: полуторагигабайтным видеофайлом-исходником с анимированной поверхностью воды (такие сложные объекты, как известно, довольно требовательны к методам сжатия и битрейту). Данный файл полностью лишён каких-либо артефактов сжатия, поскольку создан искусственно. Это десятисекундный AVI-uncompressed (без сжатия), 1920x1080 25p, и с глубиной цвета 32 бита на пиксель.
Кодирование традиционно проведём в три наиболее востребованных сегодня формата: H.264 Blu-ray, MPEG2 Blu-ray, и MPEG2 DVD.
Для сравнения возьмём один наиболее проблемный участок с активным движением: здесь скорее всего можно ожидать проявления пикселизации (при некачественном кодировщике и/или недостатке битрейта кадр обычно бьётся на легкоразличимые квадраты).
Кодирование в H.264 | ||
Оригинал | Аппаратное кодирование | Программное кодирование |
 |  |  |
Кодирование в MPEG2 Blu-ray | ||
Оригинал | Аппаратное кодирование | Программное кодирование |
|  |  |
Что-то не видать ни квадратов, ни собственно разницы между аппаратным и программным кодированием. Похоже, движок, просчитывающий и кодирующий видео, и в самом деле умеет на лету переносить вычисления с центрального на графический процессор, не меняя при этом никакие параметры кодирования. Кстати, на справедливость такого предположения указывает и следующий рисунок:
Вернёмся к оценке качества кодирования, к последнему его этапу: кодированию в MPEG2 SD, совместимому с бытовым DVD-видео диском. Да, с кадром стандартного разрешения нам пришлось помудрить. Дело в том, что широкоэкранное видео в SD-разрешении достигается путём изменения соотношения сторон пикселя, и для того, чтобы в графике увидеть нормальный аспект, придётся изменить размеры рисунка с 720x576 на 1024x576.
Поскольку площадь рисунка многократно уменьшилась, то увеличилась и зона поиска артефактов (Сталкер тут ни при чём, имеются в виду огрехи кодирования).
Кодирование в MPEG2 DVD | ||
Оригинал | Аппаратное кодирование | Программное кодирование |
 |  |  |
В случае с кодированием в MPEG-2 на стоп-кадрах, полученных из готовых файлов, можно увидеть некоторую рябь, мусор на поверхности воды. Следует учесть также и тот факт, что стоп-кадр оригинального видео уменьшался в графическом редакторе, а не трансформировался путём перекодирования в интерлейсный MPEG2. В любом случае, явной разницы между аппаратным кодированием и программным по прежнему не наблюдается.
Видеокарты и производительность
Для комфортной работы в Adobe Premiere Pro CS5 (как, впрочем, и во всех остальных приложениях пакета CS5) рекомендуется использовать видеокарты серии Quadro, однако специалисты скажут: при разработке "игровых" видеокарт GeForce и видеокарт профессионального назначения семейства Quadro используются фактически одни и те же электронные компоненты. Разница состоит лишь в поддержке и оптимизации драйверов под то или иное приложение.
Скажут, и будут правы лишь частично. Дело в том, что видеокартам игрового назначения недоступны некоторые весьма ценные возможности, раскрывающиеся только в драйверах для профессиональной серии Quadro. Для того, чтобы увидеть это своими глазами, попробуем столкнуть лбами профессиональную видеокарту Quadro FX 480 и игровую XFX GeForce GTX 285. Загрузим уже знакомый нам проект и начнём поочередно включать отображение слоёв на таймлинии. Интересно, какая из видеокарт закапризничает первой?
Гадать не было никакого смысла. Конечно же, GeForce GTX 285 оказалась слабее — при включении уже пятого слоя электронные игровые мозги сдались победителю-профессионалу Quadro FX 4800. И пусть количество фильтров в Adobe Premiere Pro CS5, поддерживаемых аппаратно, одинаково для профессиональных карт и игровой GTX285 (см. рис. справа). Как видите, на этом количестве всё и заканчивается. Близок локоть, да не укусишь: если более четырёх слоёв видео снабдить определёнными фильтрами, то GeForce GTX 285 перестаёт обрабатывать таймлинию аппаратно, в то время как старшие, профессиональные модели, продолжат аппаратный рендеринг.
Но что, если мы всё же попытаемся сравнить работу на этих видеокартах с таким проектом, который умеет "потянуть" GTX 285?
В качестве инструмента, измеряющего загрузку центрального и графического процессоров, мы используем утилиту NVIDIA System Monitor из пакета NVIDIA System Tools. Воспроизводимый проект представляет собой уже знакомую нам композицию, однако, вследствие невозможности работать на игровой видеокарте более чем с четырьмя слоями, мы отключили верхние два (поскольку запись с экрана отъедает часть ресурсов, обе видеокарты вели себя не очень хорошо при воспроизведении таймлинии).
Видимая разница в скорости работы сравниваемых видеокарт практически отсутствует, и это — очевидная радость для владельцев игровой GTX 285, кому достаточно и четырёх видеодорожек, обрабатываемых аппаратно. Для работы в Adobe CS5 корпорацией Adobe сертифицированы следующие видеокарты: GeForce GTX 285 (Windows и Mac OS), Quadro FX 3800 (Windows), Quadro FX 4800 (Windows и Mac OS), Quadro FX 5800 (Windows), Quadro CX. При этом оговаривается, что игровая видеокарта GTX 285 поддерживается с ограничениями, и оговаривается вполне справедливо, в чём мы имели возможность убедиться самостоятельно.
за предоставленное оборудование
за предоставленную видеокарту
за предоставленную видеокарту
