[не удалять] XviD4PSP - универсальный медиаконвертер [архив №4]

Только до 35 % нагрузился камень.. Что-нибудь еще можно сделать?

Если в начале скрипта setMTmode(*,*) и setMemoryMax выставлены правильно, то скорей всего в скрипте используются фильтры, которым не требуется больше 2-х потоков, или же однопоточные фильтры (бывают и такие). А еще не забываем прописывать setMTmode(2) или (3) непосредственно перед самим фильтром. При установке убираем галочку на месте С++.
Я вот логики действий, у кого "чёй-то не устанавливается", не могу понять: ну нахрена ставить Вижуал Си если он уже есть в системе?! Тем более что дана ведь возможность выбора при установке. Или действуют по принципу "больше поставлю - больше получу"?
P.S.: Люди добрые, киньте пожалуйста в меня ссылочкой на короткий видеосюжет, в котором содержится полупрозрачный логотип (типа semi-transparent). Для экспериментов надо, "во благо всего человечества"

Использую BD TemporalDegrain.. Нагружаются все потоки,но на треть..

Spartan999
Попробуйте поменять RemoveGrainSSE2.dll и RepairSSE2.dll на RemoveGrainSSE3.dll и RepairSSE3.dll, и еще заодно можно попробовать mt_masktools-25.dll поменять на mt_masktools-26.dll.
Mt_masktools-26.dll, RemoveGrainSSE3.dll и RepairSSE3.dll лучше взять из Modded Plugins Package от -Vit- (http://forum.doom9.org/showthread.php?t=156028 ; ссылки для скачивания: http://www.mediafire.com/?mfs7bp2rprbhp22 , http://www.spirton.com/uploads/QTGMC/QTGMC%2032-bit%20Plugins%20%5BVit-Mod%5D.zip). Если не поможет, то надо бы смотреть скрипт полностью (тот который выполняется, а не который в пресете).
PS: и еще. Если стоит обычная версия Avisynth, то непонятно на что надеяться. Должна быть Avisynth МТ. Mt_masktools-26.dll, RemoveGrainSSE3.dll и RepairSSE3.dll меняем в скрипте (раздел загрузки плагинов).

artemelesin, на googlecode же чёрным по белому указано, что:
А вообще, установите лучше XviD4PSP 5.10.271.0 (2012-02-14) RC28 и MS Visual C++ x86/x64
Дело в том, что по крайней мере в 64-разрядной Win7 библиотеки MS Visual C++ и DirectX по умолчанию присутствуют не в полном объёме.
Поэтому приходится устанавливать полный пакет MS Visual C++ x86/x64 и обновлять DirectX с помощью dxwebsetup.exe (286Кб)

IvGrad
Понятное дело, что библиотеки могут присутствовать не в полном объеме, и не только в 64-разрядной Win7. Удивление мое вызвано тем, что MS Visual C++ нужен сплошь и рядом, многие проги тянут его вместе с собой, поэтому любому юзеру надо бы понимать какие библиотеки MS Visual C++ у него уже есть и следить за их комплектацией, чтобы не возникало таких вот ситуаций не только с XviD4PSP.
И вот снова ему предлагают установить XviD4PSP 5.10.271.0 (2012-02-14) RC28, чтобы он снова нажал "установить С++" - в этом проблема. Местные гуру на подобные вопросы уже просто устали отвечать, поэтому игнорируют, здесь ведь собираются не для обучения элементарным правилам обхождения с компьютером.

Если при установке программы возникают ошибки, то их надо исправлять или же совсем удалить возможность установки библиотек MS Visual C++. Эту надпись надо не на сайте вешать, а добавить предупреждение в саму программу рядом с галочками C++.

DreadMaster, с ошибкой при установке XviD4PSP, если в инсталляторе был выбран пункт MS Visual C++, я лично не сталкивался.
По той причине, что никогда этот пункт в меню не выбирал, а устанавливал необходимые мне библиотеки всегда вручную.
Но это уже вопрос компьютерной грамотности и как правильно заметил тов. shark000X к данной теме не относится.
Теперь по существу. Известно, что на 64-разрядных ОС по умолчанию XviD4PSP устанавливается в папку c:\Program Files (x86)\ .
Это может вызвать ошибку в работе компонентов для которых путь установки прописан, как c:\Program Files\ .
Соответственно, если изначально установить XviD4PSP в c:\Program Files\ , то будет ли всё работать корректно?
Я в принципе могу проверить и сам, но мне просто интересно пробовал ли кто-нибудь такой способ вместо того, чтобы править пути.

IvGrad
В данной ветке об этом писалось ранее. Желающие удовлетворить интерес могут пролистать все 50 страничек... может еще и архивные придется прихватить
По логике вещей, должно бы работать, в крайнем случае идем в реестр и через поиск "Program Files x86" анализируем все привязки.

Не стоит этого делать вообще, это ничего не даст, к тому же mt_masktools-26.dll предназначен для AviSynth 2.6, в конвертере используется AviSynth 2.5.8 MT. В QTGMC используются RemoveGrainSSE2.dll и RepairSSE2.dll те же, что и в конвертере, смотрите по дате релиза плагинов от 19.04.2011. Это касается и обоих плагинов масок. Показуйте свой скрипт, поскольку я вам не верю, что всё сделано правильно. И стоит указать тип исходника и рассказать о своём железе.

Tempter57
Каюсь, забыл уточнить что mt_masktools-26.dll для 2.6МТ. Но вот RemoveGrainSSE3.dll и RepairSSE3.dll точно могут помочь - это от процессора зависит, мой например намного шустрей с инструкциями SSE3 работает, а с SSE2 тупит.

Скрипт Источник https://rutr.life/forum/viewtopic.php?t=2851855
2600k@4400,8 gb,560ti.. win7 64 bit
без setmtmode(5,4) нагрузка 15 %
с setmtmode(5,4) 35%
без фильтра 100 %

Spartan999
Шаблон скрипта в части setmtmode(5,4) вы поняли верно, и даже можно пробовать увеличивать количество потоков вплоть до setmtmode(5,8), судя по CPU и если включен HT, хотя я уже говорил, что серьёзные скрипты надо обрабатывать количеством потоков, равным или меньшим количеству физических ядер. У вас i7-2600k и скорее всего вам надо просто смириться с его неполной загрузкой при работе с подобными скриптами AviSynth. Процесс обработки подобным фильтром и с таким разрешением может занять несколько суток. Вы к этому готовы или оно вам надо? К тому же модератор раздела HD рипов MaLLIeHbKa вряд ли такой рип пропустит к раздаче. Обратите пристальное внимание на её рипы. Есть чему поучиться. Она всегда со своими рипами выкладывает скрипт AviSynth и настройки кодека х264. Но там суть скрипта AviSynth несколько иная. Вообще для создания BDRip необходим уже AviSynth 2.6 с его поддержкой цветового пространства YV24() и XviD 4PSP 5 уже не годится, он не дотягивает современным требованиям, морально и физически устарел, если не сказать проще - сдулся.
Далее ваша ошибка состоит в том, что вы неверно открываете BDRemux да ещё посредством С подобными исходниками так не поступают. Прочтите в техветке "Обработка и пересжатие видео" инструкцию: раздел Подготовка исходного материала. Суть: подобные исходники нуждаются в индексации и открывать их DirectShowSource нельзя!!!
Но мой вам совет отказаться от фильтрации вообще при работе с подобными исходниками: всё можно решить настройками кодеков, как х264 (что проще, хотя и настроек больше), так и Xvid, в последнем, как правило, это решается подбором матрицы квантования, например, heini_mr или шарктузовской 3HR c достаточно высоким битрейтом и коэффициентом качества

Пробовал,безрезультатно. HT включен.. Не готов. Не надо Для себя делаю Буду иметь ввиду.. ... Так и поступлю.. +1
Спасибо за тех.помощь

Spartan999
Вот эту цитату, после которой стоят три точки, надо давать полностью, в смысле для чего и каких целей я говорил. Поскольку существует много исходников иных нежели BDRemux: материалы камкодеров, стареньких DVD, DVB спутниковых каналов, VHS, которым XviD 4PSP со своим набором обработки подходит вполне.

Понял,учту..

Краткий путеводитель по многопоточным режимам МТ (по материалам http://avisynth.org/mediawiki/Internal_functions/Multithreading_functions , http://avisynth.org/mediawiki/MT_support_page и на основе жизненного опыта. Предназначено для широкой аудитории, к формулировкам не придираемся).
На особенностях работы МТ с использованием настроек вида MT("фильтр",2,2) останавливаться не собираюсь, лучше разобраться с setmtmode, который не вызывает побочных эффектов при правильном его применении.
setmtmode(*, 4) - Вторая цифра после запятой определяет количество потоков, которые будут использоваться для обработки ВСЕГО скрипта (в данном примере - 4 ядра без НТ или 4 логических потока с НТ). Такую комбинацию имеет смысл использовать только в начале скрипта, поскольку при дальнейшей его работе количество потоков невозможно поменять. По этой причине в середине скрипта обычно встречается setmtmode(*) с указанием только первой цифры, которой определяется режим работы МТ, т.е. "mode", о чем идет речь дальше:
setmtmode(1) - Самый быстрый режим, но работает только с некоторыми фильтрами, для которых специально предусмотрен, поэтому применяется крайне редко.
setmtmode(2) - Практически самый распространенный режим, работает с большинством фильтров. Работа каждого фильтра распределяется между доступными потоками ПРОЦЕССОРА (физическими и/или логическими), поэтому для обслуживания очереди задач используется больше ресурсов оперативной памяти (иногда требуется тонкая настройка SetMemoryMax).
setmtmode(3) - Предназначен в первую очередь для фильтров, которые не работают нормально в mode 2, в том числе для загрузчиков медиа-источников. Позволяет использовать по одному потоку ПРОЦЕССОРА для каждого фильтра, поэтому работает медленней, чем setmtmode(2), но менее требователен к ресурсам памяти. Данный режим весьма полезен для жадных к ресурсам фильтров, способных самостоятельно (без помощи МТ) разделять свою работу на несколько ВИРТУАЛЬНЫХ потоков внутри потока процессора.
setmtmode(4) - Это комбинация двух режимов - setmtmode(2) и setmtmode(3) - удовлетворяющая, соответственно, требования подавляющего большинства фильтров. Недостатки: является одновременно медленным и требовательным к ресурсам памяти; может запросто подвесить систему при использовании "жадных" фильтров.
Теоретические размышления (цифры карикатурные): setmtmode(6) - Это модифицированная версия режима setmtmode(5) со всеми его недостатками и достоинствами, но работающая чуть-чуть быстрей.
setmtmode(5) - Самый медленный режим. Не устанавливает какие-либо ограничения, поэтому используется в основном перед критичными в этом вопросе загрузчиками медиа-источников. Предназначен для фильтров, не требующих линейного обслуживания фреймов (когда не требуется строгий порядок подачи фреймов: 0,1,2,...,последний). В связи с тем, что подавляющее большинство приложений предусматривает именно линейную подачу фреймов, загрузка процессора при setmtmode(5) обычно в несколько раз меньше, чем работа без МТ вообще, а в зависимости от поставленных задач обработка с setmtmode(5) может оказаться медленней, чем даже на стареньком 1-ядерном Атлон ХР (безо всяких МТ разумеется).
Следует отметить, что все обращения к скриптам Avisynth обрабатываются в обратной последовательности (снизу вверх). Таким образом, например, если составить такой скрипт: то ContraHD будет простаивать в ожидании Temporalsoften, а результаты работы MSuper и ContraHD мы получим не раньше, чем отработает свою задачу Temporalsoften в очень медленном режиме setmtmode(5).
В связи с тем, что обычно пользователю не известны устройство и внутренние алгоритмы работы фильтров (в частности, как именно они используют ресурсы компьютера), при использовании режимов setmtmode весьма благоразумным является измерение скорости работы скриптов с помощью сторонних утилит, не зависящих от Avisynth, например, с помощью AVSMeter ( http://doom10.org/index.php?topic=1817.0 ). Измеритель скорости запускается очень просто: перетаскиваем файл avs-скрипта мышкой на экзешник AVSMeter, ждем пару минут для набора статистики FPS (кадров в секунду), после чего проверка может быть прервана пользователем. При этом каждое изменение параметров setmtmode и setmemorymax проверяется на скорость выполнения, после чего варианты настроек сравниваются и выбирается наиболее оптимальный. Такой подход позволяет сэкономить уйму времени: потратив не более 20-30 минут на предварительные настройки и оптимизацию с помощью AVSMeter, можем избежать нескольких часов или суток лишней обработки в неоптимизированном режиме. ВАЖНО: для успешного использования в 64-битной системе, необходимо пропатчить файл AVSMeter.exe с помощью 4GB.Patch ( http://ntcore.com/files/4gb_patch.zip ) или использовать другую программу с подобными возможностями, чтобы установить в экзешнике флаг "IMAGE_FILE_LARGE_ADDRESS_AWARE".
Всем благ и мультипоточных успехов!
P.S.: Если вы используете Avisynth 2.6 MT сборки SEt ( http://forum.doom9.org/showthread.php?t=148782 ), то в указанной сборке фильтр МТ встроен на уровне ядра Avisynth, поэтому не загружайте фильтр МТ отдельно с помощью LoadPlugin в своих скриптах!
Возможные причины частичной загрузки процессора (<=60%) в режиме МТ, и способы ее устранения:
1) Неверное применение режимов setmtmode(5) и setmtmode(6), а иногда и setmtmode(4) в тех местах скрипта (перед теми фильтрами), где больше подходят режимы 1-3 (изложено выше в данном сообщении);
2) Неверный подбор параметра SetMemoryMax() при использовании режимов setmtmode(2) и setmtmode(4).
Вообще параметр SetMemoryMax находится в подобной зависимости даже без МТ, но при указанных режимах МТ может иметь критическое значение. SetMemoryMax() -- это ограничитель, установка максимума оперативной памяти, которая будет выделена для работы фильтров Ависинт конкретного скрипта. Здесь надо выдержать БАЛАНС между потребностями Ависинта и потребностями кодека. Если мы установим SetMemoryMax слишком большим, то фильтры Ависинт могут вдруг забрать все свободные ресурсы памяти, после чего сами же будут простаивать в ожидании кодировщика, который будет тормозить весь процесс из-за нехватки памяти для кодирования. Если мы установим SetMemoryMax слишком низким, то возникнет обратная ситуация (что и происходит в большинстве таких случаев) -- кодировщик будет простаивать в ожидании фильтров, требующих больше памяти для завершения своих операций. При этом, в последней ситуации могут возникать критические СИСТЕМНЫЕ ОШИБКИ, поскольку в отличие от кодеков, адаптирующихся к объему доступных ресурсов, фильтры Ависинт способны создать очередь заданий, которую компьютерное "железо" не способно обработать физически;
Приведенные выше проблемные ситуации можно спокойно обойти, если применять AVSMeter или подобные утилиты при подготовке скриптов. Однако бывают ситуации, которые невозможно разрешить предложенным способом. Например:
3) Блокирование потоков процессора, доступных кодеку изначально. Важно понимать следующее применительно к многопоточным компьютерным системам (не знаю, ко всем ли кодекам относится, не вижу смысла проверять): Предотвратить эту проблему возможно следующими способами:

-- не запускайте какие-либо приложения, если кодируете с предварительным использованием Ависинта в МТ-режиме (если даже приложению явно не дается более высокий приоритет, то при его запуске могут стартоваться системные службы с такими приоритетами);
-- если все-таки крайне необходимо делать что-то параллельно с кодированием, то запустите все необходимые для работы приложения до старта процесса кодирования, и до его окончания не завершайте их работу;
-- по возможности деактивируйте процессорный режим HT (Hyper-Threading) на компьютере, где обычно производится кодирование;
-- если по каким-либо причинам отключать HT не желательно, то хотя бы четко указывайте кодеку, что он может использовать количество потоков не больше количества физических ядер процессора (если ядер 4, то и потоков кодеку поставить 4, а не используемое по умолчанию например в Xvid4PSP5 количество потоков 6 [4*1,5]);
-- в случае продолжения проблемы или при невозможности использования одного из 4 вариантов выше, попробуйте радикально решить проблему БАЛАНСа, но уже применительно к распределению потоков между кодеком и Ависинт, т.е. изначально задайте фильтрам Ависинта и кодеку количество потоков, которое в сумме не превышает количество физическихядер процессора (например для 6-ядерника: setmtmode(*, 3) в начале скрипта Ависинт и 3 потока кодеку; или setmtmode(*, 4) и 2 потока кодеку). При этом варианте снова лучший помощник AVSMeter или подобные утилиты.

Tempter57, оказывается QTGMC убирает блочность при движении, в исходниках MPEG-2, такая красноватая пыль вокруг контуров. Причем четкость не страдает практически.
Используя MDegrain чет у меня не получалось убрать эту хрень.
Может не те параметры использовал? Или это fft3dfilter отрабатывает? Есть вариант без QTGMC?
QTGMC гружу так:
QTGMC(Preset="Placebo", Sharpness=0.4, FPSDivisor=2)
Кодирую в lossles, иксом, --qp 0

agz
Если отбросить деинтерлейс, то взглянув на принцип шумопадавления и решарпинга GTGMC можно увидеть:
1) мощнейший предварительный фильтр для векторного анализа
2) MDegrain1 для чисто обработки исходника с последующим в начале ремонтом контуров на базе функции RemoveNonBobDiff, потом интересный решарпинг и далее формирование на его базе нового суперклипа
3) Шумоподавитель MDegrain2 на основе нового суперклипа и векторного анализа на основе мощнейшего предварительного фильтра
4) далее два каскада ремонта контуров объектов движения опять на основе функции RemoveNonBobDiff с последующим ремонтом фильтром repair. нет, для этого необходимо в QtGMC подключать опцию Denoicer при том на пресетах Fast и Faster подключается при этом fft3dfilter, а на пресетах Medium, Slow, Slower подключается dfttest. Вариант без деинтерлейса -это DVD Old STB_DB
На предыдущей странице рассматривался новый мощный деинтерлейс TGMC_SVP_Test по типу QTGMC, но гораздо быстрее. Помимо shark000X его просто никто не заметил, а жаль.. он того стоит

Заметил, но до тестированя еще руки не дошли. А так уже везде включен.

Tempter57, да я сразу попробовал. Чет не пошло, не находит SVConvert().

agz
я там сказал, что необходимо скачать архив плагинов 1.0.3 от разработчика chainik_svp и добавить из в папку plugins XviD 4PSP

Tempter57, да да, я уже скачал, заменил. Работает
А что насчет GPU версий? Их можно подгружать вместо стандартных?

Из любопытства собрал из сырца r276.0 (29.11.2011). Код не правил.
Если кому интересно http://narod.ru/disk/46738370001.7589008fbee18fcc410b9e1612b0793c/XviD4PSP%205.10...11.2011).7z.html

Интересно. А что в нем - можно в общих чертах узнать? Какие отличительные особенности? А какие версии Avisynth и MKVToolnix?

пока нет, для этого функцию MDegrain надо иметь с bool "GPU", не всё сразу

Tempter57, перечитал описание QTGMC, в ветке на doom9. Сделал как там рекомендуют:
Тут loadplugin, import
SetMemoryMax(1024)
SetMTMode(3, 8)
MPEG2Source()
SetMTMode(2)
QTGMC(Preset="Placebo", Sharpness=0.4, FPSDivisor=2)
Distributor()
Скорость обработки с 5.5 поднялась до 7.5! Никаких вылетов, уже три lossless'я (720x576, SAR=16/11) закодировал
При увеличении тредов у икса - скорость падает. Стоит --threads 6, по числу ядер.
Проц очень жестко загружен, на все 100%. Никогда такого не видел, всегда были провалы.

Спасибо! Это конкретно атлоновские рекомендации для 6 ядер и placebo? Плюс два потока к числу ядер для QTGMC? Так надо понимать? Спрашиваю так, на всякий случай, потому как до сих пор на slow выпадений не наблюдал, а placebo не юзал. Вправду блоки в сорсе убирает без потери резкости?

Там не указано конкретно для AMD или Intel. На AMD работает отлично. Думаю и на Intel проблем не будет. Да. Может резкость падает, но только там где была блочность. Фон практически не страдает.

agz
OK