Видеомонтаж
Содержание материала
| Мощная рабочая станция для видеомонтажа, Часть 1 Нафиг оно нужно Мы все, в каком-то роде, маньяки. Кто-то зациклен на железках, кто-то на гаджетах, другой уперся рогом в какую-то программу и что-то в ней ваяет. Отличие нас от остальных, мы не останавливаемся на достигнутом и стараемся всегда добиться профессионального результата в том, чем начали интересоваться неделю назад. Когда я вперся в видеомонтаж, это было чем-то типа шутки, перегнать снятое на видеокамеру на диск в формате SVCD и потом смотреть с друзьями. Закончилось перебором множества видеоредакторов от мувимейкера из комплекта винды до ковыряния в Avid Express DV 3.5. Однако остановился на на такой классной программе, как Vegas Video. Начиная с 3-й версии, я удовольствием пользуюсь ей и осознаю, что для моих амбиций в области видеомонтажа, она подходит, как нельзя лучше. Первый фильм занимал всего 20 минут и влезал на один SVCD диск. Еще тогда я заметил, что на моем, Dual Pentium 3-933, как то долго все проиходит. Это притом, что игрушки все летали, система тоже шевелилась довольно шустро. Отчасти, быстроты добавляло наличие в системе второго процессора и даже когда одно из приложений занимало все ресурсы, оно обычно ограничивалось одним процессором, а второй был в распоряжении системы и меня. Это еще раз убедило меня в правильности выбора в сторону SMP систем. Но несмотря ни на что, прогресс идет, я заметил что для просчета часового фильма мне приходится ждать аж по 20 часов , и не факт, что я потом не найду какую нибудь ошибку и не придется все заново пересчитывать. В общем так постепенно свыкался с мыслью об предстоящем апгрейде. Казалось бы , чего там думать, берешь самый шустрый проц, мать под него и память. И дело обвешиваешь это все остальными железками, часть из которых можно взять из старого компьютера. В моем случае, выбор сужало то, что я изначально хотел двухпроцессорную систему, в их на данный момент было всего два варианта - ксеоны и оптероны. После нахождения лакомой мамочки ASUS PC DL Deluxe, которая при цене в 220$ впитала все самое лучшее из однопроцессорных вариантов и имела на борту 2 слота под 604 сокет, я больше не сомневался, что именно мне было покупать. Года три назад, когда я распробовал RAID контроллеры, перепаяв 30$ Promise Ultra 66 Fastrack 66, кторый стоил тогда около 150$, стало понятно каким образом можно увеличить производительность дисковой подсистемы, поэтому следующая моя материнка уже имела на бортру встроенный Promise FT 100. ASUS PC DL тоже была с таким же RAID контролером, только более новым вариантом, который поддерживал SATA устройства. Так я проапгрейдил свою систему и продолжил монтировать видео уже в пятой версии вегаса. Но вот осталось одно но. Того увеличения скорости рендеринга, на которе я рассчитывал, тратя огромные деньги на апгрейд, я не получил. Да, стало быстрее, но не так как я ожидал. Комп стал мощнее, игры стали летать, все остальное тоже, но для видеомонтажа этого оказалось недостаточно и я начал разбираться, каким именно должен быть компьютер для того, чтобы в нем можно было бустро монтировать видео и максимально уменьшить время получения результата. Определяем аппаратную конфигурацию рабочей станции Прежде чем определяться с комплектующими необходимо выделить круг задач , которые будет решать компьютер и определить их специфические требования к оборудованию. Если двигаться по порядку, то начнем с описания самого процесса работы. Сначала видео снимается на камеру, потом по интерфейсу IEEE1394 переносится на жесткий диск компьютера в формате DV, как AVI файл. Значит, нам необходим порт IEEE1394. Он может быть как внутренний, встроенный в материнскую плату, так и внешний, в виде отдельного контроллера. Наиболее удачным вариантом было бы купить звуковую карту у которой он присутствует, например Audigy 2. В этом случае можно оставить в запасе еще один PCI слот, который может пригодиться например для карты нелинейного монтажа или видео захвата, с случае если придется оцифровывать аналоговый материал, что бывает достаточно часто. Каждый час видео занимает на жестком диске около 13 гигабайт, т.е. нам просто необходим большой жесткий диск. В случае если мы приехали с отдыха, может так случиться, что там будет не одна , а 2 или 3 видеокассеты. Тогда около 40 гигабайт уйдет только на хранение информации. Для того, чтобы хранить результаты промежуточных преобразований , понадобится примерно столько же места на диске. Благо, сейчас в продаже есть жесткие диски по 200, 300, 400 Гб, которые постепенно становятся доступными по цене. В качестве интерфейса лучше выбрать SATA , потому что он является более скоростным и соединительные кабели тоньше, а следовательно меньше мешают потоку воздуха в корпусе компьютера. О количестве жестких дисков поговорим дальше. После того как видео скопируется на компьютер, оно обрабатывается при помощи различных программ по улучшению изображения или сразу попадает в программу видеомонтажа, в которой происходит процесс нарезки, склейки, наложения эффектов и всевозможных фильтров. В конце концов мы получаем на выходе DV , MJPEG или Mpeg2 файл, который просчитывается достаточно продолжительное время, напрямую зависящее от производительности процессора и дисковой подсистемы. Т.е. программа читает с жесткого диска видео файл декодирует его на лету, обрабатывает и записывает в выбранном нами формате обратно на жесткий диск. Т.е. происходит 4 операции. Чтение файла с диска, обработка информации центральным процессором , кодирование в выходной формат и запись обратно на жесткий диск. Все это в комплексе называется рендерингом, а время выполнения - временем рендеринга. Дисковая подсистема Как же нам сократить время рендеринга? Для этого нужно сократить время выполнения всех его составляющих и снизить их взаимное влияние друг на друга. К примеру, если исходный файл и выходной файл у нас находятся на одном жестком диске, то тогда головкам этого диска приходится одновременно работать на 2 фронта, считывать файл и записывать файл. Кроме этого, пропускная способность интерфейса тоже делится на 2, часть времени используется для чтения, часть для записи. В результате мы получим существенное замедление скорости выполнения обеих операций, чего можно было бы избежать, будь у нас исходный файл и выходной файл на разных жестких дисках. Желательно, чтобы они даже не находилось на одном шлейфе, чтобы избежать потери в скорости, если жесткие диски могут выдавать в сумме скорость большую, чем позволяет интерфейс. Разнеся файлы по разным дискам мы максимально снизим взаимное влияние операций чтения - записи и упремся в ограничение скорости чтения диска с исходным видеофайлом. В виду того, что после компрессии например в Mpeg2 размер файла уменьшится в разы, скорость записи на второй диск не так критична, главное чтобы запись не мешала чтению. Дальнейшее увеличение скорости считывания возможно при использовании RAID массивов типа RAID 0 (STRIPE), которые позволяют более чем в полтора раза увеличить скорость выполнения операций чтения записи. В случае если один диск дает 60-65 мегабайт в секунду, то пара даст больше сотни. Такая скорость даст прирост в случае если процессор в состоянии обработать весь поток поступающей с диска информации. Далее, если двигаться в сторону полной оптимизации, я хотел бы предложить следующую конфигурацию дисковой подсистемы рабочей станции. Нам нужно несколько областей для хранения различных данных. Операционная система. Она устанавливается в количестве 2-3 штуки на загрузочный дисковый массив типа зеркало, в самое начало. Остальное пространство разбивается таким образом, чтобы был один раздел для хранения важной информации (софт, документы, библиотеки видео , звука и изображений и др. ) и еще один, для хранения результатов работу по видео - файлы проектов, результаты работы. У меня для этой цели используется пара IDE Maxtor 200Gb на контролере Promise. Далее, нужна пара быстрых дисков, один для хранения исходников, второй для хранения результатов рендеринга и промежуточных файлов. Фактически, у меня для этого еще одна пара дисков 200Гб, разбитых на 2 логических. Смысл такой, что исходники пишутся либо на первый раздел диска А , либо на первый раздел диска В, а в процессе рендеринга результат будет писаться на второй раздел другого диска.
Как еще можно увеличить скорость? Для этого нужно первый диск заменить на дисковый массив. Скорость увеличивается почти в два раза, в надежности теряем уже точно в 2 раза. В случае если что-то случится с одним из дисков в массиве STRIPE, потеряем информацию размера вдвое большего емкости одного диска. Поэтому можно предложить такой вариант. Создать массив их двух небольших 80Гб дисков одной из последних моделей типа Maxtor Diamond Max 9 или 10. Они имеют ту же скорость что их более емкие и более дорогие собратья, а емкость меньшую, как и цену. На этот массив можно положить pagefile.sys , директории Temp и Tmp, а также темп файлы других редакторов типа звукового или графического. Туда же копировать исходники текущего проекта и потом менять на другие по его окончании… Процессор Итак, с дисковой подсистемой, более менее, определились, переходим к процессору. Тут все очень просто. Чем быстрее процессор, а точнее связка - процессор - чипсет - память, тем быстрее будет происходить просчет видео. Скорость просчета видео зависит от многих параметров, таких как тип процессора его структура, частота, частота шина, размер кеша, частота на которой кеш работает, его латентность; частота, тип, размер и конфигурация (двухканальная) оперативной памяти; от настроек БИОСа материнской платы и ее чипсета. Короче, одни железки сильно влияют, другие дают прирост 1-5% при скрупулезной настройке , но основные показатели дают процессор и память. Память чем быстрее, тем лучше, чем больше тем лучше. Т.е. установить какую-нибудь брендовую DDR400 или 533, если мама ее поддерживает в размере до 1-2 Гб , но не более 3.5 потому что больше 32 разрядная система не увидит. Реально хватает 1 Гб почти на все случаи жизни, но если будет 2 , то это только лучше. Разве что нужно стараться покупать память одного типа и производителя и даже партии, по крайней мере на один канал ставить одинаковые модули. Это поможет избежать лишней нестабильности при работе системы. На многих сайтах типа хобота (www.ixbt.com), регулярно публикуют сравнительные тестирования топовых процессоров в различных задачах, в том числе и в кодировании видео. Нам нужно выбрать такой, чтобы был самый быстрый для нашей задачи. По моему мнению, процессоры Интел пентиум 4 - идеальны для этой роли. В данный момент самый быстрый из них работает на частоте 3.6 ГГц и стоит очень дорого. Существуют модификации с 1мб кешем L2 или так называемый extreme edition, которые стоят дороже, но и дают иногда прирост небольшой. Покупая процессор мы заранее выбирает такой, чтобы его можно было в случае чего немного разогнать, когда это будет необходимо. Поэтому не стоит гнаться за самым быстрым в линейке, наоборот, можно купить какой-нибудь 3ГГц , а потом разогнать его до тез же 3.6 путем подъема частоты шины. Если хочется еще большей производительности и есть на этой деньги, то можно посмотреть в сторону двухпроцессорных систем. Они в целом, значительно дороже, но всегда попадаются недорогие варианты, если как следует поискать. Я уже давно являюсь ярым приверженцем двухпроцессорных конфигураций и в то время как иные люди переживают по 2-3 апгрейда, я делаю всего один, тем самым компенсирую себе разницу в цене между одно и многопроцессорной системой. В качестве вариантов на сегодняшний день можно посоветовать купить либо двухпроцессорную конфигурацию на Intel Xeon DP Socket 604 на базе недорогой материнской платы ASUS PC DL Deluxe или аналогов на чипсете Intel 875P или что-то на оптеронах. Но это возможно будет значительно дороже за счет стоимости материнской платы за 500$ или памяти с контролем четности, да и сами процессоры недешевы (мало интересовался этим вопросом). Но даже если у вас будет двухпроцессорная система, это вовсе не гарантирует 100% прироста при работе, как хотелось бы. Гарантировать можно 5-7% прирост, но не более и только за счет того, что приложение будет занимать один процессор, а система будет мучить второй. Дальше все зависит от оптимизации приложения, в нашем случае, видеоредактора, под многопроцессорные системы и распараллеливание операций, так назывой многопотоковости. Даже если сам редактор заявлен производителем, как поддерживающий два и более процессора, остаются еще такие его компоненты, как фильтры, переходы, декодеры видео форматов, кодеры, которые в сумме дают совершенно неясную картину работы на нескольких процессорах, в то время как на одном это видится как обычная 100% загрузка. В случае с несколькими процессорами, сказать что программа оптимизирована под многопотоковость можно только когда загрузка процессоров будет более 55% для двух процессоров и более 27-30% для двухпроцессорной системы с включенным Hyper threading (HT). Т.е. фактически приходится брать как - бы кота в мешке. Платить на 300-400$ дороже за двухпроцессорный вариант на дорогих серверных камнях, но не быть уверенным что получишь прирост в приложениях, с которыми работаешь. Если остальная оптимизации системы, расположение жестких дисков, увеличение памяти, разгон процессора по частоте, 100% дает прирост производительности, а следовательно уменьшение скорости рендеринга, то в случае с покупкой второго процессора - вопрос спорный. Слишком уж много факторов участвует в процессе, отсюда и результат, о котором можно только попытаться догадаться, но не знать наверняка. Попав в такую ситуацию, когда мне нужно знать, на что способная моя система и что можно сделать для того, чтобы увеличить ее быстродействие при рендеринга , я решил провести небольшое тестирование своего компьютера при работе с приложениями для полного технологического процесса от захвата видео с камеры, обработки и видеомонтажа до авторинга и записи ДВД . Когда я попытался объять своим умищем предстоящие телодвижения, то пришел в ужас. Придется проделать огромное количество работы, без какого - либо опыта в таких делах и риск нарваться на комментарии профессионалов, типа, тесты подобранны неправильно, тестирование необъективное, настройки не те и тому подобное. Тогда я решил сделать по-другому. Не тестировать все, а выделить перечень наиболее часто используемых операций и тестировать только их работу. Этого должно хватить для того, чтобы получить представление о главном - оправдываются ли вложения в двухпроцессорную систему или можно добиться того же на одном процессоре или при его разгоне. |
[--pagebreak--]
[--pagebreak--]
Тестирование
Для тестирования используется кусок DVD диска . Т.е. создал проект, продолжительностью меньше минуты, в которую поместил наиболее употребляемые переходы и эффекты.
Исходником является Mpeg2 файл. В таком виде решил произвести следующие тесты.
Зависимость времени рендеринга в разные форматы от частоты процессора
На данном этапе я кодирую поочередно в DV, Mpeg2 и WMV форматы, причем DV идет как Interlace, так и прогрессив. Каждый тест проводится для вариантов процессоров 2400(133х18) МГц, 2666(133х20) МГц, 2800 Мгц, 3066(133х23)МГц и 3630МГц (165х22). Последний вариант - это режим разгона по шине, который выдерживает мой компьютер без ущерба для стабильности.
В настройках системы стоит однопроцессорное ядро, т.е. тестируется вариант, если бы у нас был только один процессор. В качестве настроек, выбирались стандартные профили для кодирования.
Профиль Частота процессора
3.63 ГГц
3.06 ГГц
2.8 ГГц
2.66 ГГц
2.40 ГГц
Рендеринг в PAL DV Interlace
5:32
6:37
7:02
7:25
8:07
Рендеринг в PAL DV Progressive
3:05
3:37
3:54
4:11
4:34
Рендеринг в DVD PAL Progressive
3:21
4:01
4:16
4:31
4:57
Рендеринг в WMV
4:59
5:56
6:30
6:54
7:23
На графиках видно как уменьшается время рендеринга в зависимости от увеличения частоты процессора. В текущей конфигурации даже если процессор будет около 4ГГц, время рендеринга Mpeg2 в случшем случае выйдет за отметку не более 3 минут, при условии отсутствия тормозов в видео жесткого диска или других. Дальнейшее увеличение частоты процессора не даст революционных изменений, разве что частота увеличится в 2-3 раза. Или произведите в уме расчет, если вычесть, к примеру из цены Intel Xeon 3.6 ГГц, цену Intel Xeon 3.6 ГГц.(сделайте это сами в качестве домашнего задания). Для владельцев обычных Intel Pentium 4, будут похожие результаты по зависимости.
Зависимость времени рендеринга в разные форматы от частоты шины
Увеличивает частоту шины с 133 до 166МГц, одноврменно уменьшая множитель, чтобы получить 3ГГц. Сравниваем время рендеринга 3ГГц процессора с шиной 133 и с шиной 165 МГц, меняя множитель.
Профиль Частота процессора (шины)
3.06(133) ГГц
2.97(165) ГГц
Рендеринг в PAL DV Interlace
6:33
6:37
Рендеринг в PAL DV Progressive
3:42
3:37
Рендеринг в DVD PAL Progressive
4:00
4:01
Рендеринг в WMV
5:57
5:56
В таблице видно, что разница во времени рендеринга находится в пределах погрешности, а значит в данном случае такого вида разгон нам не поможет, поднимать нужно частоту процессора.
Зависимость времени рендеринга в разные форматы от количества процессоров, исходник Mpeg2
Самый интересный тест, который является одним из важных для понимания, даст ли мне прирост второй процессор при выполнении моих задач или не даст.
Профиль Кол-во процессоров
One CPU w/o HT
Dual CPU w/o HT
Dual CPU with HT
Рендеринг в PAL DV Interlace
6:37
6:19
6:28
Рендеринг в PAL DV Progressive
3:37
3:30
3:33
Рендеринг в DVD PAL Progressive
4:01
3:36
3:39
Рендеринг в WMV
5:56
4:41
4:55
Прирост есть , но он не большой. Видно что в этом случае операция совсем не оптимизирована для многопотокового выполния, при включении HT происходит даже некоторое падение производительности. В целом, разница есть только в случае с рендерингом в WMV.
Увеличение производительности от использования нескольких процессоров небольшой, ровно такой, как должен быть у неоптимизированной программы для SMP, о чем свидетелствуют графики загрузки процессоров. Вот такой эффект дают пресловутые 5-8% дополнительной мощности от двух процессоров по сравнению с одним.
Зависимость времени рендеринга в разные форматы от количества процессоров, исходник DV
Предыдущий тест дал понять, что добавив второй камень не всегда можно сократить время рендеринга процессора не то чтобы в 2 раза, а хотя бы на 20-30%. Но рано было падать духом, захотелось продолжить эксперименты и я решил заменить исходник на PAL DV.
В конце концов, приходится работать не только с Mpeg2 исходниками, да и мало кто с ними вообще работает, зато с DV работают все, кто монтируют собственное любительское видео и я тоже вхожу в число этих людей.
Поэтому я взял обычный материал в DV камеры и сделал простенький проект. Один кусок видео, порезан на 3 части, соединенные двумя плавными переходами.
Выполняем рендеринг в PAL DV, т.е. просчитываем переходы, выполняем рендеринг в Mpeg2, т.е. просчитываем проект сразу в Mpeg2 и еще кодируем , предварительно просчитанный DV в первом тесте в Mpeg2, но в последнем случае происходит только кодирование DV в Mpeg2, без применения эффектов, т.е. тестим сам кодер от Mainconcept при работе с DV материалом.
Кол-во процессоров Профиль
Рендеринг в PAL DV Interlace
Кодирование PAL DV в Mpeg2
Рендеринг PAL DV в Mpeg2
Dual CPU with HT
0:35
0:48
1:48
Dual CPU w/o HT
0:39
0:56
1:59
One CPU w/o HT
0:42
1:31
3:08
Результаты получились весьма интересные, учитывая тот факт, что загрузка процессоров достигала 90% при всех трех тестах.
Первый тест имеет небольшой прирост и зависит в основном не от работы процессоров, а от скорости жестких дисков исходного материала и куда пишется результат. Но загрузка обоих процессоров и прирост скорости присутствует.
Второй и третий тесты с кодированием, сильнее грузят процессоры и тут виден реальный прирост от работы 2х и 4х процессоров. Т.е. технология HT реально работает при кодировании в Mpeg2, в случае если у нас в качестве исходного материала используется DV.
На графике загрузки процессора, который относится к рендерингу в Mpeg2 видно небольшой провал в начале графика первого процессора. (В этом тесте HT был отключен, т.е. у нас работают рельно 2 процессора.) Этот провал произошел в момент, когда просчитывался очередной переход между фрагментами файла.
Попробуем определить причину такого провала. Без анализа графиков загрузки это сложно, а графики я пока не строил, но сделаю такое допущение, что в момент перехода, который представляет собой процедуру, когда программа считывает поочередно 2 куска одного и того же файла в разных местах, происходит падение производительности жесткого диска и один из процессоров, (а иногда и 2) оказывается недогруженным. Отсюда провал на груфике и реальное падение скорости рендеринга.
Влияние размещения файлов на жестком диске на время кодирования
Совершенно обычное явление, когда вы производите захват видео с DV кассеты на жесткий диск в виде одного куска или нарезанием на сцены, не важно, потом все это переносится в проект в Вегасе и начинается процесс удаления всего лишнего. В результате остается набор сцен, связанных между собой переходами, а физически они как были, так и есть - куски одного файла лежащие на одном жестком диске.
Начинается рендеринг, доходит дело до места, где нужно аккуратно наложить один край сцены на другой и тогда начинается веселье для вегаса. Он одновременно читает один файл на одном жестком диске в разных местах. Это сразу отражается на производительности и времени рендеринга проекта.
Для проверки, можно провести такой опыт. Берем DV файл открываем в вегасе и создаем проект такого типа (А).
Рендерим этот проект в DV и в моем случае получим время 1:14.
Берем две копии первого DV файла, размещаем их на двух разных жестких дисках, создаем проект такого типа(В).
Рендерим проект типа В и получаем время всего 0:43. Т.е. потери на переходы составили 31 секунду, что почти сопоставимо с временем рендеринга варианта В.
Мне стало интересно, с какой скоростью просчитался бы проект будь он вообще без переходов. Убрал все переходы, получилось 0:18, т.е. тут у нас прямая зависимость от скорости жесткого диска.
Я пока не готов делать комплексные выводы по этому тесту, но в целом, тенденция видна хорошо. Жесткий диск, а точнее его скорость и время поиска, являются такими же важными составляющими формулы времени суммарного рендеринга видеофайлов, как и процессор. От неспособности диска дать вовремя кусок файла для просчета, процессор, каким бы он не был мощным, будет простаивать и файл будет просчитываться дольше, чем если бы у нас был более быстрый жесткий диск.
Выводы
Основной темой тестирования было выяснение вопроса, оправдана ли трата денег на второй процессор для задач видеомонтажа, в частности в Vegas Video 5. Однозначно ответить на этот вопрос не представляется возможным потому что, в одних операциях прирост не более 5-9%, в других чуть меньше чем в два раза. Кроме этого, время рендеринга, которое я пытался сократить, зависит от многих параметров, кроме процессора и комбинации этих параметров дают разные результаты.
В любом случае, второй процессор позволяет запустить одновременно вторую задачу, например кодирование звука в AC3 и тем самым сократить общее время рендеринга проекта в целом. При этом , на машине можно комфортно работать , открыв второе или третье окно Вегаса, в то время, как в фоновом режиме будет происходить просчет другого проекта.
Получается, что второй процессор прибавляет мощности, которая не всегда может быть реализована в скорости на одном приложении, но всегда может быть использована другими задачами.
Поэтому следующие тесты будут посвящены теме оптимизации проектов под использование в двухпроцессорной конфигурации и оптимизация железа под использование в задачах видеомонтажа и кодирования.
Опимизация дисковой подсистемы
В плане продолжения оптимизации тачки решил не останавливаться на достигнутом и прикинуть, что мне даст дисковый массив 0 уровня, т.е. STRIPE. А то все говорят, что вот сделай этот массив и будет тебе счастье.
В пятницу вечером ехал домой с сумочкой, в который лежала пара SATA Hitachi 80Гб (они были в тесте на Fcenter). Там низкое время доступа и высокие скорости, хотя большинство винтов сейчас имеют высокие скорости линейного чтения (60-65 mb/c).
Выбор пал на небольшие диски по нескольким причинам. Потому что я не доверяю, в смысле надежности, массиву с чередованием и потому что диски дорогие покупать, тоже не хотелось. Зная себя, купи я 2х200Гб и установи в STRIPE , то обязательно бы забил свободное место, сначала чем-то ненужным, а потом чем-то нужным. Поэтому 2х80Гб - это самое то, что нужно.
Первым дело я протестировал при помощи программы Drive и выделил, в процентном соотношении, область с максимальной скоростью. Получилось более 40% диска. Далее я разбил диск на разделы, последние 60% емкости пошли на хранилище объемной, но маловажной информации, место для скидывания образов DVD дисков, для последующей записи и тому подобного.
К первым 40% - это около 60Гб я отнесся более трепетно. Первые 10Гб отвел под TEMP диск, куда положил Page File основной операционки, и перенес каталоги Temp и Tmp. Остальные 50Гб отделил под хранение видеофайлов текущих проектов, чтобы обращение к ним происходило быстрее.
В отличие от максторов, IBM (а хитачи - этот тот же IBM) всегда имели меньшие параметры потребляемой мощности. поэтому я надеялся, что БП выдержит. Пришлось отрубить SCSI 20Гб винт, т.к. не было свободного места в корпусе для новых винтов. Получилось 2хHitachi 80Гб + 2хMaxtor 200Гб+ еще 2 макстора по 200Гб отдельно. Итого 6 винтов и 3 CD-ROM. Питалово не просело, но все равно я хочу в перспективе купить новый блок питания, ватт эдак на 500-700.
Тестирование
Для оценки производительности я решил прогнать старый тест по кодированию DV в mpeg2 и в DV сцены с несколькими переходами, когда соединяются часто одного и того же файла друг с другом и когда для работы используются два разных файла и переходы происходят всегда между разными файлами, лежащими на разных дисках.
В качестве места размещения видеофайлов проекта выбирал по очереди отдельный диск Maxtor и логический диск массива STRIPE. Разница во времени рендеринга оказалась в пределах погрешности, тут трудятся только процессоры, причем все 4 работают только когда заканчивается обсчет перехода. Средняя загрузка в обычно режиме около 72%, смена винтов не влияет на время рендеринга. Т.е. кодирование DV операция, где достаточно обычной линейной скорости одного современного винта 60 мб/c.
Но сильнее всего удручает другое. Просчет переходов при кодировании в DV и Mpeg2 происходит с загрузкой на 100% только одного из 4х процессоров. Т.е. средняя загрузка бывает в диапазоне 25-30%, а это говорит о плохой оптимизации программы Vegas 5 для работы с мультипроцессорными системами и опцией HT на процессорах Intel.
Выводы
Создание дискового массива 0 уровня дало большой прирост в работе с фотошопом, когда я поместил файл подкачки на диск Temp, так же шустрее стал работать Adobe Audition 1.5, но в случае с Вегасом 5, прирост при рендеринге составил менее 3%. Т.е. прироста никакого, тут все уперлось во что-то другое.
