Есть ли способ распределить задания кодирования x264 по нескольким компьютерам (чтобы увеличить скорость кодирования)?

29

Кто-нибудь знает о текущем, активном решении для кодирования видео x264 на многих компьютерах (через сеть), чтобы увеличить кодирование FPS?

Брауни указывает на кроссплатформенность и открытый исходный код, но, как вы все знаете, я обычно использую Windows.

Программы, о которых я слышал, и почему я не верю, что они подходят:

  • x264farm : не активно развивается. Хороший интерфейс, но не поддерживает двухпроходное кодирование и не работает с более новыми сборками x264.
  • ЭЛДЕР : Опять же, не активно разрабатывался, но моя проблема заключалась в том, что он не работал с новыми сборками x264, и его было очень сложно настроить (читай: случайно перестал работать).

Хотя мне абсолютно не нужна программа, которая активно разрабатывается, мне бы хотелось, чтобы она поддерживала двухпроходное кодирование и работала с новыми (er) сборками x264 .

Дополнительная информация : До сих пор я предложил (и наградил!) Две отдельные награды по этому вопросу с тех пор, как впервые опубликовал его более двух лет назад, и до сих пор не нашел решения этой проблемы. По сути, я ищу простую программу, позволяющую мне кодировать видео x264 с использованием вычислительной мощности нескольких компьютеров, подключенных по локальной сети. Кроме того, было бы неплохо, если бы он работал с новыми сборками (er) x264 и поддерживал двухпроходное кодирование.

Если в какой-то момент кто-то получит обновленный ответ или новое решение этой проблемы, пожалуйста, опубликуйте его, и он будет рассмотрен.

Обновление 2016 :

После большого опыта работы с компьютерным / машинным зрением я понял, что накладные расходы, связанные с большим объемом совместно используемых данных / памяти, и потенциальное узкое место, которое они представляют, могут перевесить потенциальные выгоды.

Хотя я все еще хотел бы найти что-то, что позволило бы мне использовать простую вычислительную мощность нескольких устройств, на данный момент современные кодировщики на основе GPGPU являются гораздо лучшим подходом, если вам требуется улучшенное кодирование в режиме реального времени. Это то, что предоставляют большинство облачных платформ кодирования видео (что является еще одной альтернативой, если вы используете SaaS или облачные вычисления), хотя и в более широком масштабе.

cloud distributed-computing x264 video-encoding прорыв
источник
Все еще работаю над этим. x264farm - это просто менеджер рендеринга, похоже, вы должны иметь возможность разместить любую версию x264 на своих подчиненных компьютерах. Вы пробовали это, и какие ошибки появляются, если вы сделали?
Кек
1
forum.doom9.org/showthread.php?p=1184152#post1184152
Прорыв
1
Я понимаю, что это старая тема, но я думаю, что я должен поделиться своим личным опытом. Не распределяйте одно задание по нескольким машинам, это пустая трата времени, распределение по нескольким ядрам уже снижает производительность, и есть несколько физических процессоров, а затем несколько машин, каждая с проблемой ввода-вывода и задержкой. При этом используйте его, когда это действительно необходимо, если есть несколько файлов (заданий), которые распределяются по файлам, я считаю, что Squeeze может распределять нагрузку на несколько машин, но это довольно дорого.
Шейн Сюй
@ShaneHsu спасибо, что поделились. Впервые я написал этот вопрос более четырех лет назад, и в то время машина, которую я использовал для этой работы, была не такой мощной, как та, что у меня есть сейчас, поэтому тогда было гораздо разумнее идти по этому пути. Сегодня я должен согласиться с вами - если скорость рендеринга становится проблемой, лучше всего перенести всю работу на другую машину, а не разбивать одну работу на несколько частей (и позволить одному экземпляру кодера h.264 позаботиться о нем. любое многопоточное / многоядерное кодирование, если необходимо).
Прорыв
Я собираюсь сделать то же самое, но, к сожалению, похоже, что этот поток в основном заполнен недоделанными решениями или проектами, которые больше не существуют. Похоже, что ваша потребность в этом исчезла, но если у вас есть дополнительная информация о возможных решениях с момента последнего обновления, пожалуйста, дайте мне знать.
Локслию

Ответы:

6

Вы можете визуализировать отдельные фрагменты видео и использовать VirtualDub для сшивания всего вместе с его режимом копирования (где он не кодирует). Это не настоящая распределенная кодировка или что-то еще, но самые простые решения иногда работают лучше всего.

Иван Вучица
источник
5
Опять же, единственная проблема в этом состоит в том, что будет потеря качества из-за размещения кадров I / B при рендеринге видео. Алгоритм обнаружения сцены должен был бы использоваться, чтобы определить, где его разделить, и каким-то образом вам нужно будет разделить видео именно на этот кадр ...
Прорыв
VirtualDub имеет те «зеленые и красные» значки, которые должны использоваться при обнаружении переключателя сцены. Если моя память, созданная несколько лет назад, служит мне правильно, это сработало довольно хорошо. Но опять же, я любитель, когда дело доходит до кодирования видео и видео.
Иван Вучица
AFAIK VirtualDub имеет команду «перейти к следующему кадру». Я бы просто разделил это вручную.
Камило Мартин
@Breakthrough Итак, все, что вам нужно, - это фильтр, который разбивает видеовход на куски на границах смены сцен (чтобы затем их можно было кодировать отдельно)? Это достаточно просто. Есть ли другая проблема?
GroovyDotCom
@GroovyDotCom хорошо в дополнение к этому, все вспомогательное программное обеспечение (например, сервер, чтобы инициировать фильтр разделения, распространить его на все клиентские узлы, на которых работают кодировщики, поставить в очередь задания, перенести файлы обратно на главный сервер и повторно объединить результат) по-прежнему необходимо решать, и это по-прежнему не решает потенциальных проблем качества / эффективности с методом кодирования большого видео в отдельных сегментах. Также обратите внимание, что этому вопросу уже почти шесть лет, поэтому я уверен, что с тех пор многое изменилось и в отношении распределенного кодирования.
Прорыв
4

Это бета, но функционально. Это не так просто, но это работает. Это на базе Windows и бесплатно.

СТАРЕЙШИЙ от некоторых парней Doom9

рыгать
источник
2
Я тоже это видел, но надеялся на что-то сравнимое с x264farm - с x264farm качество не пострадает ... Кроме того, проект был заброшен довольно давно.
Прорыв
1
Первоначально я получил награду в 50 баллов за этот ответ, потому что это было самое близкое решение в то время . Однако эта программа имела некоторые потери качества по сравнению с кодировщиком для одного компьютера. Я надеюсь избежать удара по качеству.
Прорыв
@Breakthrough Что, если вы нацеливаетесь немного выше, например, если это делает его на 10% хуже, а настройки (detail / framesize / etc) на 10% выше?
tobylane
@tobylane, проблема заключается в размещении кадров I / B при рендеринге видео. Чтобы определить, где его разделить, нужно использовать алгоритм обнаружения сцены, и каким-то образом вам нужно будет разделить видео именно на этот кадр. В зависимости от исходного материала это часто невозможно сделать идеально, и, следовательно, кодирование всего видео за один раз обычно дает лучшее качество, чем его рендеринг в виде кусков.
Прорыв
2
@Breakthrough x264 по умолчанию имеет максимальную GOP 250 кадров, а HD материал еще меньше. Когда-нибудь он закроет GOP (если вы не настроите его), и тогда не произойдет потери качества, если вы сделаете щелчок в том месте, где заканчивается GOP, к сожалению, это не очень предсказуемо. В любом случае, в 1,5-часовом фильме, разделив его на 6- 15 минут. куски прямо при смене сцены не сильно повредят сжимаемости. И это помогает!
Камило Мартин
3

Вы также можете попробовать использовать это программное обеспечение для параллельного / распределенного кодирования для Windows, которое работает хорошо и хорошо масштабируется.

Попробуйте поискать в Google для параллельного кодера xcode.

Эти ссылки должны предоставить больше информации.

http://superscalar.pbworks.com/

dxblitzx
источник
Несвязанный: наименования выглядят разорванными прямо из документа Apple Xcode о том, как параллельная компиляция работала с Xgrid. (IDE против видеокодера)
Chealion
ic, я не пользователь Mac, но вы должны попробовать это, работает только на Windows, хотя. У меня есть установка с комбинированной вычислительной мощностью около 10 ГГц, а видео длительностью 90 минут занимает в среднем 30-32 минуты для преобразования (x.264 / AAC / 1800 кбит / с vbr / 256 кбит / с для звука).
dxblitzx
Благодарю за ваш ответ. Я изменил это на текущий правильный ответ, так как это решение наиболее близко к тому, что я искал! :)
Прорыв
2

Для пользователей Final Cut Studio (только Mac), компонент x264 QuickTime работает замечательно хорошо при использовании с кластером, созданным с использованием QMaster. Загрузите ваш фильм в Compressor, и все готово. В тестах я обнаружил приличное увеличение скорости, особенно при работе с общей точкой хранения.

Chealion
источник
3
Блин ... Я пользователь Windows. Это выглядит довольно круто, хотя и похоже на то, что я ищу - просто хотелось бы, чтобы он был мультиплатформенным!
Прорыв
2

Для Mac OS X 10.5 (я не уверен в совместимости для 10.6) раньше использовался VisualHub , который позволял бы вам настроить ферму сетки в вашей локальной сети. Теперь он снят с производства, и ReduxEncoder появился как замена, но я не могу найти варианты для этого.

Тиаго Велосо
источник
2

Я большой поклонник Sony Vegas для редактирования видео в Windows ... и есть функция Network Render. :) вкусняшка

Sony Vegas Workflow

РЕДАКТИРОВАТЬ: Не слишком уверен, если это жизнеспособное решение, но вместо того, чтобы пытаться найти приложение для кодирования видео, которое поддерживает сетевой рендеринг, я попытался найти программное обеспечение, которое позволяет любому приложению использовать преимущества распределенных вычислений. И я нашел это - IAIDataShareServer .

Выглядит довольно мощно, и пример опубликованных результатов действительно великолепен. Если вы собираетесь попробовать, дайте нам знать, как это работает?

EDIT2: IAIDataShareServer, кажется, просто инструктирует машины для выполнения отдельных задач. В этой связи я попытался найти другие решения для распределенных вычислений и перечислил несколько многообещающих.

  1. JPPF
  2. Xoreax
  3. DCEZ (это выглядит хорошо)
Калибан
источник
3
Вы уверены в этом? forums.creativecow.net/thread/24/895788
Прорыв
1
@Breakthrough: эй приятель, новое возможное решение найдено. Хотя сам не проверял. Смотрите отредактированный ответ. Удачи!
калибан
2
@scopedreams: я видел это и сразу же подумал, что это идеально ... К сожалению, этот распределенный общий доступ к данным просто запускает экземпляры программ на каждом подключенном к нему компьютере - полезно для выполнения множества заданий, когда каждый клиент выполняет одно задание за раз ... Но в моем случае я хочу, чтобы на одном компьютере параллельно вычислялась только одна работа.
Прорыв
1
@Breakthrough: черт возьми, назад к тралению в Интернете, я думаю.
калибр
1
@Breakthrough: обновил мой ответ, чтобы предоставить список клиентов распределенных вычислений. Опять не проверено. Не беспокойтесь о принятии моего ответа, я делаю это, чтобы узнать что-то новое для себя тоже. :)
откалиброван
1

простой факт заключается в том, что ни один из разработчиков в мире до сих пор не удосужился написать и отправить распределенные исправления клиент / сервер универсального кодирования TCP: IP / UDP для текущего x264, на сегодняшний день это 1745 см. x264.nl/

общая модель клиент / сервер хорошо понятна, как и чистая кодовая база x264, и запрос разъяснения любого кода x264 - это просто вопрос присоединения к IRC-каналу x264 dev и запроса, в течение нескольких минут у вас обычно будет ключ x264 Dev или два ответят на ваш запрос о том, как работает этот раздел кода, и даже получат практические идеи о том, как вы могли бы переписать свой развивающийся код, чтобы лучше соответствовать x264 (и x262 - новому кодеру Mpeg2, основанному на фреймворке мирового класса x264, над которым все работает сейчас) модель.

Так что если вы разработчик, то самое лучшее, что вы можете сделать для будущего качества и профессии 32/64-битное распределенное кодирование видео x264, - это на самом деле написать эти необходимые базовые патчи клиент / сервер, чтобы сделать один экземпляр x264 или отдельный веб / графический интерфейс. Интерфейс приложения с этим новым кодом API клиент / сервер x264, который вы пишете, для активного поиска, а также назначения и передачи на лету отдельных разделов кодирования одного видео для любого нового соответствующего управляемого кода клиента x264, который вы также пишете.

Ваши новые клиенты / сервер действительно распределенные базовые патчи кодирования даже не должны быть самыми лучшими, просто базовый, но работающий и полностью работающий код C, который тестируется и используется doom10.org/index.php?action=unread

Так как разработчик x264, похоже, любит делать одно, то есть брать существующий медленный код на C и писать оптимизированные его версии, раздел за разделом, но вам нужно сначала представить (приветствовать исправления) фактический бета-код сначала против последний филиал OC

это стоит того, чтобы на него обратить внимание, и на самом деле сегодня он пытается кодировать эти серверы x264 для многих патчей для клиентов x264, поскольку x264 только что получил 10-битную возможность кодирования глубины (что означает высокое качество High, High 10, High 4: 2: 2 H. 264 профилей с интенсивными вычислениями теперь доступны каждому бесплатно с x264).

очень скоро будет оптимизирован для ускорения сборки http://mailman.videolan.org/pipermail/x264-devel/2010-October/007858.html

но даже одна 8-ядерная машина будет изо всех сил пытаться обеспечить высочайшее качество продукции в разумные сроки с разрешением 1080P, а вскоре и 2K и 4K со сверхвысоким разрешением и т. д., очень проста в настройке и использовании распределенная опция стандартного кодирования x264 / H.264. патч или два прочь

если ваш разработчик, ПОЖАЛУЙСТА, не ждите, сделайте это сегодня.

распределенный x264
источник
На самом деле, я думал об этом. Основная проблема заключается не в том, чтобы заставить два компьютера выполнять вычисления, а скорее в передаче данных рабочего набора между машинами. Гораздо проще перемещать данные в ОЗУ и из нее на одной машине (хотя и много гигабайт в секунду), но гораздо медленнее в локальной сети (до 100 мегабайт в секунду).
Прорыв
1

Вы можете взглянуть на Media Encoding Cluster :

Media Encoding Cluster - это первое решение для кодирования с открытым исходным кодом, написанное на C / C ++ для распределенного кодирования медиа (видео и аудио).

Media Encoding Cluster - это расширяемый видеокодер, который использует легкую одноранговую сетку для использования вычислительной мощности обычных ПК с целью распределения кодирования видео с высокой степенью сжатия, например MPEG4 и H.264.

Он распределяет видеоблоки по сети на клиентские узлы и распараллеливает задачу кодирования для одного файла даже по нескольким компьютерам, чтобы сократить время кодирования для каждого файла.

Другой подход предложен для Nvidia по Badaboom ($ 39,99 с судом), также рассмотрен здесь :

Элементаль Badaboom использует интерфейс CUDA от Nvidia, чтобы выполнить большую часть работы по копированию DVD с использованием графического процессора вместо старого процессора.

Аналогичным образом, существует также Avivo Video Converter для ATI Radeon, описанный в википедии , хотя для его работы может потребоваться некоторое усилие.

harrymc
источник
@Breakthrough: вы смотрели на эти продукты?
harrymc
1

Хотя это может показаться излишним, Rhozet Carbon Server может собрать несколько экземпляров Carbon Coder для работы, которую вы описали.

Сайт для Rhozet Carbon Server

Несколько узлов Углеродного кодера могут быть сконфигурированы как ферма транскодирования, управляемая одним или несколькими Углеродными серверами. Carbon Server позволяет автоматизировать обработку задач объемного транскодирования, отработки отказа узлов Carbon Coder, управляемых сервером, а также управлять распределением заданий, назначением приоритетов, балансировкой нагрузки, передачей по FTP, мониторингом состояния и уведомлением о заданиях.

edusysadmin
источник