2

У меня есть 2 отдельных экземпляра ffmpeg на моем компьютере с macOS (10.14.2 Mojave и четырехъядерный процессор Intel Core i5-8259U @ 2.30 ГГц, если это помогает):

1 - Установлено с brew (и связано с моим местным dylib's)

2 - Статическая сборка, загруженная из сборок Zeranoe's ffmpeg

Оба v4.1. Но при перекодировании одного и того же файла (OGG -> MP3) с теми же параметрами команды, с той же загрузкой системы и при прочих равных условиях ... экземпляр № 1 примерно в 3 раза быстрее, чем экземпляр № 2.Мне нужно знать почему, потому что мне нужно связать статическую сборку ffmpeg с моим приложением, и она должна работать оптимально. Смотрите вывод команды ниже:

Более быстрый экземпляр ffmpeg (обратите внимание, что скорость 46.5x):

$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size=   26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x

Более медленный экземпляр ffmpeg (обратите внимание, что скорость равна 17.2x)

$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size=   26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x

Почему огромная разница в производительности ???

Если я пойму это, то смогу собрать ffmpeg сам с оптимизированной производительностью, соответствующей моему более быстрому установленному ffmpeg (т.е. # 1).

Это как два экземпляра были настроены до создания ? Видите ли вы какие-либо существенные параметры конфигурации, которые являются причиной такой огромной разницы в производительности?

Мне не терпится узнать это, так как мое приложение зависит от производительности ffmpeg. Я был бы очень признателен за любые идеи. Заранее спасибо !

Экземпляр № 1 (быстрее) был настроен следующим образом:

ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)

configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay 
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl 
--enable-videotoolbox

libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libavresample   4.  0.  0 /  4.  0.  0
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100

Экземпляр № 2 (медленнее) был настроен следующим образом:

ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers

built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)

configuration: --enable-gpl --enable-version3 --enable-sdl2 
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame 
--enable-libopencore-amrnb --enable-libopencore-amrwb 
--enable-libopenjpeg --enable-libopus --enable-libshine 
--enable-libsnappy --enable-libsoxr --enable-libtheora 
--enable-libtwolame --enable-libvpx --enable-libwavpack 
--enable-libwebp --enable-libx264 --enable-libx265 
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib 
--enable-gmp --enable-libvidstab --enable-libvorbis 
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex 
--enable-libxvid --enable-libaom --enable-appkit 
--enable-avfoundation --enable-coreimage --enable-audiotoolbox

libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100

------ ОБНОВИТЬ: ------

1 - я попытался собрать libmp3lame с помощью --enable-nasm, а затем ffmpeg, используя этот встроенный lame. Разницы не заметил ... все еще медленно.

2 - Я провел те же тесты транскодирования на гораздо более старом Mac, и результаты были почти идентичны (уменьшены, потому что это более медленный компьютер).

то есть libmp3lame определенно является проблемой!

Итак, я решил для своего приложения, что буду использовать обходной путь - я просто предпочитаю транскодирование вместо AAC вместо MP3. Транскодирование AAC происходит молниеносно во всех моих экземплярах ffmpeg, и мое приложение хорошо поддерживает AAC. Я также продолжу исследовать проблему медлительности libmp3lame, но пока я разблокирован в моем приложении.

Спасибо всем за помощь! (Особая благодарность @Gyan и @ llogan)

1 ответ1

1

Это скорее всего ошибка от LAME

# 491 хромает на 3.100 медленнее, чем 3.99.5

Я сообщил об этом Zeranoe и johnvansickle.com. Джон сказал, что это будет исправлено в его выпуске git 20 декабря. Он сказал, что скомпилировал lame с CFLAGS="-O3" CPPFLAGS="-DNDEBUG" привело к ускорению в 3 раза.

Быть в курсе насм

Включение nasm, кажется, имеет существенное значение для 3.100 по сравнению с 3.99.5 в моем ленивом тесте на Arch Linux.

И Zeranoe, и John компилируют lame с --enable-nasm , поэтому медлительность их сборок связана с ранее упомянутой ошибкой.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .