|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
07-Июн-12 16:17
(12 лет назад, ред. 07-Июн-12 16:17)
shark000X писал(а):
сколько потоков отдал кодировщику?
6 потоков. При меньшем fps проседает.
shark000X писал(а):
сколько Ависинту
ависинту 4 потока, потому что больше давится. И давится не только fftw3, но и плагин TTчего-то там вылетает с ошибкой в malloc, т.е. не может выделить память из-за ее нехватки.
shark000X писал(а):
учитывая запущенные процессы других программ
это каких других? Сейчас в системе больше никто не грузит проц.
ЗЫ.
Перед финальным кодированием делал тестовое кодирование семпла с составлением таблицы fps при разных кол-вах потоков. По ней и ориентировался. Потом может vbs-скрипт сделаю для автосоздания этой таблицы.
Кодирование идет так: avs2pipemod (AviSynth 2.6 MT) => x264_64-10bit.
В скрипте функция MCTD(settings="high", twopass=false)
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
07-Июн-12 18:08
(спустя 1 час 51 мин., ред. 07-Июн-12 18:08)
unreal666
гы-гы, сижу жду ответа на предыдущей страничке, обновляя ее периодически  капэць...
Запамятовал, что у тебя 32+64, поэтому мои вопросы были не уместны, равно как и ответы на них. Чтобы "руками пощупать" проблему прожорливости, надо кодек и Ависинт поставить в равные условия, а не так что последний страдает от нехватки памяти, а первый рассекает по широким 64-битным морям. Если откинуть в сторону легкую фильтрацию, которой МТ и не нужен, а также непритязательные середнячковые варианты, то окажется, что в одной и той же системе идеальное соотношение баланса по загрузке обычно предполагает меньшее количество потоков кодеку и большее Ависинту МТ, и только изредка равное распределение. Однако при этом кодек с удовольствием потреблял бы больше и процесс ускорился бы (потому что скорость современных кодеков находится в геометрической зависимости не столько от качества, сколько от количества потоков), но это невозможно сделать, потому что тогда некуда будет распихивать потоки Ависинта. Остается ожидать появления Горгоно-процессоров (будь то на физическом или логическом уровне).
О! А что за vbs-скрипт для автосоздания таблицы? (если чё, в ЛС плиз)
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
07-Июн-12 18:45
(спустя 36 мин., ред. 07-Июн-12 18:45)
shark000X писал(а):
Запамятовал, что у тебя 32+64
А это не сильно и влияет. Вообще по разным прогам (avs2pipe + x264) я распихал, чтобы была меньше вероятность нехватки памяти процессу (один занимается ависинтом, другой кодированием). Ну раз распихал, то почему бы не воспользоваться преимуществами x264_x64.
Вообще, интересно было бы разбить какую-нибудь мощную функцию-скрипт на меньшие части и каждую часть обрабатывать в отдельном скрипте с подгрузкой предыдущей через .vdr.
Т.е. типа
abisynth -> VD -> avisynth -> VD -> avisynth -> VD -> avisynth -> x264 
Тогда по идее каждому из них должно будет хватать памяти для большего кол-ва потоков.
shark000X писал(а):
деальное соотношение баланса по загрузке обычно предполагает меньшее количество потоков кодеку и большее Ависинту МТ, и только изредка равное распределение.
ну. До этого кодил видео, насчет которого говорили.
По тестам наилучший результат при avs-потоках 1-4 и x264 потоках 1-12 получился при avs=4 (само собой) и x264=12. Немного ближе было еще при x264=6 (между 6 и 10 скорость почему-то была ниже).
shark000X писал(а):
О! А что за vbs-скрипт для автосоздания таблицы? (если чё, в ЛС плиз)
Да просто натравливать x264 с нужными параметрами на avs-файл и перебирать кол-во потоков avs и x264 и в конце выдать или файл с таблицей-логом или просто вывести на экран с помощью функции MsgBox.
shark000X писал(а):
гы-гы, сижу жду ответа на предыдущей страничке, обновляя ее периодически
а ты обновляй не эту страницу, а страницу "Мои сообщения"
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
07-Июн-12 19:54
(спустя 1 час 9 мин., ред. 07-Июн-12 19:54)
unreal666
скрытый текст
Цитата:
Вообще, интересно было бы разбить какую-нибудь мощную функцию-скрипт на меньшие части и каждую часть обрабатывать в отдельном скрипте с подгрузкой предыдущей через .vdr.
Т.е. типа
abisynth -> VD -> avisynth -> VD -> avisynth -> VD -> avisynth -> x264
Весьма заманчивая идея  вот только одно не пойму: VD, насколько вижу, хотелось бы сделать простым буфером для перераспределения ресурсов памяти, но ведь Ависинт тоже фреймсервер... не лучше ли было бы найти способ запустить одновременно два Ависинта, чтобы оба фреймсервера делали последовательную работу, а не просто буферил один из них?
Цитата:
vbs-скрипт... просто натравливать x264 с нужными параметрами на avs-файл и перебирать кол-во потоков avs и x264 и в конце выдать или файл с таблицей-логом или просто вывести на экран с помощью функции MsgBox.
Хотелось бы попробовать рабочий вариант 
Цитата:
а ты обновляй не эту страницу, а страницу "Мои сообщения"
обычно так и поступаю, когда в нескольких ветках сразу общаюсь, а тут в одной застрял (не подумал, что мой пост последний на странице)
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
07-Июн-12 20:08
(спустя 13 мин., ред. 07-Июн-12 20:08)
shark000X писал(а):
вот только одно не пойму: VD, насколько вижу, хотелось бы сделать простым буфером для перераспределения ресурсов памяти, но ведь Ависинт тоже фреймсервер... не лучше ли было бы найти способ запустить одновременно два Ависинта, чтобы оба фреймсервера делали последовательную работу, а не просто буферил один из них?
Тоже фреймсервер, но ависинт не отдельная прога. В качестве проги для ависинт и выступает VD.
В данной цепочке есть одно "но". Нужно больше общей памяти, т.к. на каждом шаге будут свои кэши ависинта.
ЗЫ.
Как вариант вместо VD создать какой-нибудь avs-плагин для приема данных из консольного потока, а не из файла. Тогда любой прогой, типа avs2pipe можно будет передавать данные в другой avs2pipe и так по цепочке.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
07-Июн-12 20:15
(спустя 6 мин., ред. 07-Июн-12 21:01)
unreal666
я ж об этом и говорю, иначе пусть мне объяснят как запустить Ависинт без помощи сторонних программ:):):)
на счет кэша, кстати, вот интересный вариант, с ним может и второй фреймсервер не понадобится: http://avs2raw.com/ (не пробовал)
А что если в качестве буферного сервера использовать Ависинт х64  или он глючит как раз по кешу?
|
|
|
|
Lenchik
Стаж: 17 лет 11 месяцев Сообщений: 854
|
Lenchik ·
07-Июн-12 20:59
(спустя 44 мин.)
unreal666, shark000X
Насколько я помню, в ffdshow есть фреймсервер для ависинта makeAvis, который позволяет скрипты представить avi'шками (так и циклить скрипты через avisource). Потом ещё VFAPI.
Еще вот вам в тему http://forum.doom9.org/showthread.php?t=162006
и http://forum.doom9.org/showthread.php?p=1577288#post1577288
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
07-Июн-12 21:04
(спустя 4 мин.)
Lenchik
Привет кладезю знаний
сорри, добавил последнюю строчку в предыдущий пост синхронно...
На эту тему unreal666 мозговой центр, мне просто тема понравилась
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
07-Июн-12 21:57
(спустя 53 мин., ред. 07-Июн-12 21:57)
Lenchik писал(а):
Насколько я помню, в ffdshow есть фреймсервер для ависинта makeAvis, который позволяет скрипты представить avi'шками (так и циклить скрипты через avisource). Потом ещё VFAPI.
И как это поможет сделать вышеуказанную цепочку? Тут главное не как открыть скрипт, а как передать выходные данные одного скрипта в другой в разных процессах.
Если я просто соединю эти avi-шки в цепочку, исполняться они все равно будут в одном процессе, т.к. exe-шник то один.
shark000X писал(а):
на счет кэша, кстати, вот интересный вариант, с ним может и второй фреймсервер не понадобится: http://avs2raw.com/ (не пробовал)
Какая-то платная непонятная штука. Была бы ломанная
Судя по описанию, используется ST-версия ависинта. Многопоточность в нем реализована как я и думал: создается несколько копий проги, каждая из которых обрабатывает свою порцию кадров и потом отдает их основному процессу. Вот пример запуска командной строки этих вспомогательных процессов:
Код:
"I:\avs2raw.exe" -i "I:\test.avs" -o "I:\test.yuv" *MT* 1600 1999 -cachesize 3489792000
После *MT* идет диапазон обрабатываемых кадров.
cachesize - это походу размер кэша в самом выходном файле (т.к. он создался точно такого размера).
Т.е. выходной файл одновременно является и кэшем. Оригинальная идея - что-то типа распределенной памяти получается.
НО:
1. На YV12 почему-то поматерилась, что нифига он не YV12.
2. Поддержка только YV12, YUY2 и RGB24/32.
3. Что-то не увидел возможности передачи выходных данных в поток.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
07-Июн-12 22:30
(спустя 32 мин.)
unreal666 писал(а):
Lenchik писал(а):
Насколько я помню, в ffdshow есть фреймсервер для ависинта makeAvis, который позволяет скрипты представить avi'шками (так и циклить скрипты через avisource). Потом ещё VFAPI.
И как это поможет сделать вышеуказанную цепочку? Тут главное не как открыть скрипт, а как передать выходные данные одного скрипта в другой в разных процессах.
Та не, мысля дельная на самом деле. Указанные проги, как понимаю, позволяют выкладывать резульатты работы скрипта в виде виртуального файла, после чего такие "файлы" открываются в следующем скрипте и продолжается обработка этого промежуточного результата сос ледующими фильтрами...
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
07-Июн-12 22:42
(спустя 12 мин., ред. 07-Июн-12 22:42)
shark000X
makeAvis ничего не выкладывает. Он просто преобразовывает avs в avi, который можно открыть обычным AviSource с помощью ffdshow.
VFAPI делает подобное.
Нужно делать как AVS2RAW, только не параллельную цепочку создавать, а последовательную. Хотя его идея с параллельностью мне вкатывает, только допилить его под 2.6 и сделать бесплатным
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
08-Июн-12 00:15
(спустя 1 час 32 мин., ред. 08-Июн-12 00:15)
unreal666 писал(а):
Нужно делать как AVS2RAW, только не параллельную цепочку создавать, а последовательную. Хотя его идея с параллельностью мне вкатывает
угумс
Цитата:
допилить его под 2.6 и сделать бесплатным
это для меня -- темный лес в плане реализации 
ПС: кстати вспомнил... глубокоуважаемый мною LoRd_MuldeR давно ведь соорудил подобную утилиту ( http://forum.doom9.org/showthread.php?t=144140 ), которой не хватает лишь переходов между ее же пайпами, которые для твоих целей должны быть виртуальными, т.е. не давать выход на кодирование. Может на крайняк ему такую идею подкинешь, если проблемы с реализацией? Ему такое добавить к замечательному продукту -- раз плюнуть 
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
08-Июн-12 03:27
(спустя 3 часа, ред. 08-Июн-12 03:27)
shark000X писал(а):
глубокоуважаемый мною LoRd_MuldeR давно ведь соорудил подобную утилиту
И что он там такого соорудил? Обычная GUI-шка для avs2pipe + x264.
shark000X писал(а):
что в одной и той же системе идеальное соотношение баланса по загрузке обычно предполагает меньшее количество потоков кодеку и большее Ависинту МТ
Вот это по моему неправильно, т.к. в таком случае у ависинта кол-во потоков, свыше кол-ва потока x264, будет просто бесполезно простаивать.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
08-Июн-12 11:21
(спустя 7 часов, ред. 08-Июн-12 11:21)
unreal666 писал(а):
в таком случае у ависинта кол-во потоков, свыше кол-ва потока x264, будет просто бесполезно простаивать.
Если фильтры тяжелые, то нет. Грубо говоря (применительно к системе 32+32), если загрузить отдельно фильтры на все имеющиеся потоки и посмотреть скорость выполнения, а потом загрузить отдельно кодек на все потоки и посмотреть скорость выполнения, то:
-- если эти скорости окажутся равными (крайне редко), то при совместном их использовании пострадает в большей степени скорость кодека;
-- если большей окажется скорость кодека (чаще всего), то смело отдаем фильтрам больше потоков -- они не будут простаивать, благодаря им будет предотвращено еще большее падение скорости фильтров, при котором как раз наоборот кодеку придется ожидать. Но при этом конечно нужно тонко выбрать баланс по соотношению потоков;
-- если большей окажется скорость фильтров, то выбирать соотношение начинаем смело с равных пропорций в сторону увеличения потоков кодека. При этом в большинстве случаев такое увеличение будет незначительным, иначе фильтры легкие и им скорей всего не нужен МТ.
unreal666 писал(а):
И что он там такого соорудил? Обычная GUI-шка для avs2pipe + x264.
Ну может этот продукт мне более интересным показался по той причине, что пайпами не пользовался. Однако в нем реализована возможность выбора между параллельной и последовательной обработкой в совместном 32+64 или отдельных режимах, а это уже почти половина из того, что тебе нужно.
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
08-Июн-12 13:38
(спустя 2 часа 16 мин., ред. 08-Июн-12 13:38)
shark000X писал(а):
Если фильтры тяжелые, то нет.
Вообще-то каждый такой поток в ависиинт обрабатывает один кадр, т.е. он как бы самодостаточный. Если x264 будет запрашивать кол-во кадров меньше, чем кол-во потоков ависинта, то остальные потоки ависинта просто не будут запускаться, т.к. 1 поток ависинта = 1 кадр. Можно в ависинт воткнуть на 1 поток больше, чем в x264, т.к. после отдачи кадра поток завершается не мгновенно.
shark000X писал(а):
Однако в нем реализована возможность выбора между параллельной и последовательной обработкой в совместном 32+64 или отдельных режимах, а это уже почти половина из того, что тебе нужно.
у него там в папке просто 32-х и 64-х битные avs2pipe и x264. Параллельность в нем - это тоже самое, что одновременно запустить 2 задачи в MeGUI или просто вручную.
|
|
|
|
DesertMt
Стаж: 17 лет 5 месяцев Сообщений: 26
|
DesertMt ·
08-Июн-12 13:57
(спустя 19 мин.)
подскажите как правильно должен выглядеть скрипт ависинта. с фреймсервера идёт видео YUV2. создаю для MEGUI скрипт где мне нужно указать ColorMatrix(mode="Rec.601->Rec.709", inputFR=false, clamp=0) . MEGUI предлагает сам вставить в конец срипта ConvertToYV12(). как правильнее будет сначала ColorMatrix а потом ConvertToYV12() или наоборот ? в XviD4PSP 5 я посмотрел ColorMatrix идёт после ConvertToYV12(). разьяните пожалуйста
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
08-Июн-12 14:54
(спустя 57 мин., ред. 08-Июн-12 14:54)
unreal666 писал(а):
у него там в папке просто 32-х и 64-х битные avs2pipe и x264. Параллельность в нем - это тоже самое, что одновременно запустить 2 задачи в MeGUI или просто вручную.
значит мимо, буду знать...
Цитата:
Если x264 будет запрашивать кол-во кадров меньше, чем кол-во потоков ависинта, то остальные потоки ависинта просто не будут запускаться, т.к. 1 поток ависинта = 1 кадр. Можно в ависинт воткнуть на 1 поток больше, чем в x264, т.к. после отдачи кадра он завершается не мгновенно.
не-а, не совпадает с моим пониманием. Чтобы не показывать долго на пальцах, вот принципиальная схема всего этого действия: http://avisynth.org/mediawiki/MT_modes_explained . На выходе последнего фильтра Ависинт имеем кэшированный результат вне зависимости от того, сколько там выше использовалось потоков и как по ним распределялись или нет (в режиме 3) обрабатываемые фреймы. Получателю конечного кэша, будь то ВиртуалДаб, или другой редактор, или кодировщик, в том числе x264,-- ему по барабану сколько потоков использовалось для производства конечного кэша, его интересует только содержимое кэша. На всякий случай, вот как обрабатывается кэш в Ависинте МТ:
скрытый текст
class Cache
{
public: //These function should be threadsafe. The most simple way is to use
a //critical section like
this PVideoFrame GetCachedFrame(int
framenumber)
{
EnterCriticalSection(&cs);
//Code
//...
LeaveCriticalSection(&cs);
return retval;
} SetCachedFrame(PVideoFrame
frame);
private:
CRITICAL_SECTION cs;
}
class Sample : public GenericVideoFilter{
public:
Sample(PClip _child, IScriptEnvironment* env);
~Sample();
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
protected:
PClipLocalStorage cls;
Cache* FrameCache;
}
Sample::Sample(PClip _child, IScriptEnvironment* env)
:
GenericVideoFilter(_child),cls(env)
{ //if the cache has not been created yet GetValue will return 0
if(cls->GetValue()==0) {
//create the cache and save the address in the PClipLocalStorage
FrameCache = new
Cache();cls->SetValue(static_cast(FrameCache));
}
// The cache has been created so assign the address to FrameCache
else {
FrameCache=static_cast(cls->GetValue());
}
}
Sample::~Sample()
{
//only delete FrameCache if it is not delete yet.
if(cls->GetValue()!=0) {
delete FrameCache;
cls->SetValue(0);//Signal that the cache is deleted
}
}
Конечно нельзя исключить ситуацию, когда какому-то разработчику взбрело в голову организовать свое ПО так, чтобы оно запрашивало из указанного кэша какое-то конкретное количество фреймов в зависимости от количества потоков, используемых таким ПО. Однако, возвращаясь к твоему тезису, мультипоточность в х264 основана на принципе разделения фрейма на так называемые слайсы. То бишь, запрашивая фреймы, х264 разделяет их на мелкие куски, распределяя их для кодирования по нескольким доступным потокам. Здесь может возникать простаивание только если фильтры Ависинта не успевают выполнить свою задачу (при любом количестве доступных для них потоков).
Вся эта "кухня" в Ависинте вообще непрерывна до момента завершения обработки самого последнего фрейма, а обработка каждого фрейма как раз завершается "мгновенно" в момент его размещения в конечном кэше.
Как-то так 
ПС: проблемы у тебя, верней у твоей 32+64 системы, с памятью в 32-битной части. При 32+32 тебе сам доктор прописал отдавать больше потоков Ависинту при использовании тяжелых фильтров. Кстати, хз может оно так и быстрее работало бы. Но как очень интересный вариант рассматриваешь цепочку из двух фреймсерверов, чем такое решение меня и привлекло -- если будет работать, то может и сам на х64 перейду
И еще одно "кстати": ранее упоминалось отсутствие разницы между реально доступным объемом физической памяти и ее размещением в свопе. Таки ведь разница имеется и существенная, поскольку работа со свопом конкретно тормозит -- скорость любого диска несоизмеримо медленней по сравнению с оперативкой и кэшем процессора. Поэтому х64 система конечно привлекательней, но нет под нее нормального Ависинта... заковыка.
DesertMt
а методом научного "тыка" такие простые вопросы не выясняются?.. попробовать так и этак, если лень или нет времени почитать
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
08-Июн-12 15:06
(спустя 11 мин., ред. 08-Июн-12 15:06)
shark000X писал(а):
вот как обрабатывается кэш в Ависинте МТ:
Я в C++ ни бум бум. С меня пока для изучения хватает питона и углубление в джаваскрипт. Нужно, чтобы подправить код одной проге.
shark000X писал(а):
Но как очень интересный вариант рассматриваешь цепочку из двух фреймсерверову
Необязательно из двух. Но в последовательной цепочке недостаток в том, что если тяжелая функция всего одна, то ее надо разбивать на мелкие. А это как-то не комильфо получается, разбивать чужую функцию на части. А вот с параллельной обработкой нескольких диапазонов кадров за раз уже интересней. Только придется, как и в той проге, делать кеш на винте.
shark000X писал(а):
И еще одно "кстати": ранее упоминалось отсутствие разницы между реально доступным объемом физической памяти и ее размещением в свопе. Таки ведь разница имеется и существенная, поскольку работа со свопом конкретно тормозит -- скорость любого диска несоизмеримо медленней по сравнению с оперативкой и кэшем процессора.
SSD диск в помощь. Хоть и медленней RAM, но все равно намного быстрей HDD. Правда стоят дофига.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
08-Июн-12 15:15
(спустя 9 мин., ред. 08-Июн-12 21:22)
unreal666 писал(а):
Я в C++ ни бум бум. С меня пока для изучения хватает питона и углубление в джаваскрипт.
гы, я вообще в программировании ни бум-бум, скрипт привел, чтобы показать принцип действия (в целом вроде понятно, это ж не ассемблер)
Цитата:
SSD диск в помощь... Правда стоят дофига.
таки да... да,да,да
ППППС: коллега, а вот эта штуковина знакома: http://forum.doom9.org/showthread.php?t=163281 ?
И в той же ветке обсуждение, из которого следует, что мы вроде бы не зря патчили dll-ки, но может еще стоило пропатчить avisynth.dll... или я чего-то не так понял (времени щас не особо на разбираться)
|
|
|
|
Xant1k
Стаж: 16 лет 1 месяц Сообщений: 3566
|
Xant1k ·
09-Июн-12 15:21
(спустя 1 день, ред. 09-Июн-12 15:21)
|
|
|
|
Phekla333
Стаж: 14 лет 11 месяцев Сообщений: 18
|
Phekla333 ·
09-Июн-12 17:30
(спустя 2 часа 8 мин.)
Рискну спросить, может поможете товарищи спецы.
Видео в формате AVI на компьютере звучит, а на DVD-плэере не звучит, что сделать, чтобы зазвучало?
Спасибо.
Rhekla3333.
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
09-Июн-12 20:22
(спустя 2 часа 52 мин.)
shark000X
попробуй у себя примени юзер. функцию MCTD (файл наз-ся MCTDmod_чего-там, у себя я его имя укоротил) с 8 потоками и ависинта и x264 на 1080p или хотя бы на 720. Будет ли вылет.
Phekla333
выкинуть плеер.
а если нужен нормальный ответ, то вспомни, что телепатов пока мало.
какие хар-ки видео (отчет MediaInfo), какая модель плеера и чего он там поддерживает?
ЗЫ.
есть мудрость/правило: в правильно заданном вопросе содержится половина ответа.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
09-Июн-12 21:11
(спустя 49 мин., ред. 09-Июн-12 21:11)
unreal666
если интересует 8+8 потоков, то на Q6600 есть смысл проверять, как думаешь?
Xant1k писал(а):
вокруг объектов неприятная размытость
а может это mosquito-noise?
|
|
|
|
unreal666
Стаж: 16 лет 5 месяцев Сообщений: 1712
|
unreal666 ·
09-Июн-12 21:13
(спустя 1 мин.)
shark000X писал(а):
то на Q6600 есть смысл проверять, как думаешь?
Без разницы. Просто проверка на вылет. На кол-во ядер пофигу.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
09-Июн-12 22:29
(спустя 1 час 16 мин., ред. 09-Июн-12 22:29)
Xant1k
глянул сэмпл исходника, таки вроде он -- mosquito-noise, чистить надо исходник, а не настройки кодека насиловать... попробуйте найти решения на основе частотных фильтров
unreal666
ОК, но не сразу, чуть позже смогу, я щас чуть ли ни с планшета с тобой калякаю
ППППС: м-дааа, таки выявил ты брешь... безо всяких нагрузок по кодированию, вываливается сам скрипт при запуске -- при 7 потоках запускается, а 8 уже не хочет
|
|
|
|
Xant1k
Стаж: 16 лет 1 месяц Сообщений: 3566
|
Xant1k ·
10-Июн-12 07:07
(спустя 8 часов)
shark000X
Цитата:
а может это mosquito-noise?
Теперь уже оно, наверное...)
Цитата:
чистить надо исходник
Глянул сейчас исходник и там так называемого mosquito-noise не наблюдается почти в этом кадре. И если я правильно понимаю он стал сильнее после рипа т.к битрейт ниже стал или какие-то настройки не докрутил. Другого объяснения не вижу.
Цитата:
попробуйте найти решения на основе частотных фильтров
Например, FFT3DFilter?
Чувствую я попал 
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
10-Июн-12 11:03
(спустя 3 часа, ред. 10-Июн-12 11:06)
Это ж Вы вроде писАли. По логике высказывания следует, что вырезка из первоисточника. Если так, то mosquito там имеется в большинстве кадров. Если это криво построенная фраза, т.е. вырезка из рипа, то mosquito мог появиться после предварительной фильтрации кривыми инструментами или с кривыми настройками. Тогда лучше их не применять, поскольку mosquito -- это одна из самых сложных проблем, его невозможно удалить полностью (только сделать наименее заметным).
Xant1k писал(а):
Например, FFT3DFilter?
Чувствую я попал
Мыслите в правильном направлении, но и не только FFT3DFilter. Готового решения на блюдечке тут быть не может, надо пробовать варианты. Да, Вы попали... в ситуацию, когда пришло время узнать много нового и полезного, но потратить на это время.
|
|
|
|
Xant1k
Стаж: 16 лет 1 месяц Сообщений: 3566
|
Xant1k ·
10-Июн-12 11:07
(спустя 4 мин., ред. 10-Июн-12 11:07)
Цитата:
По логике высказывания следует, что вырезка из первоисточника.
Как раз таки по логике следует из рипа вырезка потому как
Цитата:
Оцените кач-во рипа
Насчёт остального даже не знаю...Образ m2v делал через DGIndex стандартным способом. Настройки кодека приложил.
Цитата:
Пришло время узнать много нового и полезного
Что ж, буду пробовать тогда сначала с этим фильтром справится.
|
|
|
|
shark000X
Стаж: 13 лет 11 месяцев Сообщений: 435
|
shark000X ·
10-Июн-12 11:15
(спустя 7 мин., ред. 10-Июн-12 11:15)
Xant1k
Действительно не видите разницы между двумя фразами (?):
Не, ну конечно есть народы, которые пишут и читают то ли сверху вниз, то ли снизу вверх. Я не из их числа, сорри.
Читаю последовательно слева на право, чтобы логика высказывания не искажалась, поскольку вроде на русском написано.
ПС: FFT3DFilter сам по себе может быть и не эффективен. Попробуйте в поиске что-то типа "avisynth frequency denoiser"
|
|
|
|
Xant1k
Стаж: 16 лет 1 месяц Сообщений: 3566
|
Xant1k ·
10-Июн-12 11:21
(спустя 6 мин., ред. 10-Июн-12 11:21)
shark000X
Наверное всё таки у программистов/айтишников и тех кто с математикой и другими точными науками дружит другое мышление нежели у рекламщиков/творческих людей
...а возможно забыл дописать "с рипа":)
|
|
|
|
