Проведенный нами тест NVIDIA A4000 почти подтвердил, что она способна вытянуть на энкодинге до 16 независимых видеопотоков FullHD в формате H264. Удастся ли кратно увеличить производительность с профессиональной видеокартой, которая стоит в два раза дороже? Попробуем проверить.

В нашей второй статье про энкодинг (с тестом А4000) мы упустили, что видеопоток бывает и большего разрешения, поэтому стоит протестировать энкодинг файлов в формате 4К. Для полноты картины мы также сравним энкодинг на решениях от NVIDIA с встроенным GPU от Intel. Некоторые профессионалы полагают, будто достаточно собрать тот же FFmpeg с включенным QuickSync и внешняя видеокарта станет не нужна. Проверим и это утверждение.

Мы не будем подробно расписывать процесс тестирования для видеокарт от NVIDIA и зачем нам FFmpeg, поскольку информация об этом есть в предыдущих статьях (первая и вторая части). Лучше сосредоточимся на новых результатах и полезных лайфхаках.

A4000 vs A5000

Используем тот же самый тестовый стенд из имеющихся в наличии серверов HOSTKEY, но установим в него видеокарту NVIDIA A5000 с большим количеством блоков энкодинга, 24 ГБ видеопамяти и более высоким энергопотреблением.

Для начала проверим ее работу на количестве потоков, оказавшемся предельным для А4000 по результатам предыдущего теста:

14 потоков

gpu

pwr

gtemp

mtemp

sm

mem

enc

dec

mclk

pclk

fb

bar1

Idx

W

C

C

%

%

%

%

MHz

MHz

MB

MB

0

97

47

-

92

3

100

0

7600

1920

3502

33

frame=1015 fps=31 q=28.0 Lsize= 9056kB time=00:00:33.80 bitrate=2194.8kbits/s speed=1.02x

Удивительно! Мы получили сравнимые с результатом A4000 цифры. Несмотря на большую частоту работы чипа, больший объем используемой видеопамяти и большее энергопотребление, A5000 осилила энкодинг только 14 потоков и спасовала на пятнадцатом. Это фиаско еще раз доказывает, что профессиональные видеоадаптеры предназначены для других целей.

Включаем 4K

Теперь попробуем запустить трансляцию потока с разрешением 3840x2160 (оно же 4K), благо есть и такая версия файла про кролика. Энкодинг силами только центрального процессора захлебнулся уже на одном потоке, когда объем данных кратно увеличился:

frame= 2902 fps=27 q=29.0 size=104448kB time=00:01:33.56 bitrate=9144.7kbits/s dup=436 drop=0 speed=0.878x

Каковы возможности GPU (помним, результаты у A4000 и A5000 сравнимы)? Это 3 потока. 

gpu

pwr

gtemp

mtemp

sm

mem

enc

dec

mclk

pclk

fb

bar1

Idx

W

C

C

%

%

%

%

MHz

MHz

MB

MB

0

96

46

-

100

3

96

0

7600

1920

1112

9


Как видим, по потребляемой мощности и загрузке блоков энкодинга видеочип работает явно не в режиме повышенного комфорта, хотя при этом расходуется лишь около 1 ГБ видеопамяти.

Вывод FFmpeg подтверждает, что видеокарта справляется:

frame= 1465 fps=33 q=35.0 Lsize=12584kB time=00:00:48.80 bitrate=2112.4kbits/s dup=159 drop=0 speed=1.09x

А вот 4 потока адаптер уже не переваривает. Хотя загрузка железа остается примерно на тех же значениях, начинаются просадки по кадрам:

frame=  614 fps= 26 q=35.0 Lsize=4978kB time=00:00:20.43 bitrate=1995.6kbits/s speed=0.858x

Сборка FFmpeg с поддержкой QuickSync

Если верить заявлению компании-разработчика, технология QuickSync должна «используя специальные возможности обработки мультимедийных данных графических технологий Intel® для ускорения декодирования и кодирования, позволить процессору параллельно выполнять другие задачи и повышая быстродействие системы».

Для тестов понадобился подходящий процессор Intel (мы нашли машину с Core i9-9900K CPU @ 3.60GHz) и собранная с поддержкой Quick Sync утилита FFmpeg. С первым проблем не возникло (достаточно чипа старше 6-го поколения и наличия в нем GPU, что несложно проверить), но сборка FFmpeg под тестовую Ubuntu 20.04 вызвала стойкие ассоциации с практическим освоением Камасутры. Чтобы не заставлять вас тратить драгоценное время, опишем, как нам удалось решить проблему.

Поскольку пакеты в репозиториях сломаны, первым делом нужно собрать и установить в систему библиотеки gmmlib и libva, а также последние версии Intel media driver и Media SDK. Для этого в домашней директории создадим папку GIT, зайдем в нее и выполним последовательно следующие команды (если будет не хватать каких-то зависимостей, установим их из репозитория; мы рекомендуем сделать sudo apt install autoconf automake build-essential cmake pkg-config):

git clone https://github.com/intel/gmmlib.git && cd gmmlib
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu ..
make -j8
sudo make install

git clone https://github.com/intel/libva.git && cd libva
./autogen.sh --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu 
make -j8
sudo make install

git clone https://github.com/intel/media-driver.git && cd media-driver
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu ..
make -j8
sudo make install

git clone https://github.com/Intel-Media-SDK/MediaSDK.git && cd MediaSDK
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu ..
make -j8
sudo make install

Затем нужно собрать FFmpeg с помощью нескольких магических команд:

git clone https://github.com/ffmpeg/ffmpeg
cd ffmpeg
./configure --enable-libmfx --enable-vaapi --enable-opencl --enable-libvorbis --enable-libvpx --enable-libdrm --enable-gpl --cpu=native --enable-libfdk-aac --enable-libx264 --enable-libx265 --extra-libs=-lpthread --enable-nonfree
make -j8
sudo make install

Стоит убедиться, что у нас появилась поддержка Quick Sync:

ffmpeg -decoders|grep qsv

Вывод команды должен быть примерно таким:

V....D av1_qsv              AV1 video (Intel Quick Sync Video acceleration) (codec av1)
V....D h264_qsv             H264 video (Intel Quick Sync Video acceleration) (codec h264)
V....D hevc_qsv             HEVC video (Intel Quick Sync Video acceleration) (codec hevc)
V....D mjpeg_qsv            MJPEG video (Intel Quick Sync Video acceleration) (codec mjpeg)
V....D mpeg2_qsv            MPEG2VIDEO video (Intel Quick Sync Video acceleration) (codec mpeg2video)
V....D vc1_qsv              VC1 video (Intel Quick Sync Video acceleration) (codec vc1)
V....D vp8_qsv              VP8 video (Intel Quick Sync Video acceleration) (codec vp8)
V....D vp9_qsv              VP9 video (Intel Quick Sync Video acceleration) (codec vp9)

Ура! Все готово к тестам.

Тестирование энкодинга с Quick Sync

Для начала проверим, как справляется с энкодингом видео в FullHD процессор без Quick Sync: он выдерживает максимум 4 потока, при которых все ядра загружены под 100%


frame= 1461 fps= 33 q=29.0 size=24064kB time=00:00:46.33 bitrate=4254.7kbits/s speed=1.05x

Пятый поток процессор уже не осиливает, поэтому можно смело приступать к тесту с Quick Sync. В скрипте из предыдущей статьи для этого нужно будет заменить энкодер на h264_qsv, и он примет следующий вид (подробнее об использовании QuickSync с FFmpeg можно почитать тут):

#!/bin/bash                                                                                                          
for (( i=0; i<$1; i++ )) do
   ffmpeg -i http://78.0.75.110:5454/ -an -vcodec h264_qsv -y Output-File-$i.mp4 &               
done

Сразу делаем проверку на 6 потоках (+2 к тесту на чистом CPU):

frame=291 fps=55 q=29.0 size=1280kB time=00:00:10.13 bitrate=1034.8kbits/s dup=2 drop=0 speed=1.93x

Разница очевидна: загрузка процессора не превышает 50%, а имеющийся запас вычислительных ресурсов позволяет прогнозировать 11 – 12 итоговых потоков.

Ставим 11 потоков:

frame=157 fps=30 q=38.0 Lsize=628kB time=00:00:05.69 bitrate=903.0kbits/s dup=2 drop=0 speed=1.09x

Загрузка процессора возрастает незначительно, но GPU уже подходит к пределу возможностей. Двенадцатый поток роняет битрейт и скорость обработки до 24 – 28 кадров.

Теперь проверяем потоки в 4K. В отличие от AMD, наш процессор Intel спокойно обрабатывает один поток в таком разрешении и без аппаратного ускорения:

frame=655 fps=31 q=-1.0 Lsize=30637kB time=00:00:21.73 bitrate=11547.9kbits/s speed=1.03x

На большее он, увы, не способен. С включенным Quick Sync тестовый компьютер смог вытянуть три потока с разрешением 4K:

frame= 509 fps=31 q=33.0 Lsize=8010kB time=00:00:17.42 bitrate=3764.7kbits/s dup=2 drop=0 speed=1.07x

Спасовал он только на четвертом, но столько же у нас выдержала и видеокарта Nvidia A5000.

Недостатки у решения, увы, тоже есть. При использовании модуля BMC (к примеру, при управлении машиной через IPMI), вы не получите доступ ко всем возможностям аппаратного ускорения, даже если GPU процессора будет определяться в системе. Придется выбирать между удобством удаленного управления или получением всех плюсов от использования Quick Sync.

Итоги

Выводы вы можете сделать самостоятельно. Мы лишь отметим, что для энкодинга видео разница в мощности видеокарт не всегда определяется их ценой, а для решения некоторых задач стоит обратить внимание на специализированные технологии внутри центральных процессоров. Также мы использовали для тестов H264, но кодеки HEVC (H265) или VP1 в теории должны дать лучшие результаты, особенно на разрешениях 4K. Если вы самостоятельно проведете подобные тесты с первым (VP1 пока что представлен аппаратно и массово только для декодинга), поделитесь результатами в комментариях.

____________

Сколько в деньгах?

Стоимость описанных выше экспериментов измерить просто: воспользуйтесь нашим калькулятором-конфигуратором на этой странице.

Например, в самой простой конфигурации она следующая:

  • машина с A4000 обойдется в 22 000р, 12 потоков - 1800р на поток в месяц;

  • машина с A5000 обойдется в 31 000р, 14 потоков - 2214р на поток в месяц;

  • сервер на i9-9900K с QuickSync (QSV) обойдется в 5000-6000р, 11 потоков, 450р на поток.

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

    Кстати, все серверы HOSTKEY предоставляются с нашим модулем полного удаленного управления сервером IPMI и панелью управления серверами и API. Об устройстве последней мы рассказали в этой статье.

Комментарии (6)


  1. mkarev
    24.04.2022 06:17
    +1

    Удивительно! Мы получили сравнимые с результатом A4000 цифры. Несмотря на большую частоту работы чипа, больший объем используемой видеопамяти и большее энергопотребление, A5000 осилила энкодинг только 14 потоков и спасовала на пятнадцатом. Это фиаско...

    С одной стороны результат вполне ожидаемый, т.к. обе карты имеют на борту один модуль NVENC (см. [1]).

    С другой стороны результат странный, т.к. в связи с более высокой частотой чипа "The performance should scale according to the video clocks as reported by nvidia-smi for other GPUs of every individual family" (см. [2]). Как вариант, прирост тактовой частоты был недостаточен для того, чтобы успеть еще один профиль кодирования на целевом разрешении, но это не точно.

    Литература
    [1] https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
    [2] https://docs.nvidia.com/video-technologies/video-codec-sdk/nvenc-application-note/index.html#nvenc-performance


    1. akdengi
      25.04.2022 00:04
      +1

      Ожидаемо да, но по факту хоть и частоты больше, но похоже на модули энкодинга это не сильно повлияло (в пределах погрешности измерений), да и если исходить из realtime больше 16 потоков и не должно было дать :) при одинаковой архитектуре. Думаю результаты были бы лучше при том же рендеренге видео с декодированием/кодированием, где частота влияет на суммарно затраченное время.


  1. borovinskiy
    24.04.2022 08:35
    +1

    Спасибо за опыт!

    Для CentOS8 можно попробовать ffmpeg взять из реп: https://elibsystem.ru/node/531. Пробрасывал Quadro P400 в Proxmox и все заработало. Quadro P400 так как 1 слот занимает, а кодировщики в одном поколении одинаковые с 1030 стоят.


  1. borovinskiy
    24.04.2022 08:42
    +2

    Есть методологический вопрос: а качество не дефолтовое ставить пробовали? Просто при q=38 там же смотреть будет ничего не возможно. При больших q (низком качестве) алгоритмы загрубляют картинку и поэтому, боюсь, у вас получается высокая производительность.

    Поставьте q=18 или такое, качество картинки при котором вас будет устраивать как зрителя.


    1. akdengi
      25.04.2022 00:13
      +1

      Здесь был входной поток видео без тонкой настройки ffmpeg и без изменения качества (да, можно было затюнинговать, но смысл как раз был в работе с дефолтом) и визуальная проверка показала, что записываемые потоки в хорошем качестве на диске. Плюс q тут в момент скрина и он прыгал в выводе, а для h264 если почитать вопросы и отзывы про ffmpeg, похоже в норме прыжки от 0 до 31 (кто то говорит, что даже при q уходящем до 50 на некоторых кадрах итог будет ОК). Также с nvenc ffmpeg параметры некорректно выдает в вывод (тот же битрейт держится на постоянке и не совпадает со входными потоками).


  1. gwg605
    24.04.2022 13:57
    +1

    С таким разбросом qp возникают вопросы, что вообще измеряли и что с чем сравнивали???