Comments 26
Я в питоне не особо разбираюсь, но статью оценил. Спасибо, может пригодиться.
UFO just landed and posted this here
Ждём статью об ускорении кодирования видеопотока :)
Могу сразу сказать, что libx264 и libx265 грузят ЦП на 100%, то есть они без лишних просьб используют все потоки. Аппаратное ускорение они не поддерживают. Кодеры *_qsv работают. (Наверное и их аналоги от Nvidia.) Главная проблема в том, что для кодеров используют большое число параметров, которые влияют на скорость кодирования и надо перебирать все комбинации, так, что подобные таблицы могут быть огромными. Даже если использовать только пресеты (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow), все равно будет очень много данных.
Статья не раскрывает ничего, ни патченых драйверов под многопоточный encoder для Nvidia, ни того, как собирать или где добывать ffmpeg с поддержкой кодирования на radeon-ах. Ни того, что аппаратное ускорение можно применять не только для encoder-ов, но, и для decoder-ов, что тоже ускоряет общее время обработки.
Статья вообще-то полностью про декодер, если я ничего не пропустил…
Статья как раз про декодеры. Исторически сложилось так, что всю жизнь сидел на Intel. С NVIDIA также работал мало. А вот с продукцией AMD практически не имел дела. Про поддержку Radeon в ffmeg вообще не слышал, специально не искал, так как эта поддержка для меня не актуальна.
Дочитал до i5 8400 и сразу понял вашу проблему. При упоминании HWAccel стоит сразу же оговориться, что оно несёт собой просто тонну проблем и ограничений по входным данным. Размер кадра, битрейт, FPS, уровень и профиль кодека, которым кодировались данные. Все это жёстко ограничивает возможности встроенного в чип ВК аппаратного декодера (ASIC) по количеству поддерживаемых форматов. На днях тестировал декодер 5700xt, где завезли поддержку аж всего и аж в 8k сразу. Во всех тестах r5 3600x оказался быстрее в декодировании, просто в разы. Сегодня, когда zen 2 продается по 5 рублей за кило, лучше даже и не вспоминать про аппаратный декодер.
Он не придумывался для ускорения декодирования видео, он придумывался в качестве очередной энергосберегайки и как замена слабомощным процессорам, а все остальное просто маркетинговый булшит. Да несомненно, в той же 5700xt завезли и аппаратный кодер, но это случилось только «вчера» и ни где никакой поддержки ещё нет, кроме драйвера AMD, который будет кодировать видео с экрана на лету, не напрягая ВК и процессор особо, в ответ на shadow play от зелёных. Вот как-то так пока обстоят дела на сегодняшний и получается, что для этих задач и проще и удобнее использовать процессор. Особенно, когда AMD ударилась в ядра. А у аппаратного декодера всегда есть потолок, например по fps, выше которого он физически не прыгнет. Алсо, когда в последний раз интересовался cuda декодером, он был скорее мертв, чем жив судя по его возможностям. По работе мне надо уметь держать воспроизведение видео любых форматов любого разрешения, в том числе и нестандартных, например 4096х4096, 3600х3600, фишай, а уж 360 видео в равнопромежуточной проекции имеет кучу нестандартных соотношений сторон. Так что к теме имею прямое отношение.
Он не придумывался для ускорения декодирования видео, он придумывался в качестве очередной энергосберегайки и как замена слабомощным процессорам, а все остальное просто маркетинговый булшит. Да несомненно, в той же 5700xt завезли и аппаратный кодер, но это случилось только «вчера» и ни где никакой поддержки ещё нет, кроме драйвера AMD, который будет кодировать видео с экрана на лету, не напрягая ВК и процессор особо, в ответ на shadow play от зелёных. Вот как-то так пока обстоят дела на сегодняшний и получается, что для этих задач и проще и удобнее использовать процессор. Особенно, когда AMD ударилась в ядра. А у аппаратного декодера всегда есть потолок, например по fps, выше которого он физически не прыгнет. Алсо, когда в последний раз интересовался cuda декодером, он был скорее мертв, чем жив судя по его возможностям. По работе мне надо уметь держать воспроизведение видео любых форматов любого разрешения, в том числе и нестандартных, например 4096х4096, 3600х3600, фишай, а уж 360 видео в равнопромежуточной проекции имеет кучу нестандартных соотношений сторон. Так что к теме имею прямое отношение.
UFO just landed and posted this here
Спасибо! Очень интересная информация. Исторически сложилось так, что я всю жизнь сидел на Intel (да и сейчас сижу). Было бы очень интересно пощупать AMD, но в обозримом будущем наверное не получится (хоть они и 5 рублей за кило).
Сегодня, когда zen 2 продается по 5 рублей за кило, лучше даже и не вспоминать про аппаратный декодер
Про аппаратный декодер придется вспомнить, если у вас компания занимается стримингом и имеет собственные сервера для транскодинга. В свое время мы использовали серверные процессоры Intel для этой цели. Если использовать программный декодер, то уменьшается количество каналов, которые можно транскодировать одновременно в разные качества. Наиболее оптимальный вариант — когда транскодинг полностью аппаратный и не происходит копирование в системную память после декодера, а поверхность сразу отправляется в энкодер. На одном таком сервере за счет встроенного GPU удавалось ускорить процесс в 5-6 раз, как и количество каналов. Это вообще критично может быть, учитывая стоимость одного сервера.
А у аппаратного декодера всегда есть потолок, например по fps, выше которого он физически не прыгнет
Этот потолок часто ограничен только пропускной способностью памяти и бывает 200-500 fps в зависимости от разрешения картинки. Если сервер обрабатывает много потоков это может быть критично.
Киношку по названию можно найти на YouTube:
А ведь это даже не серверный процессор, да и ffmpeg не последний… Хотелось бы увидеть результат qsv… А вот у радеона в спеках числится как раз поддержка декодирования 4k AVC на 150fps максимально. И при декодировании этого ролика ASIC загружен на 100%. Диспетчер задач — GPU — Video Encode (ей богу не знаю почему они засунули этот показатель в encode). Но это его потолок. На карточках NV всегда отображается в графике Video Decode.
ps Киношку перезалили вроде как только в 60fps теперь доступна…
Video: h264 (High) (avc1 / 0x31637661), yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], 18005 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default)
R5 3600x:
ffmpeg -threads auto -i "f:\Films\COSTA RICA IN 4K 30fps (ULTRA HD) w Freefly Movi.mp4" -f null - -benchmark
frame= 5111 fps=482 q=-0.0 size=N/A time=00:02:50.94 bitrate=N/A speed=16.1x
Radeon 5700xt:
ffmpeg -hwaccel dxva2 -threads 1 -i "f:\Films\COSTA RICA IN 4K 30fps (ULTRA HD) w Freefly Movi.mp4" -f null - -benchmark
frame= 1267 fps=148 q=-0.0 size=N/A time=00:00:42.28 bitrate=N/A speed=4.94xА ведь это даже не серверный процессор, да и ffmpeg не последний… Хотелось бы увидеть результат qsv… А вот у радеона в спеках числится как раз поддержка декодирования 4k AVC на 150fps максимально. И при декодировании этого ролика ASIC загружен на 100%. Диспетчер задач — GPU — Video Encode (ей богу не знаю почему они засунули этот показатель в encode). Но это его потолок. На карточках NV всегда отображается в графике Video Decode.
ps Киношку перезалили вроде как только в 60fps теперь доступна…
Video: h264 (High) (avc1 / 0x31637661), yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], 13993 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
i7-8700
Geforce RTX 2080:
У меня, правда битрейт меньше исходника, я сам жал в h264
i7-8700
ffmpeg -threads auto -i costa-rica_h264.mp4 -f null - -benchmark
frame= 9246 fps=245 q=-0.0 Lsize=N/A time=00:05:08.50 bitrate=N/A speed=8.18xGeforce RTX 2080:
ffmpeg -hwaccel vdpau -threads 1 -i costa-rica_h264.mp4 -f null - -benchmark
frame= 9246 fps=198 q=-0.0 Lsize=N/A time=00:05:08.50 bitrate=N/A speed=6.59xУ меня, правда битрейт меньше исходника, я сам жал в h264
А ffmpeg -hwaccel qsv… что говорит?
trac.ffmpeg.org/wiki/Hardware/QuickSync Тут вроде как установка и сборка… Если оно еще не на перманентной основе вшито в ffmpeg.
ps При выходе за пределы возможностей аппаратного декодера на 5700xt в данный момент, кстати, падает драйвер. Ну скажем видео 8k не 24 фпс максимум, а 30. А должен сваливаться в софтварный декод. Чего-то там не доделали пока индусы из AMD…
trac.ffmpeg.org/wiki/Hardware/QuickSync Тут вроде как установка и сборка… Если оно еще не на перманентной основе вшито в ffmpeg.
ps При выходе за пределы возможностей аппаратного декодера на 5700xt в данный момент, кстати, падает драйвер. Ну скажем видео 8k не 24 фпс максимум, а 30. А должен сваливаться в софтварный декод. Чего-то там не доделали пока индусы из AMD…
И при декодировании этого ролика ASIC загружен на 100%
ASIC ускоряет, как правило, такие операции как арифметическое кодирование и iDCT, остальное, например, Motion estimation, в зависимости от реализации, может выполняться на блоках общего назначения или даже CPU.
Хотелось бы увидеть результат qsv
У меня получался результат в 6-10 раз быстрее (Haswell, Broadwell, SkyLake), но для получения такого результата нужно использовать непосредственно Intel Media SDK без ffmpeg
Запустил свой ролик (тот же, что и данные в статье)
Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 30.30 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
ffmpeg -c:v h264_qsv -i INPUT -f null — -benchmark
на выходе
frame= 2241 fps=129 q=-0.0 Lsize=N/A time=00:01:14.77 bitrate=N/A speed=4.3x
Загрузка ЦП — 35%, графический процессор — 80%
Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 30.30 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
ffmpeg -c:v h264_qsv -i INPUT -f null — -benchmark
на выходе
frame= 2241 fps=129 q=-0.0 Lsize=N/A time=00:01:14.77 bitrate=N/A speed=4.3x
Загрузка ЦП — 35%, графический процессор — 80%
Сам недавно кстати эксперементировал с ffmpeg на ноутбуке с двумя видеокартами (uhd630+1050ti), жал видео в h264. Лучший по скорости результат показал h264_nvenc, чуть медленнее но качественнее сжал h264_qsv, самый медленный но самый качественный результат дал libx264, но проц напрягся под сотку, от чего грелся и шумел. Самое любопытное то, что мне удалось запустить две копии ffmpeg и жать одновременно двумя аппаратными кодеками qsv и nvenc два разных видеофайла (в диспетчере задач четко было видно загруженность обоих видеокарт). Смысла в этом конечно мало, разве что сериал так пожать получиться быстрее, но вот увы, жать один видеофайл двумя аппаратными видеокодеками нельзя. Больше всех удивил qsv — жмет быстро, но при этом проц почти не нагружен и по температурам все хорошо, можно поставить например жать сериал и в этот момент полноценно пользоваться ноутбуком.
Спасибо за интересную информацию. Ну вообще-то параллельная работа двух разных видеокарт достаточно ожидаема, было бы очень странно, если б они мешали друг другу. А такой режим может оказаться актуальным, если надо параллельно обрабатывать несколько 4K потоков.
Я однажды поставил себе задачу: нужно сжать было сериал, чтобы смотреть его на телефоне. Цена вопроса: сжать чтобы мало занимал места, но при этом не сильно чтобы в ущерб качеству. Перепробовав тонну кодировщиков, в том числе и онлайн, я остановился именно на ffmpeg, но пожелав для себя сделать работу с ним максимально комфортной, я воспользовался весьма приятным GUI под названием WinFF.
Начал настраивать под себя пресеты, в итоге сделал свой пресет:
Качество картинки остается весьма приятная глазу на телефоне, звук жмется до стерео, в AAC с битрейтом 64к, что дает малый размер, качества звука вполне хватает для просмотра на телефоне. Все это сжиматься весьма на приличной скорости.
Что касаеться nvenc, то пресет немного разниться:
Почему то nvenc + ffmpeg не могут жать с пресетом veryslow, из за чего страдает размер и качество, можно лишь минимум slow, звук жмется аналогично. Это собственно одна из причин выбора именно в пользу QSV
Начал настраивать под себя пресеты, в итоге сделал свой пресет:
-vcodec h264_qsv -global_quality 25 -preset veryslow -profile high -vf format=nv12 -b:a 64k -ac 2
Качество картинки остается весьма приятная глазу на телефоне, звук жмется до стерео, в AAC с битрейтом 64к, что дает малый размер, качества звука вполне хватает для просмотра на телефоне. Все это сжиматься весьма на приличной скорости.
Что касаеться nvenc, то пресет немного разниться:
-vcodec h264_nvenc -global_quality 25 -preset slow -profile high -vf format=nv12 -b:a 64k -ac 2
Почему то nvenc + ffmpeg не могут жать с пресетом veryslow, из за чего страдает размер и качество, можно лишь минимум slow, звук жмется аналогично. Это собственно одна из причин выбора именно в пользу QSV
Sign up to leave a comment.
Как повысить скорость декодирования видеопотока в FFmpeg