Просмотр полной версии : Fraps>H.264 Очень слабо грузит проц.
Месяц ломаю голову на другом форуме, к ответу так и не пришел:
Имеются таковые настройки проекта:
http://img806.imageshack.us/img806/6549/65140760.jpg
Видео рендерется вот по таким настройкам:
http://img844.imageshack.us/img844/5205/60521722.jpg
В процессе рендеринга проц (Athlon II x3 425) грузится на 30-40%. Память на 92% (2 гига :*). С файлом подкачки тоже все нормально вроде. Ни один из показателей не превышает 99% Стоят два саташных харда. Вегас, директория с несжатым видиом и файл подкачки - все на одном носителе, винда на третьем - айдишном. Вот кароче:
http://img718.imageshack.us/img718/849/91361389.jpg
А теперь вопрос: В какой части железа происходит затык? Попускная способность харда? Да нет, вроде, все нормально. Почему я не могу рендерить быстрее, мой проц используется на 30% потенциала.
Пока мне известно что тестовый ролик из FRAPS (uncompressed) в h.264 жмется следующим образом:
в восьмом верасе: 7мин25с.
Загрузка проца: 30-40%, второе ядро грузится больше всех, первое - процентов на 5.
в девятом вегасе: 1мин39с.
Загрузка проца: 60-70% одинаково на все три ядра.
в десятом недовегасе: 1мин20с.
Загрузка проца: 50-60% равномерно.
Файл чистый, без эффектов, но если применить блюр, то загрузка проца в девятом получается 100%
директория с несжатым видиом и файл подкачки - все на одном носителе
Чем не затык? На айдишный переносить что-то - не выход, но и так, как есть, тоже коряво. Имхо ещё винт нужен. Сата.
В свойствах твоего проекта поля не нужны.
Чем не затык? На айдишный переносить что-то - не выход, но и так, как есть, тоже коряво. Имхо ещё винт нужен. Сата.
То есть должно быть 3 саташных винта: на одном вегас, на втором несжатое видео, на третий складываем готовую продукцию :0? Ну если не говорить про рейды всякие.
На айдишный переносить что-то - не выход
То есть винда мне всю картину портит? Которая стоит на айдишном. Ах да, сейчас на айдишном стоит еще и Вегас, но его темповый файл находится на ВД блэк.
Сейчас подразогал проц на 30% - производительность возросла на те же 30%. На другом форуме еще предположили, что ядра не все грузятся.
Скажите, а у Вас при рендеринге в h.264 проц полностью грузит, и какая машинка?
Hahaha, машинка у меня в профиле пользователя обозначена. Слабая машинка, но используется на 100 % . Все винты саташные, Вегас и другой софт стоят на системном вместе со своими темпами. Три других винта - для видео и всего остального, что может понадобиться. С какого на какой просчитывать я решаю только из соображений по поддержанию порядка на компе. Мне важно знать, что, например, такая-то школа у меня вся в такой-то папке, где в свою очередь материал делится на видео, аудио, фото, графику, футажи, скрины (иногда). Особых проблем со скоростью не испытываю. Загрузка проца на видео всегда 100%, только звук выше 70 не поднимается. h.264 - тяжёлый кодек, должен грузить по полной.
должно быть 3 саташных винта: на одном вегас, на втором несжатое видео, на третий складываем готовую продукцию
Когда один из рабочих форматов uncompressed, то да. Возьми у кого-нибудь винт на пробу, сам увидишь.
Почему разгон повлиял не знаю. Здесь на форуме обсуждалась проблема с дефектами просчитаного видео, которое было получено после разгона, так что не увлекайся.
yankee, Спасибо, будем думать. Сейчас попробовал обычный mpeg-4 пережать - та же фигня, проц грузится слабо :(
Hahaha
Включите счетчики производительности, сами увидите загружены ли винчестеры на полную. Скорее всего загружен винчестер сорцов.
Похожий эффект (недогруз по ядрам) наблюдается у некоторых пользователей x264.exe. По большей части это вызвано отсутствием распараллеливания у декодера и/или фильтров обработки. Скажем, в Вегасе фильтры NewBlue грешили этим делом. Но если Blur делает загрузку в 100%, то вряд ли это тот самый случай.
Скажите, а у Вас при рендеринге в h.264 проц полностью грузит, и какая машинка?От случая к случаю.
К слову, зачем используется 32-битная цветность?
Почему в проекте используется черезстрочная развертка? Почему при этом метод деинтерлейса не выбран?
Еще к слову, не советую использовать сжатие с average bitrate в один проход - качество распределения битрейта в таком варианте несколько не очень.
Ну и до кучи - сжимать h264 в avi - кощунство и ересь.
Спасибо, я все понял - это специфика вегасов/кодеков, на других машинах такие же проблемы.
К слову, зачем используется 32-битная цветность?
Почему в проекте используется черезстрочная развертка?
Я не знаю :) Тупо скопипастил настройки с какого-то форума. Вроде на производительность не влияет?
А если я цвет на 8 бит поставлю это ускорит:
а) скорость превью
б) скорость рендеринга
в) оба варианта
UPD: Блин, поигрался с настройками - вообще фигня странная происходит.
В некоторых случаях 8bit DRAFT работает в три раза медленней чем 8bit BEST.
Со слоями тоже непонятка, в каких моментах 8bit мне может изменить картинку? Если слои в оверлее, то 32bit Full range (тот что новый) дает изменение, в других ситуациях вроде все окейно, пока.
Вроде на производительность не влияет?
В первую очередь может влиять на результат. Стоит только начать зумировать или изменять скорость, как всё будет - и влияние на скорость, и влияние на картинку.
цвет на 8 битускоряет все
Какие слои? В каком оверлее?
warper В проекте слой полупрозрачный, в режиме наложения overlay его внешний вид значительно менялся, причем не только с перехода от 32bit(full range) к 32bit (video levels), но и от 32bit (video levels) к 8bit. Но на это дело пришлось временно забить, т.к не могу сделать так, что бы при этом режиме наложения альфа канал оставался прозрачным.