Данная тема посвящена извечному вопросу. Нет, быть или не быть можно поискать в поиске, а в этой теме найдете ответы (или предложите свои) на вопросы : о кодировании видео, перекодировки видео из одного формата в другой и т.д.

FAQ по теме - http://forums.overclockers.ru/viewtopic.php?p=219601#219601. Обязателен к прочтению. Вопросы, на которые можно получить ответ в факе, будут удаляться. Особо рьянных будем одаривать картами и баннами.
Отредактировано куратором: Максим. Дата: 12.02.2007 19:31
Отредактировано куратором: SCIF-1986. Дата: 21.06.2007 1:53

На правах оффтопа (Извините, но интересно просто)...
Скажите, пожалуйста, кто нибудь знает как реализована поддержка многопоточности в кодеках? Т.е. все потоки обрабатывают один и тот-же кадр (разделенный на фрагменты) или каждый поток работает над своим кадром?
И еще интересно почему бы не сделать поддержку многопоточности по следующему принципу :
Смотрим сколько есть ядер (реальных, виртуальных); Разбиваем фильм на столько же фрагментов; Запускаем такое-же кол-во потоков (каждый поток (ядро) работает над своим куском фильма); В самом конце какой-то один (главный) поток обрабатывает информацию на стыке фрагментов (типа если для получения кадра нужна информация 2-х предыдущих и 2-х последующих кадров).
В таком виде было бы реальное увеличение скорости кодирования при переходе с одного ядра на большее число (2, 4, ...).

И еще. Кто недавно пересел с одного ядра на два, скажите, плиз, на сколько увеличилась скорость кодирования.

Senator2
Ну я скажу, без проблем.
В Xvid и DivX насколько я знаю реализованно так - одно ядро ищет инфу для векторов и макроблоков, а второе сжимает предущий кадр. В X264 сделано по другому - кадр делиться на число потоков, то есть если два ядра и кадр 704 на 512, то для каждого ядра достанется кадр 704 на 256.
Потом благодаря двум потокам (или больше) еще включается в X264 следующая вещь - пока одно ядро работает с поиском макроблоков и векторов, другое запускает на выполнение обработку следующий кадр в AviSynth. Несколько не понятен сам подход правда, потому что только при --threads 2 такое включается, то есть получается так, что оба ядра уже заняты - но правда факт есть факт, есть прирост, правда всего 1-1.5 fps.

Прирост где-то 70-80 процентов, правда при этом если на одном ядре была у меня всегда загрузка проца порядка 98-100 процентов, то сейчас для каждого ядра 75-85 (максимально 90 процентов) загруз. И иногда бывают интересные вещи типа того, что одно ядро может загрузить на 90 процентов, а другое процентов на 40 - видимо с одной частью изображения сложнее работать, да может быть и обработка AviSynth попала на это хорошо загруженное ядро.

Максим Спасибо за информацию... В X264 сделано по уму (по крайней мере распределение на потоки. Не нужно будет оптимизировать под четыре ядра и больше (все уже сделано).
Хотя все равно интересно почему нельзя разделить весь фильм на несколько фрагментов (как я предположил/предложил выше, так было бы лучше). И переписывать в самом кодеке я думаю не много нужно.

70-80% это очень даже хорошо...
А никто не пробовал запустить кодироваться 2 фильма одновременно (1-й на одно ядро, 2-й - на второе). Если так можно, то, по идее, должно быть почти 100% увеличение скорости.

Senator2
Можешь запустить сразу и два фильма на кодирование и ставь тады --threads 1, но при этом у тебя одна фича описанная выше отключиться, а потом при таком подходе у тебя будет не возможность использования фильтров типа FFT3DGPU. И еще прикол может случиться такой, что тебе или памяти не хватит (некоторые скрипты у меня в пике имели около 700 MB), либо сам avisynth начнет глючить (наверное из-за кучи все время переопределяемой памяти).

А деление кадра на несколько частей в X264 - это кстати плохо. Лучше бы эту часть сделали, как в Xvid.

Я даже осмелюсь предположить что уважаемый mein в своей тулзе вполне мог бы осуществить такой подход (программно разбить фильм на нужное кол-во кусков, создать необходимое кол-во заданий, и запускать каждую пару заданий на своем ядре а потом все это дело склеить).
Хотя, для X264 это наверное не нужно, т.к. сам кодек это делает (пусть и не в таком варианте).
А вот если бы такое прицепить к тому же GordianKnot (для XVid)...
Добавлено спустя 5 минут
Максим Спасибо. С фильтрами конечно будет неувязка... Нужно и фильтры переделывать

Senator2
АГА, будет не увязочка будет.

To all
Кстати, Fizick на Думе обещался проверить и попровать оптимизировать под модифицированную библиотечку FFTW3.dll (позволяет многие функции в данной библиотечке переделать под GPU - то есть многие фильтры с фурье-преобразованием можно будет запускать с применением GPU. То есть как FFT3DGPU, только не от tsp, а от самого Fizick)

да они сделали как можно проще с разбиением кадра на части - видимо так меньше гемороя с программированием.

Даже если получится, то всё равно недостатки есть. Кроме того я в многопроцессорности не разбираюсь . Оставляем побольше разрешение и разница будет малозаметна между двухпоточным(или больше) и однопоточным сжатием, в той реализации, которая щас имеется.

Подождем... Посмотрим что получится...
А то на моей 6600GT FFT3DGPU дает около 4fps при кодировании с использованием данного фильтра, а с FFT3DFilter - 8-12 fps.

Senator2
По поводу твоей разницы - не честно говоря такое не особо может быть .... у меня FFT3DFilter дает те же 8-10 кадров, а FFT3DGPU 16-20 fps - разница есть. Кстати, я это тестил еще когда не было фичи, на запуски отработки ависинта на следующем кадра - может быть чего-то и изменилось (причем как я понимаю разница была бы еще больше, так как процессор как грузило, так и грузит. А GPU он и в африке GPU.

mein
Все бы хорошо, но на более большом количестве ядер и стало быть более большом количестве потоков, разница в качестве заметна становиться. Тестил на сервере с четырьмя Opteron 870 - заметны переходы, и некоторые различия в блурах. Например самая верхняя и самая нижняя части всегда выглядели несколько детальнее, чем те, которые были ближе к центру (проверялось на клипах, например один из клипов - RHCP - Scar Tissue)

Всем привет ребят. такой вопрос чем конвертнуть .avi чтоб уменьшить разрешение до 176 на 220 мне на смарт надо ролики залить

Максим
Ну дык у Вас и карточка покруче будет . Я просто на каком-то фильме специально попробовал с использованием FFT3DGPU и с FFT3DFilter. Так первый медленнее делает чем второй. Загрузка проца при использовании первого - была на уровне 50-60%, а видяха работала на полную (я так понимаю проц простаивал пока видяха выдаст ему результат фильтрации). Так что пока я от использования данного фильтра отказался (FFT3DGPU).
mein
Я тож не силен в многопроцессорности, но помоему там есть какой-то параметр при запуске из командной строки, который указывает что вот это выполнять на таком-то ядре... Вы же запуск задания делаете из командной строки?
Но это так, размышления, для X264 оно скорее всего не относится...
Добавлено спустя 5 минут, 16 секунд
Вот поэтому я думаю что лучше будет делить не кадр на куски, а весь фильм, и каждый кусок кодить отдельным потоком.

Smert-NIK
Для этого самое лучшее, что я видел - SmartMovie (это если нужно в avi получить). Если получить на выходе 3gp - то лучше Nokia Media Converter.

Zharun Может потому что я использую XVid а не X264. Ведь Xvid кодится быстрее... И процу приходится ждать пока GPU выдаст результат для кадра...

Senator2
У тебя вероятнее всего стоял включенный AA и AF. Их нужно отключать
Добавлено спустя 1 минуту, 12 секунд
Senator2
Я в Xvid кодирую, только если этот фильм потом захочу смотреть на стационаре. x264 лучше

Печально, видимо ещё не отработали как надо.
Senator2 я запускаю createprocess'ом - там вроде нет указания конкретного ядра для процесса

mein
Вот такие пироги. А Xvid и DivX новые вообще не запускаются на такой системе

Максим ты имееш в виду конвертер что в месте со Смарт Муви идет, а я про него забыл спасиба что напомнил!!!!

Smert-NIK
Не за что