Я читал эту статью и увидел, что процессор лучше для сжатия видео, чем графический процессор.
В статье говорится, что это происходит только потому, что процессор может обрабатывать более сложные алгоритмы, чем графический процессор, но я хочу получить более подробное техническое объяснение, я провел поиск в Интернете, но ничего не нашел.
Итак, кто-нибудь знает, чтобы объяснить или связать сайт, чтобы у меня было более глубокое объяснение этого?
Ссылка на статью не очень хорошая.
Обычно, однопроходные кодировки битрейта преобразуют ваш битрейт в значение RF с максимальным пределом битрейта и принимают его оттуда.
Однопроходное управление скоростью ABR в x264 не реализовано как ограничение CRF +. Однако он прав, что 2pass - лучший способ достичь заданного битрейта.
И он, видимо, не понимает, что может запустить x264 с потоками = 3 или чем-то еще, чтобы освободить некоторое время процессора для других задач. Или установите приоритет x264 на очень низкий, чтобы он получал только время процессора, которое не требуется ни одной другой задаче.
Он также смешивает потоки = 1 с использованием CUDA или чего-то еще. Неудивительно, что у вас есть вопросы, потому что эта статья имеет ужасное объяснение. Вся статья в основном сводится к: использовать x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvили, возможно, использовать некоторую фильтрацию света с входным скриптом AviSynth. Он на самом деле рекомендует "плацебо". Это весело. Я никогда не видел пиратский файл, закодированный плацебо. (Вы можете сказать от me=esaили me=tesa, вместо me=umhвсех пресетов хорошего качества, вплоть до veryslow.
Он также не упоминает использование 10-битной глубины цвета. Медленнее кодировать и декодировать, но даже после обратного преобразования обратно в 8-битный, вы получаете лучший 8-битный SSIM. Очевидно, помогает наличие большей точности для векторов движения. Также помогает отсутствие округления до целого 8-битного значения. Вы можете думать о 8-битном для каждого компонента как о скорости взлома; квантование в частотной области и последующее сжатие с помощью CABAC означает, что более высокие коэффициенты глубины в битах не должны занимать больше места.
(Кстати, h.265 получает меньше преимуществ от 10-битного кодирования для 8-битного видео, потому что оно уже имеет большую точность для векторов движения. Если есть преимущество в использовании 10-битного x265 для 8-битных видеовходов, оно меньше, чем с x264. Так что менее вероятно, что штраф за скорость того стоит.)
edit: doom9 снова работает, поэтому я приведу в порядок ссылку. Перейти к нему для правильного цитирования, кто сказал, что.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
Google кэширует только глупую версию для печати, которая не отображает цитирование должным образом. Я не совсем уверен, какие части этих сообщений являются цитатами, а какие приписаны самому человеку.
Сильно нерегулярные шаблоны ветвления (режимы пропуска) и манипулирование битами (квантование / энтропийное кодирование) не подходят для современных графических процессоров. IMO единственное действительно хорошее приложение на данный момент - алгоритмы полного поиска ME, в конце концов, хотя ускоренный полный поиск все еще медленный, даже если он быстрее, чем на процессоре.
- МФАНа самом деле, в принципе, все может быть разумно сделано на GPU, кроме CABAC (что может быть сделано, его просто нельзя распараллелить).
x264 CUDA будет изначально реализовывать алгоритм fullpel и subpel ME; позже мы могли бы сделать что-то вроде RDO с приближением битовой стоимости вместо CABAC.
Потому что он должен делать все с плавающей точкой одинарной точности
- MfAНеправильно, CUDA поддерживает целочисленную математику.
- Темный Шикари
Dark Shikari - сопровождающий x264 и разработчик большинства функций с 2007 года или около того.
AFAIK, этот проект CUDA не удался. Существует поддержка использования OpenCL для разгрузки некоторой работы из потока прогнозирования (быстрое решение I / P / B, а не высококачественное окончательное кодирование кадра).
Насколько я понимаю , пространство поиска для кодирования видео настолько велико, что интеллектуальная эвристика для досрочного завершения путей поиска на процессорах превосходит возможности графических процессоров перебором, по крайней мере, для кодирования высокого качества. Это только по сравнению с тем, -preset ultrafastгде вы могли бы разумно выбрать HW-кодирование вместо x264, особенно. если у вас медленный процессор (например, ноутбук с двухъядерным процессором и без гиперпоточности). На быстром процессоре (четырехъядерный процессор i7 с гиперпоточностью) x264 superfast, вероятно, будет таким же быстрым и выглядит лучше (с той же скоростью передачи битов).
Если вы делаете кодирование, где искажение скорости (качество на размер файла) имеет значение вообще, вы должны использовать x264 -preset mediumили медленнее. Если вы что-то архивируете, потратив немного больше процессорного времени, вы сэкономите байты, пока храните этот файл.
примечание: если вы когда-нибудь увидите сообщения от тупиков на видеофоруме, это не поможет. Он был неправ в отношении большинства вещей, о которых он говорит в каждой теме, которую я когда-либо видел. Его сообщения появились в нескольких потоках, которые я гуглил о кодировке x264 GPU. Видимо, он не понимает, почему это нелегко, и несколько раз писал, чтобы рассказать разработчикам x264, почему они глупы ...
Обновление 2017 года:
ffmpeg поддерживает кодирование видео h264 и h265 NVENC с GPU-ускорением . Вы можете выполнить 1-проходное или 2-проходное кодирование с выбранным качеством для hevc_nvenc или h264_nvenc, или даже с GPU начального уровня это намного быстрее, чем неускоренное кодирование и ускоренное кодирование Intel Quick Sync.
2-х проходное качественное кодирование:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4
1-проходная кодировка по умолчанию:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4
NVENC ffmpeg справка и опции:
ffmpeg -h encoder=nvenc
Используйте это, это намного быстрее, чем кодирование процессора.
Если у вас нет графического процессора, вы можете использовать кодек Intel Quick Sync, h264_qsv, hevc_qsv или mpeg2_qsv, которые также намного быстрее, чем неускоренное кодирование.
-c:v libx264 -preset slower(что не так уж медленно, как в режиме реального времени для 1920x1080p24 на Skylake i7-6700k.)ffmpegс-vcodec h264_qsvмоим старым ноутбуком Intel с Intel HD Grpahics 4000 сделало рендеринг намного быстрее!Чтобы более подробно остановиться на том, что говорит Питер, в целом использование нескольких процессоров помогает в тех случаях, когда у вас есть несколько независимых задач, которые все должны быть выполнены, но не имеют зависимостей друг от друга, или одна задача, когда вы выполняете одно и то же математика на огромных объемах данных.
Если, однако, вам нужен вывод вычисления A в качестве ввода вычисления B, а вывод вычисления B в качестве ввода в расчет C, то вы не можете ускорить его, имея разные основные работы над каждой задачей ( A, B или C), потому что один не может начать, пока не закончится другой.
Однако даже в приведенном выше случае вы сможете распараллелить его другим способом. Если вы можете разбить свои входные данные на куски, у вас может быть одно ядро, выполняющее A, затем B, затем C с одним блоком данных, в то время как другое ядро работает над A, затем B, затем C на другом фрагменте данных. ,
Есть и другие соображения. Возможно, вы могли бы найти способ распараллелить вычисления, но простое считывание данных с диска или по сети или отправка их в графический процессор займет больше времени, чем выполнение вычислений. В этом случае не имеет смысла распараллеливать его, потому что простое получение данных в память занимает больше времени, чем вы экономите, выполняя вычисления параллельно.
Другими словами, это столько же искусство, сколько и наука.
источник