Можно ли использовать графический процессор для кодирования h264?

Мне интересно, получу ли я лучшую видеокарту, может ли она ускорить кодирование h264 на моем компьютере с помощью ручного тормоза?

Если так, как я могу сказать, какая видеокарта будет поддерживать это?

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

С помощью ручного тормоза ответ будет отрицательным. Handbrake - это кодер h.264 только для процессора, хотя теперь он может использовать OpenCL для масштабирования видео и имеет некоторую поддержку DXVA для декодирования видео.

В вопросе, связанном с slhck, упоминается MediaCoder , но для этого требуется либо видеокарта Nvidia, либо процессор Intel с графическим ядром 2-го поколения.

Есть несколько устаревших продуктов, в частности, Badaboom и программное обеспечение ATi Avivo.

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

У ATi был свой собственный видеокодер, который раньше назывался «Avivo», прежде чем был включен в пакет кодеков AMD, который включал в себя видео конвертер AMD, хотя он больше не доступен.

x264 теперь поддерживает ускорение кодирования OpenCL. Какое ускорение вы получите, будет зависеть от производительности вашей видеокарты, от моего GTS 450 я не получаю, а с более медленными картами это фактически замедляет кодирование. Лучшие карты могут помочь. Все, что вам нужно сделать, это добавить --opencl в командную строку x264. Я считаю, что ручной тормоз использует те же библиотеки x264 и предлагает то же ускорение OpenCL в новых сборках.

https://trac.ffmpeg.org/wiki/HWAccelIntro

FFmpeg предоставляет подсистему для аппаратного ускорения.

Аппаратное ускорение позволяет использовать определенные устройства (обычно графические карты> или другие конкретные устройства) для выполнения обработки мультимедиа. Это позволяет использовать выделенное оборудование для выполнения сложных вычислений, освобождая при этом процессор от таких вычислений. Обычно аппаратное ускорение позволяет определенным аппаратным устройствам (обычно графическим процессорам) выполнять операции, связанные с декодированием и кодированием видеопотоков или фильтрацией видео.

При использовании инструмента FFmpeg, HW-ассистированное декодирование включается с помощью -hwaccelопции, которая включает определенный декодер. Каждый декодер может иметь определенные ограничения (например, декодер H.264 может поддерживать только базовый профиль). HW-ассистированное кодирование включается с помощью специального кодера (например, nvenc_h264). Фильтрация Обработка с помощью HW поддерживается только в нескольких фильтрах, и в этом случае вы включаете код OpenCL с помощью параметра фильтра.

Существует несколько стандартов API аппаратного ускорения, некоторые из которых в некоторой степени поддерживаются FFmpeg.

Параметр «-hwaccel auto» позволяет выбрать аппаратное ускоренное декодирование, которое будет использоваться для сеанса кодирования. Вы можете добавить этот параметр с помощью «auto» перед вводом (если ваш x264 скомпилирован с поддержкой OpenCL, вы можете попробовать добавить параметр -x264opts), например:

ffmpeg -hwaccel auto -i input -vcodec libx264 -x264opts opencl output

Извините, но я не могу вспомнить, как перечислить все доступные опции для "-hwaccel".

Также вы можете попробовать это: https://wiki.archlinux.org/index.php/Hardware_video_acceleration

В настоящее время Handbrake поддерживает следующие кодеры с аппаратным ускорением для H.264 / AVC:

1. Intel QuickSync (в Windows и в Linux). Это совместимо, по крайней мере, с процессорами Intel серии Sandybridge (Core 2-го поколения) с интегрированной графикой, включенной и доступной для операционной системы. Рекомендуемое аппаратное обеспечение для приемлемого качества кодирования: Haswell (серия Core 4-го поколения) и выше, в котором была представлена ​​концепция детализированных целевых уровней (TU), функций прогнозирования (таких как режимы кодирования LA-BRC и ICQ ) со значительно лучшей производительностью. Смотрите руководство по использованию документации ручного тормоза здесь .

2. NVIDIA NVENC : для этого требуются как минимум графические процессоры NVIDIA серии Kepler (GK +) и выше от высокопроизводительных потребительских SKU (серии GTX) и профессиональных линейок (графические процессоры Quadro и Tesla на базе Kepler и выше). Это доступно как в Windows, так и в Linux.

Следует отметить, что с NVENC вы будете искусственно ограничены максимум двумя одновременными сеансами кодирования на потребительских SKU, тогда как на профессиональный состав это не повлияет. Для получения информации о конкретных возможностях кодера см. Матрицу графического процессора . Для лучшей производительности и качества кодера придерживайтесь последней итерации графических процессоров Pascal и Volta .

Необязательно:

3. Поддержка кодировки AMD AMF также доступна в текущих ночных сборках ТОЛЬКО для Windows. Особое примечание по поводу AMF AMD (которое подключается к кодировщику VCE, встроенному в аппаратное обеспечение во всех SKU GCN + ) заключается в том, что на более новом оборудовании, таком как Polaris (серия RX 400+) и Vega , некоторые усовершенствованные настройки кодировщика для H.264 / AVC были объявлены устаревшими, поскольку они представили поддержку кодирования HEVC. AMD отказалась от B-кадрового кодирования без поддержки адаптивного квантования (AQ), функции, которую вышеупомянутые аппаратные кодеры (QuickSync и NVENC) внедряли в поколениях без регрессий. Также смотрите это в примечаниях, касающихся показателей пропускной способности и того, что ожидать.

Что касается поддержки Apple, это в лучшем случае ориентировочно . VideoToolBox API, где реализован за рамки Handbrake, также , кажется, имеет очень ограниченный набор элементов управления. Даже если Handbrake примет его в апстриме, не ожидайте чудес с точки зрения сохранения качества и пропускной способности.

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