Главная
Кремниевые Секреты Эльбрус 8С
Перекодирование видео с ffmpeg

4.1. Перекодирование видео с ffmpeg.

Скриншот 57. Вертикальное видео, конвертированное в горизонтальное с размытым фоном. Источник: junian.

Многие, наверное, натыкались в интернете на ролики типа «как сделать своё вертикальное видео горизонтальным в 2 клика без регистрации и СМС». Ну, в общем-то, инструменты, которые это делают, чаще всего базируются на ffmpeg. ffmpeg – это довольно мощный инструмент для работы с видео. Он позволяет и конвертировать видео, и обрезать, и накладывать эффекты, проводить минимальную коррекцию и всё это через консоль. Да даже стримить можно на YouTube при помощи ffmpeg. Вы можете взять плейлист с аудио или плейлист с видео и просто пустить его потоком на YouTube, используя для этого ffmpeg. Программа едва ли не на все случаи жизни, если научиться ей пользоваться. Многие утилиты, включая OBS, HandBrake, MP4Tools и куча других полагаются на ffmpeg при работе с видео. Т.е. эти утилиты дают вам более-менее понятный графический интерфейс, но под капотом практически всегда скрывается тот самый ffmpeg.

Ну и от того, насколько хорошо оптимизирован ffmpeg под железо зависит то, насколько высокие результаты это самое железо будет демонстрировать в большинстве приложений, направленных на работу с медиа. На Эльбрусе, разумеется, есть ffmpeg, но этот ffmpeg с нюансом.

Дело в том, что ffmpeg 4.4 на Альт Линукс 10 – это далеко не тот же ffmpeg 4.4, что доступен на Эльбрус ОС или OSL. Что я имею в виду?

Скриншот 58.Список поддерживаемых av1 декодеров в ffmpeg в Альт Линукс 10.

Если вы обратите внимание, то в Альт Линукс ffmpeg поставляется с декодерами libdav1d от VideoLAN, libaom-av1 от Alliance for Open Media и av1, являющийся, в общем-то, дубликатом того же libaom-av1.

Скриншот 59. Список поддерживаемых av1 декодеров в ffmpeg в Эльбрус ОС 7.1.

В Эльбрус ОС 7.1 как вы видите, libdav1d в декодерах уже отсутствует. Это значит, что ffmpeg в Альт Линукс 10 имеет в своём составе больше модулей. Т.е. меньше всего нюансов у вас будет именно с версией от Альт Линукс. Я всё больше прихожу к мысли, что Эльбрус ОС нужен как плацдарм, на котором обкатываются новые технологии, а затем уже после обкатки они переносятся в более юзабельные дистрибутивы вроде Альт (я без понятия, как дела обстоят на Астре, сравниваю лишь с Альтом).

В общем, если в случае с VLC мы имели возможность установки дополнительных модулей, а по дефолту всё было одинаково, то в случае с ffmpeg вариант «из коробки» отличается у этих дистрибутивов. Просто занимательное наблюдение.

Итак, в чём суть теста? Мы попробуем перекодировать 4K 60 FPS H.265 8-bit 4:2:0 видео с битрейтом 77,4 Мбит/сек в старый добрый кодек кодек H.264. Длительность видео – 02:59, размер – 1,61 GiB.

А зачем перекодировать из H.265 в H.264? Ну, для примера, затем, что Apple не позволяет в Final Cut монтировать H.265 видео, снятое не на iPhone или другое совместимое устройство. Final Cut понимает H.265, но не любой.

На Эльбрусе мы проводим тест сразу с Альт Линукс 10, и с OSL 7.1, и с OSL 6.0. А зачем тут OSL 6.0? Просто в OSL 6.0 стояла ещё старая версия ffmpeg 4.3.1 и интересно оценить разницу между 4.4 и 4.3.1 в случае с Эльбрусом. Ещё я проводил тест с опцией -crf0, которая заставляет ffmpeg минимально сжимать итоговое видео, отчего оно весит больше 30 ГБ, но что с этой опцией, что без, разница ± одна и та же между всеми аппаратами, так что отдельно рассматривать результаты с этой опцией я не буду. Пишу это для того, чтобы вы не удивлялись наличию на скринах результатов с -crf0.

Уточню перед тем, как начать тест: в ffmpeg используется довольно много Ассемблерного кода под x86, чтобы ускорить вычисления на x86 машинах. ffmpeg без Ассемблерного кода под x86 и ARM я не нашёл, так что сравниваю то, что могу на Эльбрусе и на других аппаратах (ну а как иначе?).

Итак, как прогнать этот тест? Загрузить ffmpeg нужной вам версии и загрузить файл, который будем перекодировать. Далее задействуем команды.

Набор команд для теста на x86 машине с Linux:

                            if [ -f "Sony Surfing 4K Demo.mp4" ]; then mv "Sony Surfing 4K Demo.mp4" Sony-Surfing-4K-Demo.mp4; fi; in="Sony-Surfing-4K-Demo.mp4"; ffmpeg -hide_banner -version | head -n 1; out="$(basename $in .mp4)-h264.mp4"; outcrf="$(basename $in .mp4)-h264-crf0.mp4"; for outfile in "$out" "$outcrf"; do if [[ $outfile =~ -crf0.mp4$ ]]; then crf0="-crf 0"; else crf0=""; fi; postargs="-benchmark -hide_banner -loglevel error -i $in -c:v libx264 -c:a copy -map 0:v:0 -map 0:a:0 -vsync 0 -qmin 18 -qmax 24 $crf0"; /usr/bin/time -f "Elapsed: %E (%e secs). $outfile" ffmpeg $postargs $outfile; done; for videos in "$in" "$out" "$outcrf"; do du $videos; du -h $videos; ffprobe -hide_banner -i $videos 2>&1 | grep Stream; done

Набор команд для теста на Эльбрусе (E2K) с Linux с RTC и без:

                            if [ -f "Sony Surfing 4K Demo.mp4" ]; then mv "Sony Surfing 4K Demo.mp4" Sony-Surfing-4K-Demo.mp4; fi; in="Sony-Surfing-4K-Demo.mp4"; out="$(basename $in .mp4)-h264.mp4"; outcrf="$(basename $in .mp4)-h264-crf0.mp4"; translator="/opt/mcst/rtc/bin/rtc_opt_rel_p1_x64_ob"; translatorargs=" --path_prefix /mnt/shared/rtc/ubuntu20.04/ -b $HOME -b /etc/passwd -b /etc/group -b /etc/resolv.conf -- "; translate=""; folder1="/usr/bin"; folder2="."; function transver() { $translator --version; }; echo ; function sizebitrate() { echo "$(tput setaf 3)File:$(tput sgr0) $1. $(tput setaf 6)Size:$(tput sgr0) $(du -h $1 | awk '{ print $1 }') ($(du $1 | awk '{ print $1 }') bytes).$(tput sgr0) $(eval $translate $2/ffprobe -hide_banner -i $1 2>&1 | grep 'Video:')"; }; sizebitrate $in $folder1; if [[ ! $(arch) =~ ^((x|i[[:digit:]])86|amd64) ]]; then declare -a folders=("$folder1" "$folder2"); else declare -a folders=("$folder1"); fi; for folder in "${folders[@]}"; do echo; if [[ $folder == "/usr/bin" ]]; then Mode="Native"; translate=""; else Mode="Translate"; translate="$translator $translatorargs"; transver ; fi; file $folder/ffmpeg | grep -o '^.*linked'; eval $translate $folder/ffmpeg -hide_banner -version | head -n 1; for outfile in "$out" "$outcrf"; do if [[ $outfile =~ -crf0.mp4$ ]]; then crf0="-crf 0"; else crf0=""; fi; postargs="-hide_banner -loglevel error -i $in -c:v libx264 -c:a copy -map 0:v:0 -map 0:a:0 -vsync 0 -qmin 18 -qmax 24 $crf0 -y"; /usr/bin/time -f "Elapsed: %E (%e secs). Mode: $Mode. Output: $outfile." /bin/bash -c "eval $translate $folder/ffmpeg $postargs $outfile"; sizebitrate $outfile $folder; rm -f $outfile; done; done;

Набор команд для теста на ARM с Linux с ExaGear и без:

                            if [ -f "Sony Surfing 4K Demo.mp4" ]; then mv "Sony Surfing 4K Demo.mp4" Sony-Surfing-4K-Demo.mp4; fi; in="Sony-Surfing-4K-Demo.mp4"; out="$(basename $in .mp4)-h264.mp4"; outcrf="$(basename $in .mp4)-h264-crf0.mp4"; translator="exagear"; translatorargs=" -- "; translate=""; folder1="/usr/bin"; folder2="."; function transver() { /opt/exagear/bin/ubt_x64a64_opt --version | grep -i Revision; }; echo ; function sizebitrate() { echo "$(tput setaf 3)File:$(tput sgr0) $1. $(tput setaf 6)Size:$(tput sgr0) $(du -h $1 | awk '{ print $1 }') ($(du $1 | awk '{ print $1 }') bytes).$(tput sgr0) $(eval $translate $2/ffprobe -hide_banner -i $1 2>&1 | grep 'Video:')"; }; sizebitrate $in $folder1; if [[ ! $(arch) =~ ^((x|i[[:digit:]])86|amd64) ]]; then declare -a folders=("$folder1" "$folder2"); else declare -a folders=("$folder1"); fi; for folder in "${folders[@]}"; do echo; if [[ $folder == "/usr/bin" ]]; then Mode="Native"; translate=""; else Mode="Translate"; translate="$translator $translatorargs"; transver ; fi; file $folder/ffmpeg | grep -o '^.*linked'; eval $translate $folder/ffmpeg -hide_banner -version | head -n 1; for outfile in "$out" "$outcrf"; do if [[ $outfile =~ -crf0.mp4$ ]]; then crf0="-crf 0"; else crf0=""; fi; postargs="-hide_banner -loglevel error -i $in -c:v libx264 -c:a copy -map 0:v:0 -map 0:a:0 -vsync 0 -qmin 18 -qmax 24 $crf0 -y"; /usr/bin/time -f "Elapsed: %E (%e secs). Mode: $Mode. Output: $outfile." /bin/bash -c "eval $translate $folder/ffmpeg $postargs $outfile"; sizebitrate $outfile $folder; rm -f $outfile; done; done;

Набор команд для теста на x86 машине с Windows:

                            $ffmpegdir=".\ffmpeg\bin"; $ffmpeg="$ffmpegdir\ffmpeg.exe"; if (Test-Path -Path '.\Sony Surfing 4K Demo.mp4' -PathType Leaf) { Rename-Item -Path '.\Sony Surfing 4K Demo.mp4' -NewName '.\Sony-Surfing-4K-Demo.mp4' }; $in='Sony-Surfing-4K-Demo.mp4'; $out="$((Get-Item $in).Basename)-h264.mp4"; $outcrf="$((Get-Item $in).Basename)-h264-crf0.mp4"; Function SizeBitrate ($file) { Write-Output "$file - $((Get-Item $file).Length/1GB 2>$null) ($((Get-Item $file).Length 2>$null) bytes)"; Invoke-Expression "& $ffmpegdir\ffprobe.exe -hide_banner -i $file 2>&1 | findstr Video"}; Write-Output ''; SizeBitrate -file $in; Write-Output ''; Invoke-Expression "& $ffmpeg -hide_banner -version | select -first 1"; ForEach ( $outfile in $out,$outcrf ) { if ( $outfile -match '-crf0.mp4$' ) { $crf0='-crf 0' } else { $crf0='' }; Write-Output ''; $postargs="-hide_banner -loglevel error -i $in -c:v libx264 -c:a copy -map 0:v:0 -map 0:a:0 -vsync 0 -qmin 18 -qmax 24 $crf0 -y"; $ElapsedTime=(Measure-Command -Expression { Invoke-Expression "& $ffmpeg $postargs $outfile" } ); Write-Output "Elapsed: $($ElapsedTime.Hours):$($ElapsedTime.Minutes):$($ElapsedTime.Seconds).$($ElapsedTime.MilliSeconds) ($($ElapsedTime.TotalSeconds ) seconds): $outfile" ; SizeBitrate -file $outfile; Remove-Item $outfile };

И набор команд для теста на macOS (x86 и ARM) с Rosetta 2 и без (предполагается, что ARM версия ffmpeg у вас лежит в папке ffmpeg-arm, а x86 версия в папке ffmpeg-x86):

                            if [ -f "Sony Surfing 4K Demo.mp4" ]; then mv "Sony Surfing 4K Demo.mp4" Sony-Surfing-4K-Demo.mp4; fi; in="Sony-Surfing-4K-Demo.mp4"; out="$(basename $in .mp4)-h264.mp4"; outcrf="$(basename $in .mp4)-h264-crf0.mp4"; translator="arch"; translatorargs="-x86_64"; translate=""; folder1="ffmpeg-arm"; folder2="ffmpeg-x86"; echo ; function sizebitrate() { echo "$(tput setaf 3)File:$(tput sgr0) $1. $(tput setaf 6)Size:$(tput sgr0) $(du -h $1 | awk '{ print $1 }') ($(du $1 | awk '{ print $1 }') bytes).$(tput sgr0) $(eval $translate $2/ffmpeg -hide_banner -i $1 2>&1 | grep 'Video:')"; }; sizebitrate $in $folder1; if [[ ! $(arch) =~ ^((x|i[[:digit:]])86|amd64) ]]; then declare -a folders=("$folder1" "$folder2"); else declare -a folders=("$folder2"); fi; for folder in "${folders[@]}"; do echo; if [[ $folder == $folder1 ]]; then translate=""; else if [[ ! $(arch) =~ ^((x|i[[:digit:]])86|amd64) ]]; then translate="$translator $translatorargs"; fi; fi; file $folder/ffmpeg; eval $translate $folder/ffmpeg -hide_banner -version | head -n 1; for outfile in "$out" "$outcrf"; do if [[ $outfile =~ -crf0.mp4$ ]]; then crf0="-crf 0"; else crf0=""; fi; postargs="-hide_banner -loglevel error -i $in -c:v libx264 -c:a copy -map 0:v:0 -map 0:a:0 -vsync 0 -qmin 18 -qmax 24 $crf0 -y"; /usr/bin/time /bin/bash -c "eval $translate $folder/ffmpeg $postargs $outfile"; sizebitrate $outfile $folder; rm -f $outfile; done; done;

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

Версию для теста в macOS брал с OSXexperts.net.

Для Linux статичные сборки (не зависящие от особенностей отдельно взятого дистрибутива) доступны на ресурсе johnvansickle.com.

Для Windows же ffmpeg скачал с ресурса gyan.dev.

Скриншот 60. Перекодирование видео при помощи ffmpeg 4.3.1. OSL 6.0

Скриншот 61. Перекодирование видео при помощи ffmpeg 4.4. Альт 10.

Скриншот 62. Перекодирование видео при помощи ffmpeg 4.4. OSL 7.1.

Гистограмма 1. Время, затраченное на перекодирование видео на Эльбрусе с разными ОС (OSL 6.0, OSL 7.1 и Alt 10).

И, как видите, результаты с одинаковой версией ffmpeg вышли примерно одинаковыми на Alt Linux и OSL 7.1. Там разница всего 1% и её можно списать на погрешность. А вот OSL 6.0 с ffmpeg версии 4.3.1 оказался далеко позади: отстал аж на 13.5%. О чём это говорит? О том, что при портировании ffmpeg под Эльбрус ffmpeg в версии 4.4 проводились дополнительные оптимизации. Как я предполагал изначально, разработчики МЦСТ или Базальта проводили эти оптимизации, а затем обменялись наработками, и в оба дистрибутива пошла уже версия 4.4, правда собранная с разными функциональными возможностями.

Почему я так уверен, что это именно МЦСТ или Базальт СПО работали над оптимизацией под Эльбрус? Может, дело в том, что сами разработчики ffmpeg оптимизировали свой код так, чтобы ускорить его на всех машинах?

Что ж, в таком случае, между версиями 4.3.1 и 4.4 я должен ощутить положительный эффект даже на своём ноутбуке Xiaomi.

Скриншот 63. Затраты времени на перекодирование в ffmpeg (4.3.1, 4.4, 5.0) у Xiaomi Mi Notebook Pro GTX.

На скрине на telegram-send не обращайте внимания. На результат не влияет, это просто оповещение мне в Телегу о завершении теста. С помощью небольшого набора команд я запустил тест поочерёдно с 3 версиями ffmpeg: 4.3.1, 4.4 и 5.0. Тестировал я и с опцией -crf 0, и без неё. И, в общем-то, вышло у меня так, что разницы особой нет между этими версиями по части перекодирования видео на процессоре. Я поинтересовался этим вопросом и да, как оказалось, действительно, за это респект и уважение Илье Курдюкову! Прирост реально ощутим, аж 13.5%, и всё благодаря его патчам.

Гистограмма 2. Скорость декодирования видео на разных машинах.

Ну и тут мой ноутбук затратил в 3.37 раза меньше времени на эту задачу. Впрочем, кто бы сомневался. Ассемблер же тут под Intel драили.

Далее не вижу смысла особо пристально рассматривать результаты на Эльбрус ОС 6.0 с ffmpeg 4.3.1, т.к., очевидно, более оптимизированная версия доступна для установки в Эльбрус ОС 7.0 и Альт 10 с ffmpeg 4.4.

Скриншот 64. Затраты времени на перекодирование видео в Альт 10 с ffmpeg 4.4 с опцией -crf0.

Скриншот 65. Затраты времени на перекодирование видео в Эльбрус ОС 7.1 с ffmpeg 4.4 с опцией -crf0.

С опцией -crf0 результаты примерно одинаковые в Альт 10 и Эльбрус ОС 7.1. Я уже упоминал выше, с этой опцией разница между всеми +- та же.

Скриншот 66. Затраты времени на перекодирование видео на Raspberry Pi 4 с Ubuntu 20.04.3 (с ExaGear и без).

Вот теперь начинается самое интересное. Я в предыдущей главе упоминал, что каким-то волшебным образом на моей малине с Ubuntu 20.04.3 пашет ExaGear, разработка Eltechs, а, вернее, выходцев из отдела бинарной трансляции в МЦСТ, которая теперь принадлежит Huawei. Не знаю, почему, но Huawei держат ExaGear в открытом доступе. Т.е. любой желающий может скачать себе ExaGear (я пользовался версией 1.2.1.1) и попробовать, мало ли, вдруг заработает. У меня на Raspberry Pi OS не работала вся эта история, но вот на Ubuntu 20.04.3 на малине всё пашет. Я и User Guide нашёл к ExaGear, и он также в открытом доступе. Разумеется, я сам воспользовался этими инструментами чисто в исследовательских целях. Никто, брат, вообще никто даже и не думал пользоваться этим на постоянной основе. Ну, вы поняли. Интересно сравнить эффективность трансляции между ExaGear и RTC. Для ExaGear я использовал образ Ubuntu Base 20.04.3, который поставлялся вместе с ним, и для RTC на Эльбрусе я также воспользовался Ubuntu 20.04.3.

Для того, чтобы прогнать тест и с x86 версией ffmpeg, я загрузил уже готовые собранные варианты с сайта johnvansickle. Для сравнения с RTC на Эльбрусе брал версию 4.4, а для сравнения с ExaGear на малине брал версию 4.3.1, поскольку из репозитория Ubuntu ставится именно эта версия для ARM (т.е. сравниваем в нативе и в трансляции между собой те же версии ffmpeg).

Скриншот 67. Время, затраченное на перекодирование видео с ffmpeg 4.4 на 8С (Альт 10) с и без RTC.

Я перепрогнал тот же тест на Альт Линукс, воспользовавшись также и RTC 4.1. Результаты без трансляции те же, но теперь мы ещё знаем, как ffmpeg пашет на Эльбрусе в трансляции. И можем примерно определить эффективность трансляции ffmpeg с RTC.

Скриншот 68. Время, затраченное на перекодирование видео с ffmpeg 4.4 на Ubuntu 20.04.3 с Lintel 4.1.

Ещё я провёл этот же тест в трансляции в Lintel с Ubuntu 20.04.3 с двумя ядрами, выделенными под трансляцию кода.

Скриншот 69. Время, затраченное на перекодирование видео с ffmpeg 4.4 на Windows 10 21H2 с Lintel 4.1.

Ну и, конечно же, куда же без винды? Я прогнал тест и на Windows 10 21H2. Так что теперь нам известны результаты Эльбруса и в нативе, и в трансляции с RTC, и в трансляции с Lintel.

Скриншот 70. Время, затраченное на перекодирование видео с ffmpeg 4.4 на 16С (Альт 10) с и без RTC.

И под конец, барабанная дробь, я провёл этот тест и на инженерном образце Эльбрус 16С, к которому получил удалённый доступ. Большое спасибо ООО «Промобит» за возможность мельком взглянуть на то чудо, что нас ждёт в будущем. Поясню сразу: на 16С на данный момент установлен дистрибутив Альт Линукс 10, собранный под предыдущее поколение Эльбруса, у него используется старый компилятор (1.25 вместо 1.26), у него частично отключен кэш и оперативная память работает на сниженной частоте (DDR4-2400 вместо DDR4-3200). К моменту, когда я его тестировал, планок памяти стало 8 вместо 2, но суть вы поняли. Его результаты даже так впечатляют при сравнении с 8С, так что мы рассмотрим и их..

Скриншот 71. Время, затраченное на перекодирование видео в ffmpeg 4.3.1 на Macbook Pro с Apple M1.

И я также воспользуюсь данными со своего старого обзора Macbook Pro на Apple M1. Только тогда я тестировал ffmpeg версии 4.3.1, та же версия, что и на малине, а не 4.4, как на Эльбрусе. По производительности между этими версиями разницы быть не должно, но, на всякий, уточнил.

Итак, что у нас вышло?

Гистограмма 3. Время, затраченное на перекодирование видео в ffmpeg.

Гистограмма 4. Скорость перекодирования видео в ffmpeg. Результат относительно Эльбрус 8С с Альт Линукс 10.

Данных получилось много, так что разберём все неспешно по частям. Где показываю результат в процентах, там результат относительно Эльбруса 8С с Альт Линукс 10 и ffmpeg 4.4 в нативе.

Сперва начнём с Эльбрус 8С.

Гистограмма 5. Время, затраченное на перекодирование видео в ffmpeg на Эльбрус 8С с трансляцией и без.

Гистограмма 6. Скорость перекодирования видео в ffmpeg 4.4 на Эльбрус 8С (относительно Альт 10 в нативе).

Тут мы на гистограмме видим 4 теста: в нативе, т.е. c ffmpeg, скомпилированным под E2K (взят из репозитория Альт Линукс), далее в трансляции через RTC с Ubuntu 20.04.3, в трансляции через Lintel (т.е. когда вся система у нас работает через трансляцию) на Ubuntu 20.04.3 и на тоже в трансляции через Lintel, но уже на Windows 10 21H2.

Разумеется, быстрее всего нативное исполнение на Альт Линукс. Но сколько % производительности мы теряем при использовании трансляции? RTC отстал на 19%, что существенно, но не так, чтобы прям фатально. Lintel с Ubuntu отстаёт уже намного сильнее: почти в 2 раза (56% против 100%), а Lintel с Windows отстаёт уже почти в 3 раза (38% против 100%). Ну, в общем-то, я говорил, винда на Эльбрусе – какое-то лютое извращение. Работать то работает, но я хз, какой вообще смысл использовать винду на Эльбрусе.

Гистограмма 7. Время, затраченное на перекодирование видео в ffmpeg на Эльбрус 16С с трансляцией и без.

Гистограмма 8. Скорость перекодирования в ffmpeg на Эльбрус 16С (с трансляцией и без) относительно натива.

Вот что меня удивило: что на Эльбрус 16С, напротив, в трансляции получилось быстрее, чем без неё. Есть одно предположение: ffmpeg под Эльбрус 16С мог быть скомпилирован ещё без поддержки SIMD инструкций под 128 бит регистры. А вот RTC, напротив, мог транслировать 128-бит SSE инструкции в как-раз нужные нам 128-бит SIMD инструкции на Эльбрусе 16С. Может быть, моё предположение не верно, но, как бы то ни было, в трансляции результат на 16С примерно тот же, что и в нативе (чуть быстрее).

Гистограмма 9. Время, затраченное на перекодирование видео в ffmpeg на Эльбрус 8С и Эльбрус 16С в нативе.

Гистограмма 10. Скорость перекодирования на Эльбрус 8С и 16С относительно 8С в нативе.

Если смотреть на результаты 16С, то это просто ахренеть: в 2.5 раза быстрее, чем 8С. Я думаю, если бы задействовались на 16С в нативе 128-бит SIMD инструкции, 16С был бы ещё быстрее. Сейчас же результат получился близок к разнице в числе ядер и разнице по частоте (2 ГГц против 1.3 ГГц). Если бы ffmpeg был оптимизирован под E2Kv6, он работал бы ещё быстрее.

Гистограмма 11. Время, затраченное на перекодирование видео в ffmpeg на Raspberry Pi 4 в нативе и трансляции.

Гистограмма 12. Скорость перекодирования видео в ffmpeg на Raspberry Pi 4 с трансляцией и без (натив – 100%).

И вот какая интересная история получается. На Raspberry Pi 4 при использовании ExaGear производительность падает примерно в 2 раза в данной дисциплине. И тут вопрос: это под ARM настолько хорошо оптимизирован ffmpeg, что на фоне такой оптимизации скорость при трансляции просто меркнет, или же на Эльбрусе недостаточно хорошо оптимизирован ffmpeg в сравнении с другими платформами?

Ещё может быть, что для эффективной трансляции с использованием ExaGear требуется больше оперативной памяти. Как-никак, на компьютере с Эльбрус 8С у нас 32 ГБ оперативной памяти, на Macbook Pro с Apple M1 – 16 ГБ, а на малине (Raspberry Pi 4) всего лишь 4 ГБ. Этого может не хватать.

К слову, а как дела обстояли на Macbook Pro с Apple M1 и Rosetta 2?

Гистограмма 13. Время, затраченное на перекодирование видео в ffmpeg на Macbook Pro M1 в нативе и трансляции.

Гистограмма 14. Скорость перекодирования видео в ffmpeg на Macbook Pro M1 с трансляцией и без (натив – 100%).

На Macbook Pro с Apple M1 у меня разница между нативным исполнением и трансляцией вышла чуть меньше, но разница всё ещё практически в 2 раза.

Выходит, что в данном конкретном тесте RTC намного эффективнее, чем Rosetta 2 и ExaGear от Huawei. Или же просто нативный ffmpeg под E2K ещё не столь хорошо оптимизирован, и из него можно выжать больше производительности. Как бы то ни было, результаты вышли интересными.

А теперь давайте посмотрим на результаты всех аппаратов без трансляции.

Гистограмма 15. Время, затраченное на перекодирование видео в ffmpeg на всех аппаратах в нативе.

Гистограмма 16. Скорость перекодирования видео в ffmpeg на Macbook Pro M1 с трансляцией и без (натив – 100%).

Больше всех времени на эту задачу затратила малина: чуть более 10000 секунд или более 2.5 часов. Почти в 1.5 раза быстрее справился Эльбрус 8С. Далее Эльбрус 16С уже довольно близок по производительности к моему Core i7 8550U в ноутбуке Xiaomi. Но я уверен, что из 16С и Эльбрус 8С можно выжать раза в 1.5 больше производительности (а то и намного больше) при должной оптимизации, т.к., по моему подозрению, ffmpeg на 16С не задействовал преимуществ более свежей архитектуры (в т.ч. SIMD).

Быстрее всех справился, конечно, Macbook Pro с Apple M1: раз в 5 быстрее, чем Эльбрус 8С.

И остаётся вопрос: можно ли на Эльбрусе перекодировать видео при помощи аппаратных блоков кодирования и декодирования видео видеокарты AMD?

Скриншот 72. Попытка перекодирования видео при помощи VAAPI в ffmpeg 4.4 с Альт 10 на Эльбрус 8С.

Я попробовал это сделать, но, к сожалению, у меня не вышло задействовать VA-API в ffmpeg при перекодировании видео.

Скриншот 73. Опции кодировщика видео в OBS в Альт 10.

И это странно, т.к. в OBS c ffmpeg аппаратное ускорение работает. Я запускал тестовые стримы на Эльбрусе и использовал для этого VAAPI через ffmpeg в OBS. Но при этом в самом ffmpeg без OBS я не смог задействовать VAAPI. Я вполне мог что-то сделать не так, но, что получилось, вы видите.

Скриншот 74. Вывод команды vainfo в Альт Линукс 10.

Я проверил через терминал: нет никаких проблем с VAAPI как с кодированием, так и с декодированием H.264 и H.265 видео. В общем, странно: VAAPI я могу использовать в OBS при помощи ffmpeg, но в самом ffmpeg напрямую я им воспользоваться не могу. Без понятия, в чём дело.

Скриншот 75. Проигрывание 4K 60 FPS 8-bit H.265 видео в VLC.

По части воспроизведения видео: в VLC у меня не было проблем даже c 4K 60 FPS 8-bit H.265 видео. Всё ок, видеокарта здесь задействуется.

С перекодированием видео в ffmpeg разобрались. Далее, прежде чем продолжить вопрос с видео, взглянем на то, что там с работой в 3D (Blender).