FFmpeg 4 против версии 2.2 очень медленные транскодирование в контейнере VMWare CentOS 6
325
aernative
Вист, используя «ffmpeg version n4.0.1», заметил, что на хосте CentOS6 внутри контейнера VMware транскодирование видео занимает почти вдвое больше времени, чем «ffmpeg version 2.2.1».
Тесты ниже, запустили 3 итерации, самое быстрое время только ниже.
Файл, проверенный с тем же самым 2.8mb запасным видео.
Все виртуальные машины работают под управлением CentOS версии 6.10.
Я буквально понятия не имею, почему это отличается, и не могу найти никакой логической причины для этого - какие-нибудь бобы FFMpeg / VMWare там имеют какое-либо представление о том, что может происходить?
4.01 скомпилировано из исходного кода, 2.2.1 соответствует EPEL.
Просто добавить - информация о процессоре VMWare выглядит следующим образом -
процессор: 0 vendor_id: GenuineIntel семья процессора: 6 модель: 62 Название модели: Intel (R) Xeon (R) CPU E5-2620 v2 @ 2,10 ГГц степпинг: 4 микрокод: 1064 процессор МГц: 2100.000 размер кеша: 15360 кб физический идентификатор: 0 братьев и сестер: 1 основной идентификатор: 0 процессорных ядер: 1 апицид: 0 начальная апицид: 0 фпу: да fpu_exception: да Уровень процессора: 13 wp: да флаги: FPU VME-де-псевдоэфедрин TSC MSR пае MCE CX8 APIC SEP MTRR PGE MCA CMOV погладить pse36 clflush д.т.н. MMX fxsr ссе sse2 сс Системный вызов пх rdtscp лм constant_tsc arch_perfmon УИБ БПС xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock ПНИ PCLMULQDQ SSSE3 CX16 PCID sse4_1 sse4_2 x2APIC POPCNT АЕС XSAVE avx f16c rdrand гипервизор lahf_lm arat epb xsaveopt pln pts dtherm pti ретполин fsgsbase smep bogomips: 4200,00 размер clflush: 64 cache_alignment: 64 размеры адресов: 40-битный физический, 48-битный виртуальный управление энергопотреблением:
Информация о процессоре в сравнении с VirtualBox указана как
обработчик: 0 vendor_id: GenuineIntel семья процессора: 6 модель: 158 Название модели: Intel (R) Core (TM) i7-7820HQ CPU @ 2,90 ГГц степпинг: 9 процессор МГц: 2903,925 размер кеша: 8192 КБ физический идентификатор: 0 братьев и сестер: 2 основной идентификатор: 0 ядер процессора: 2 апицид: 0 начальная апицид: 0 фпу: да fpu_exception: да Уровень процессора: 22 wp: да флаги: FPU VME-де-псевдоэфедрин TSC MSR пае MCE CX8 APIC SEP MTRR PGE MCA CMOV погладить pse36 clflush MMX fxsr ße SSE2 ХТ системных вызовов пх rdtscp ой constant_tsc rep_good xtopology nonstop_tsc ПНИ PCLMULQDQ SSSE3 CX16 PCID sse4_1 sse4_2 movbe POPCNT äes XSAVE AVX rdrand lahf_lm ABM 3dnowprefetch fsgsbase avx2 invpcid rdseed bogomips: 5807,85 размер clflush: 64 cache_alignment: 64 размеры адресов: физические 39 бит, виртуальные 48 бит управление энергопотреблением:
Выше показано, что новая версия работает лучше и хуже на разных архитектурах.
Чтобы быть на 100% ясным, я перезапустил некоторые тесты ниже - это разные виртуальные машины в одном облаке с одинаковыми настройками -
Вы уверены, что делаете правильные сравнения яблок с яблоками? Например, есть два совершенно разных процессора (Xeon и i7), и одно явно настроено на использование нескольких ядер, а другое нет. Проводились ли сравнения ffmpeg 4 и ffmpeg 2 в одной и той же виртуальной машине на одном хосте?
jamesdlin 5 лет назад
0
Процессоры разные да - и это может быть фактором - однако сравнения выполняются на одном и том же хосте - и команда ffmpeg была настроена на использование только 1 ядра, сравнительно тест на тех же машинах пропорционально медленнее при установке Xeon / VMware чем локальный i7 / Virtualbox - количество ядер вводит в заблуждение, и я не думаю, что их установка идентична, будет иметь большое значение, однако я проверю, чтобы быть уверенным (то есть, как мы сравнивали сравнение одной версии с другой относительно того же машина). Тестирование снова сегодня.
aernative 5 лет назад
0
Я добавил тест на идентичные виртуальные машины, чтобы продемонстрировать суть - посмотрите последние два теста на VMWare с полной детализацией, при запуске на альтернативной установке (virtualbox) происходит обратное.
aernative 5 лет назад
0
Полные результаты уже показаны выше, команда была простым транскодом mov в mp4 для веб-воспроизведения - та же команда, использованная в обоих тестах.
aernative 5 лет назад
0
`использование возможностей процессора: нет!` указывает на то, что ваша связанная libx264 могла быть скомпилирована с `--disable-asm` или какой-то другой проблемой, из-за которой не использовались оптимизации сборки.
LordNeckbeard 5 лет назад
0
1 ответ на вопрос
0
aernative
При тестировании с 4.0.2 проблема исчезла, хотя сейчас она немного быстрее, она далеко не такая же быстрая, как при локальной настройке, но которую мы можем отнести к процессору.
Я могу только заключить, что все, что вызывало замедление, было ограничено этой конкретной версией - (4.0.1).
Хотя это и не ответ на вопрос, в чем причина, поскольку незначительное обновление версии устраняет проблему, я не вижу ошибки в попытке выяснить причину.