Как стать автором
Обновить

Комментарии 57

НЛО прилетело и опубликовало эту надпись здесь
Никто не встерчался с ошибкой «No NVENC capable devices found»?
Вроде, моя карточка уже как два поколения должна поддерживать NVENC, но не удалось пока запустить ни один найденый мною пример на аппартаное кодирование видео.
Для начала убедитесь что драйвера установлены.
Я такую ошибку видел когда на голую систему поставил свою сборку ffmpeg, а весь набор с драйверами (7.5.18) забыл установить.

Также стоит посмотреть точно ли ваша карта поддерживает NVENC? Фактически, там только Kepler и Maxwell и все.
Естественно драйвера установлены.
Выхлоп CUDA-z


Поколение Maxwell, вроде nvenc поддерживается на всех kepler и maxwell.
Такая ошибка может быть следствием несовместимого пиксельного формата.
Попробуйте добавить в строку ключ: -pix_fmt yuv420p
По умолчанию ffmpeg проверяет yuv444p.
Для информации используйте
ffmpeg -h encoder=nvenc_h264
или
ffmpeg -h encoder=nvenc_hevc
(https://trac.ffmpeg.org/wiki/HWAccelIntro)
Теперь падает с OpenEncodeSessionEx failed: 0x2. Нагуглил, что вроде как это из-за ограничения в 2 кодирующих потока на систему, но мне и один то не удаётся закодировать :(
ffmpeg -h encoder=nvenc_h264
ffmpeg version 3.0.2 Copyright © 2000-2016 the FFmpeg developers
built with gcc 6.1.1 (GCC) 20160501
configuration: --prefix=/usr --extra-cflags=-I/usr/include/nvidia-sdk --extra-cxxflags='-std=gnu++98' --extra-ldflags='-Wl,-rpath -Wl,/opt/intel/mediasdk/lib64' --enable-rpath --enable-gpl --enable-version3 --enable-nonfree --disable-static --enable-shared --enable-avresample --enable-avisynth --enable-chromaprint --enable-decoder=atrac3 --enable-decoder=atrac3p --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gpl --enable-gray --enable-iconv --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcelt --enable-libdc1394 --enable-libdcadec --enable-libfaac --enable-libfdk-aac --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libilbc --enable-libkvazaar --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopencv --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libutvideo --enable-libv4l2 --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxcb --enable-libxcb-shm --enable-libxcb-xfixes --enable-libxcb-shape --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-netcdf --enable-nvenc --enable-openal --enable-opencl --enable-opengl --enable-openssl --enable-x11grab
libavutil 55. 17.103 / 55. 17.103
libavcodec 57. 24.102 / 57. 24.102
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 31.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
Encoder nvenc_h264 [NVIDIA NVENC h264 encoder]:
General capabilities: delay
Threading capabilities: none
Supported pixel formats: yuv420p nv12 yuv444p
nvenc_h264 AVOptions:
-preset E..V… Set the encoding preset (one of slow = hq 2pass, medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default) (default «medium»)
-profile E..V… Set the encoding profile (high, main, baseline or high444p) (default «main»)
-level E..V… Set the encoding level restriction (auto, 1.0, 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1) (default «auto»)
-tier E..V… Set the encoding tier (main or high) (default «main»)
-cbr E..V… Use cbr encoding mode (default false)
-2pass E..V… Use 2pass encoding mode (default auto)
-gpu E..V… Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from 0 to INT_MAX) (default 0)
-delay E..V… Delays frame output by the given amount of frames. (from 0 to INT_MAX) (default INT_MAX)


ffmpeg -h encoder=nvenc_hevc
ffmpeg version 3.0.2 Copyright © 2000-2016 the FFmpeg developers
built with gcc 6.1.1 (GCC) 20160501
configuration: --prefix=/usr --extra-cflags=-I/usr/include/nvidia-sdk --extra-cxxflags='-std=gnu++98' --extra-ldflags='-Wl,-rpath -Wl,/opt/intel/mediasdk/lib64' --enable-rpath --enable-gpl --enable-version3 --enable-nonfree --disable-static --enable-shared --enable-avresample --enable-avisynth --enable-chromaprint --enable-decoder=atrac3 --enable-decoder=atrac3p --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gpl --enable-gray --enable-iconv --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcelt --enable-libdc1394 --enable-libdcadec --enable-libfaac --enable-libfdk-aac --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libilbc --enable-libkvazaar --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopencv --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libutvideo --enable-libv4l2 --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxcb --enable-libxcb-shm --enable-libxcb-xfixes --enable-libxcb-shape --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-netcdf --enable-nvenc --enable-openal --enable-opencl --enable-opengl --enable-openssl --enable-x11grab
libavutil 55. 17.103 / 55. 17.103
libavcodec 57. 24.102 / 57. 24.102
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 31.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
Encoder nvenc_hevc [NVIDIA NVENC hevc encoder]:
General capabilities: delay
Threading capabilities: none
Supported pixel formats: yuv420p nv12 yuv444p
nvenc_hevc AVOptions:
-preset E..V… Set the encoding preset (one of slow = hq 2pass, medium = hq, fast = hp, hq, hp, bd, ll, llhq, llhp, default) (default «medium»)
-profile E..V… Set the encoding profile (high, main, baseline or high444p) (default «main»)
-level E..V… Set the encoding level restriction (auto, 1.0, 1.0b, 1.1, 1.2, ..., 4.2, 5.0, 5.1) (default «auto»)
-tier E..V… Set the encoding tier (main or high) (default «main»)
-cbr E..V… Use cbr encoding mode (default false)
-2pass E..V… Use 2pass encoding mode (default auto)
-gpu E..V… Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from 0 to INT_MAX) (default 0)
-delay E..V… Delays frame output by the given amount of frames. (from 0 to INT_MAX) (default INT_MAX)
Так вы в линуксе кодируете или под Windows?
Пути /usr/include, /opt/intel, компилятор GCC 6 вас не смутили? Конечно под линуксом.
--disable-static --enable-shared

Вот эти два ключа нам мешали запустить кодирование под CentOS, правда ошибка была другая. Попробуйте собрать статически ffmpeg, авось?

Эта ошибка возникает из-за того, что ffmpeg пытается получить доступ к nvenc который в свою очередь запрашивает ключ дающий право кодирования и вероятно не может. На обычных картах ограничение в 2 потока, а вот на профессиональных картах и GRID — таких ограничений нет. И я не знаю искусственные ли они.
Вот тут выла статья про обход блокировки: https://habrahabr.ru/post/262563/
А вот тут есть гайд по настройке от самой NVIDIA: http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPEG-with-NVIDIA-Acceleration-on-Ubuntu_UG_v01.pdf
Тут еще поступают противоречивые сведения насчет GTX 950 — вроде как это тоже GM206, т.е. та же самая платформа, как и у GTX 960, но такой ли там NVENC модуль? Если кто есть в Минске с GTX 950 — напишите в личку, было бы интересно проверить.
>и только при т.н. pixel хантинге
К сожалению, все еще на «тяжелой» сцене с gpu кодированием (при сопоставимом с cpu вариантом выходном битрейте) видео ряд превращается в развалившуюся картинку размытых блоков.
Если можно, дайте ссылку на такое видео и/или фрагмент и какое битрейт поставить. Можно в личку. Интересно закодировать и взглянуть.
Можно взять хотя бы вот https://www.youtube.com/watch?v=iNJdPyoqt8U (один из 3840x2160) и пережать в 1080p 30fps с битрейтом 6-8 мегабит.
На 2:57 (сцена с деревьями) самая показательная.

Пробовали на quadro, grid, tesla… Скорости хорошие (раза в 2-4 быстре cpu), но качество не понравилось.
А это не самого ютуба артефакты? Подобные кадры даже после заливки в uncompressed будут на ютубе смотреться ужасно
В 4k там все сильно лучше. Из него и перегоняем. Гругие примеры роликов нужно искать, а этот я просто по названию запомнил)
Не, я выразился неправильно. Попробую переформулировать. Подобная картинка превращается в кашу в тех местах, где всё остальное выглядит нормально, но причём здесь GPU/CPU? Ютуб пережимает любое залитое видео в свой формат (в частности указанное видео играется из VP9, ну по крайней мере заявляет об этом, если тыкнуть сведения в проигрывателе), значит не критично чем изначально кодировалось, лишь бы было не хуже среднего по ютубу. С другой стороны зелёный лес и прочая трава обычно требуют большего битрейта для нормальной картинки, значит логично ожидать проблем в таких местах, если битрейт не под них настроен. У вас есть сравнение сжатого GPU/CPU при прочих равных? Мне кажется что разница будет только в скорости кодирования, а качество обусловлено особенностями кодеков, а не тем подключался ли при кодировании GPU.
Так да, я ничего не говорю про то, что у Yt появляется на меньших качествах. Берем с него просто максимальный вариант, у которого проблемная сцена еще нормально смотрится, и сами уже пережимаем через gpu/cpu варианты. И их сравниваем. На ffmpeg с cpu, и на нем же с привлечением gpu. Разница ощутимая по качеству.
А на уже пересжатые примеры можете ссылку дать? Тут вам будут сильно благодарны. Достаточно 5-10 секунд примера, которые можно на какой-нибудь гуглодиск или подобное скинуть.
Могу поискать прошлогодние тесты. Сравнивался чистый cpu вариант на E5-2620 v3 против gpu на grid k1, quadro m6000 и tesla k40.
alexkuzko, AterCattus, Denai, давайте проведем чистый тест.

alexkuzko, вот вам Red Velvet — 행복(Happiness).mov в Apple ProRes yuv422p10le. Давайте вместе попробуем его скодировать «для просмотра в интернете», чтобы выходной размер скодированного видеопотока получился около 100±10 мегабайт, и визуально сравним, у кого что. Готовое видео должно быть в HEVC YUV 4:2:0. Никаких фильтров, кроме преобразования цветового пространства. Ограничений на опции энкодера нет, выставляйте максимально возможное качество.
Я пас, у меня тех тестовых карточек уже год, как нет.
Смотрите что у меня получилось, я с первого подхода так сделал, пока не вытягивал максимум.
сам файл и опции кодирования
Насколько хорошо получилось уже сказать не могу, глаза слипаются. С утра погляжу подробнее. Если по-быстрому, то очень близки с вашим.
Ой, какой плачевный результат, очень надеюсь, что это из-за настроек. Не нужно было так сильно ограничивать битрейт сверху и задавать такой широкий диапазон квантования, а в профиле, вроде как, нужно использовать hq, а не slow (нужно уточнить в справке, ffmpeg -help encoder=nvenc_hevc) Еще, почему-то, предиктор просто отвратительно работает. -g 250 еще добавьте.

Пока что ваш результат на комплексных сценах (вторая сцена с танцами на фоне пальм) хуже ютубовского H.264, который весит примерно столько же (105 мегабайт).
slow = 2pass
hq следующий по качеству
Поменял параметры немного, взгляните еще раз своим орлиным взором и раскритикуйте, не забывая что процессором это кодировалось бы медленнее в 25 раз на Core i7 3.0 (сейчас со скоростью ~0.1x и кодируется там… через час посмотрю что получилось).
На 00:01:34.225, когда по ключевым переключаешь, второй вариант (002/003) намного лучше. Лица уже не так плывут квадратами.
Также я сделал 002 (hq) и 003 (slow) с одинаковыми параметрами (те же ссылки, только вместо mkv — txt) кроме профиля — если вы сможете понять какой из них лучше, будет интересно. Они и про времени близки (slow даже чуть быстрее оказался, чем hq) и по качеству.
У меня исходный файл за полтора часа не скачался, после чего желание отпало совсем, увы. Ну и через CPU на моём компе не менее часа обрабатывалось бы, а на GPU ~2 минуты. На пересжатых файлах ValdikSS и alexkuzko можно мохнатые ручки певиц на свету, что часто не увидеть на том же ютубе, можно на него ссылку тоже добавить, если он есть?
как то искал чем пережать видео, нашел
Sony Vegas Pro
начиная с 11 версии оно умеет видеокарту использовать.
Option->Preferences->GPU acceleretion of video processing->[OFF|ваша_видеокарта] если нет карты, меняйте драйвера на нее, не все драйвера поддерживают кодирование видео.
скорость перекодировки заметно увеличивается.
Да нормальный у Вас процессор, да не новый, но еще полетает! У нас такие в продакшене стоят и творят чудеса.

Приспасибочки за статью и видюшка и железяка под рукой ^_^
Хорошая статья. А с Intel Quick Sync подобное не пробовали?
Интересно было бы сравнить выигрыш в скорости.
Лично я не пробовал. Технология мне в целом нравится, но не нравится позиция Intel.
Они недавно вырезали из SDK поддержку некоторых (да, дешевых и массовых) процессоров и фактически сводят все к тому, что работать технология будет только на серверных чипсетах и процессорах. Почитать можно здесь же на хабре, последняя статья от интела и ссылка на их форум.

А что касается видеокарты — ее можно поставить в любой компьютер. Если проброс PCI устройств работает в гипервизоре, то и на виртуалке можно поднимать когда нужно (сам пока не пробовал т.к. в целом это стезя Quadro — посмотрите на амазоне виртуалки с GPU — и в случае с одиночной картой и специально выделенным компьютером проще напрямую на сервере работать).
У NVENC тоже не всё гладко с поддержкой. На одной версии драйверов работает, на другой ругается что процессор не тот или просто не пишет. Ещё полгода назад у меня работал shadowplay, встроенный в GFexpirience, а сейчас там даже кнопки таковой не вижу. Для записи же сторонним софтом приходится порой драйвера откатывать. Всё под windows, не серверной.
Это не просто стезя Quadro — есть определенный список этих Quadro (описан в документации к драйверу — Maxwell в нем начинается от K2200) — все десктопные и Quadro пониже тоже пробрасываются, но драйвер на них не встает и соответсвенно ничего из описанного не работает.
И соответсвующие 9-й линейке Quadro тоже есть — M2000 (GM206), M4000 и M5000 (GM204) — почему вы считаете что в них какой-то другой NVENC?
Спасибо за комментарий. Я перелопатил гору их документации и запомнились отсылки к тому, что Quadro еще на Kepler. Внесу правку.
Хотя это интересно только технически, реально они очень дорогие и использовать их только для NVENC это как из пушки по воробьям.
Позиция NVidia с тем, что на «дешевых» карточках разрешено одновременно всего 2 потока кодировать чем-то лучше? Причем без внятного определения «дешевых» (дешевые — это все карточки GeForce независимо от цены, и недокументированный список моделей Quadro).
Любые ограничения это зло.
Но одно дело когда ты вообще ничего не можешь, и совсем другое, когда ограничения касаются только проф.использования. Просто для перекодирования хватает и одного потока, второй дает небольшой бонус. Большое количество потоков нужно в первую очередь для ретрансляции.

По второму вопросу, ограничения очень четкие, без привязки к цене:
https://developer.nvidia.com/nvidia-video-codec-sdk — вот тут написано что ограничение на 2 потока касается только Desktop and Mobile Computers, т.е. линейке GeForce.
Не только. Я проверял Quadro K620 — точно так же 2 потока и всё. Видимо, K620 тоже считается Desktop (и официального списка этих моделей я нигде не нашел).
Именно на SDK 6.0? Они в нем исправили проблему с лицензией (что само по себе показывает абсурдность ограничения) и убрали ограничения для тех же K2xxx

Вообще, текущий список для Quadro:
Quadro K2000, K2200, K4000, K4200, K5000, K5200, K6000, M4000, M5000, M6000, and newer
Quadro K2000M, M2000M, K5000M, and newer

Ваша K620 просто старая судя по всему. У нее ведь даже память DDR3, а не GDDR5 (интересно отчего codename у них одинаковый с K2200 — GM107? Но это уже на совести Nvidia).
На последнем SDK 6.0.1 (под Windows). Я не знаю, насколько она старая, но чип внутри, насколько я помню, именно Maxwell. Когда дойдут до нее руки, перепроверю.
В любом случае NVENC SIP там есть, карточка вроде бы как Quadro, но лицензия урэзанная. Этот список не спасает, поскольку это список тех карточек, которые вообще в принципе nvenc умеют (там ниже и GeForce упомянуты, с явным ограничением в 2 сессии). То есть если K620 умеет, то, значит, она в этом списке есть (видимо, newer).

HEVC всё-таки это технология будущего, пока что подавляющее большинство железа ее не тянет (даже на декодировании).
А вот использовать nvenc_h264 — это действительно круто, но с некоторыми ограничениями. Обработка в один поток упирается в CPU на этапе декодирования, при этом nvidia-smi показывает utilization около 10-20% на K1200. Так что добиваться поразительных результатов надо с использованием nvresize и кодированием сразу в несколько качеств. Первый значительно снижает нагрузку на CPU при масштабировании картинки, да еще и распределяет кадры по потокам nvenc, не возвращая их обратно на хост-машину. А насчет нескольких качеств выходит так: исходник h264 1080p преобразуется в набор 240p + 360p + 576p + 720p со скоростью 500-600fps, при этом на GPU utilization encoding и cuda доходит до 100%.


Правда эффективную параллельную обработку запилить не удается, мешает… ffmpeg! Оказывается, filter_complex при его задействовании упирается при переброске фреймов в одно ядро, причем просто на кодировании звука в aac с разными битрейтами. GPU при этом застревает где-то на 200 fps, CPU тоже свободен (кроме одного ядра). Остается вариант с одинаковым аудиопотоком во всех результатах, плюс ухищрения с "-f tee", чтобы раскидать один и тот же аудиопоток по 4 файлам.

Интересная статья. А можно узнать у автора о качестве картинки при перекодировании из исходника 7-8 мегабит 720р в экстремально низкие битрейты данным способом? Например, в видеобитрейт 200к при разрешении 240х192. Или в видеобитрейт 300к 360х288. Или в 660к 504х404.
h264_qsv в этих случаях делает неудовлетворительное качество, картинка периодически рассыпается на квадраты.
Залейте куда-нибудь семпл (источник), то что получилось у вас (интересно же сравнить) с параметрами, и желаемые битрейты, я сделаю и залью. Посмотрите и сравните.
надо бы попробовать на openmcu-ru прикрутить…
Радостно видеть интерес к этой теме со стороны сообщества!
в отличие от оригинальной статьи, где почему-то упустили этот момент, я применил переработанный патч Nvidia Acceleration к FFmpeg 3.0.2, получив помимо энкодера nvenc еще и быстрый фильтр ресайза — nvresize

Первая часть этой статьи была написала в июле 2015го, а внедрение на продакшн состоялось в марте. PDF про описываемый патч датирован ноябрём 2015го года, судя по титульному листу.
Надеюсь вы не в обиде ;) Теперь понятно почему «упустили» — этого просто не было. Если хотите, внесу правку в статью.
Кстати, может вы нашли более человеческий способ убрать ограничение на 2 потока? А свой пробовали с последним SDK?
Не в обиде, конечно. Про правку как пожелаете.

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

С тех пор я стал заниматься уже совсем другим в другом месте и сейчас такого оборудования нет под рукой.

Почему в опросе нет варианта: нет, но собираюсь?

«Хорошая мысля приходит опосля» (с)
Долго думал что выбрать, а про этот вариант совсем забыл. Частично подходит, «Не кодирую видео», т.к. имеется в виду настоящее время.
> гораздо быстрее, чем x265
Это вполне очевидно. Или просто циферкой ошиблись?
Интересно из 5% использующих AMD VCE есть ли те, кто делает это под линуксами?
Очень интересно.
Поделитесь знанием.
Интересно, а хоть кто-то собирал пакет по моей инструкции или все брали уже готовый?
Понадобилось внести небольшие правки (разбирался с особенностями SAR/DAR при кодировании в 720 на 576, Nvidia решила за пользователей что 704 это правильнее...) и обнаружил что патч не применяется т.к. надо менять ctx->outputs[i]->closed на ctx->outputs[i]->status
У меня к последней версии ffmpeg патч nvresize не применился вообще. Но он мне особо и не нужен пока, поэтому я обхожусь без него.
Так он и не должен. Я же говорю про 3.0.2 версию. Уже в ней ctx->outputs был изменен, я точно помню что искал и исправлял, но в патч забыл добавить эту мелочь.

Насчет 3.1, там многое поменялось, поэтому надо переписать измененные процедуры, некоторые вещи вообще из патча можно будет убрать. Идеальным вариантом был бы новый патч от Nvidia, который мы бы переработали. Но ждать его можно год и больше, поэтому я посмотрю что с этим можно сделать в течение месяца.
В идеале, конечно, если бы его в сам ffmpeg приняли уже и далее поддерживали.
Сегодня после некоторых багов с nvresize (залипает при ресайзе с 1920x1080 в PAL — причем только на некоторых файлах и, что удивительно (мистика!), даже перекодировав исходный файл с помощью x264, не получается закодировать именно эти файлы — 4 из 52 серий одного сериала) решил поглядеть стоит ли перейти на SDK 8 и ffmpeg 3.2 — и нашел интересные примеры на странице https://developer.nvidia.com/ffmpeg — там для скейла почему-то использован scale_npp, а не свой же nvresize, про который сказано на этой же странице… Это ж-ж-ж-ж неспроста! (с)
Ну видно NPP более универсальный, нет смысла поддерживать отдельную библиотеку для ресайза, а так — общий код для всех.
То есть, NPP — Nvidia Performance Primitives.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории