FFmpeg 4 im Vergleich zu Version 2.2: Sehr langsame Transcodierungen in VMWare CentOS 6-Container

406
aernative

Wenn Sie "ffmpeg Version n4.0.1" verwenden, ist mir aufgefallen, dass auf CentOS6-Hosts in einem VMware-Container die Videotranscodierung fast doppelt so lange dauert wie "ffmpeg Version 2.2.1".

Benchmarks unten liefen 3 Iterationen, Bestzeit nur unten.

Die getestete Datei ist das gleiche 2,8 MB Stock Video.

Alle VMs, auf denen die CentOS-Version 6.10 ausgeführt wird.

| VM | FFMpeg-Version | Zeit | | Virtualbox | 4.0.1 | 11 s | | Virtualbox | 2.2.1 | 18 sek | | VMWare | 2.2.1 | 29 sek | | VMWare | 4.0.1 | 1 minuite | 

Ich habe keine Ahnung, warum dies anders ist und kann keinen logischen Grund dafür finden - haben FFMpeg / VMWare-Entwickler irgendeinen Hinweis darauf, was los sein könnte?

4.01 wird aus dem Quellcode zusammengestellt, 2.2.1 entspricht EPEL.

Einfach hinzufügen - VMWare-CPU-Info ist wie folgt -

Prozessor: 0 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 62 Modellname: Intel (R) Xeon (R) CPU E5-2620 v2 bei 2,10 GHz Treten: 4 Mikrocode: 1064 CPU-MHz: 2100.000 Cache-Größe: 15360 KB physikalische id: 0 Geschwister: 1 Kern-ID: 0 CPU-Kerne: 1 apicid: 0 Anfangsapicid: 0 fpu: ja fpu_exception: ja cpuid level: 13 wp: ja Fahnen: FPU vme de pse tsc msr PAE mce CX8 APIC sep mtrr PGE mca cmov pat PSE36 CLFLUSH dts MMX fxsr sse sse2 ss syscall nx rdtscp lm CONSTANT_TSC arch_perfmon PEBS bts xtopology tsc_reliable NONSTOP_TSC aperfmperf unfair_spinlock pni pclmulqdq SSSE3 CX16 PCID sse4_1 sse4_2 x2apic popcnt aes XSAVE avx f16c rdrand hypervisor lahf_lm arat epb xsaveopt pln pts dtherm pti retpoline fsgsbase smep Bogomips: 4200.00 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 40 Bit physisch, 48 Bit virtuell Energieverwaltung: 

Versus VirtualBox CPU-Info als gemeldet

Prozessor: 0 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 158 Modellname: Intel (R) Core (TM) i7-7820HQ-CPU bei 2.90 GHz Schritt: 9 CPU-MHz: 2903,925 Cachegröße: 8192 KB physikalische id: 0 Geschwister: 2 Kern-ID: 0 CPU-Kerne: 2 apicid: 0 Anfangsapicid: 0 fpu: ja fpu_exception: ja cpuid level: 22 wp: ja fpcgepac_sim_et_patch_sim_et_patch_sim_et_patch_sim_cp avx2 invpcid rdseed Bogomips: 5807.85 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 39 Bit physisch, 48 Bit virtuell Energieverwaltung: 

Das Vorstehende zeigt, dass die neuere Version auf verschiedenen Architekturen besser und schlechter abschneidet.

Um 100% klar zu sein, habe ich einige Benchmarks weiter unten ausgeführt - dies sind unterschiedliche VMs in derselben Cloud mit identischen Setups -

FFMPeg 4 - 122,861 Sekunden

[root @ Proofing-Test] # ./benchmark.sh Prozessor: 0 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 62 Modellname: Intel (R) Xeon (R) CPU E5-2620 v2 bei 2,10 GHz Treten: 4 Mikrocode: 1064 CPU-MHz: 2100.000 Cache-Größe: 15360 KB physikalische id: 0 Geschwister: 1 Kern-ID: 0 CPU-Kerne: 1 apicid: 0 Anfangsapicid: 0 fpu: ja fpu_exception: ja cpuid level: 13 wp: ja Fahnen: FPU vme de pse tsc msr PAE mce CX8 APIC sep mtrr PGE mca cmov pat PSE36 CLFLUSH dts MMX fxsr sse sse2 ss syscall nx rdtscp lm CONSTANT_TSC arch_perfmon PEBS bts xtopology tsc_reliable NONSTOP_TSC aperfmperf unfair_spinlock pni pclmulqdq SSSE3 CX16 PCID sse4_1 sse4_2 x2apic popcnt aes XSAVE avx f16c rdrand hypervisor lahf_lm arat epb xsaveopt pln pts dtherm pti retpoline fsgsbase smep Bogomips: 4200.00 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 40 Bit physisch, 48 Bit virtuell Energieverwaltung:  Prozessor: 1 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 62 Modellname: Intel (R) Xeon (R) CPU E5-2620 v2 bei 2,10 GHz Treten: 4 Mikrocode: 1064 CPU-MHz: 2100.000 Cache-Größe: 15360 KB physikalische id: 2 Geschwister: 1 Kern-ID: 0 CPU-Kerne: 1 apicid: 2 ursprünglicher apicid: 2 fpu: ja fpu_exception: ja cpuid level: 13 wp: ja Fahnen: FPU vme de pse tsc msr PAE mce CX8 APIC sep mtrr PGE mca cmov pat PSE36 CLFLUSH dts MMX fxsr sse sse2 ss syscall nx rdtscp lm CONSTANT_TSC arch_perfmon PEBS bts xtopology tsc_reliable NONSTOP_TSC aperfmperf unfair_spinlock pni pclmulqdq SSSE3 CX16 PCID sse4_1 sse4_2 x2apic popcnt aes XSAVE avx f16c rdrand hypervisor lahf_lm arat epb xsaveopt pln pts dtherm pti retpoline fsgsbase smep Bogomips: 4200.00 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 40 Bit physisch, 48 Bit virtuell Energieverwaltung:  ffmpeg version n4.0.1 Copyright (c) 2000-2018 der FFmpeg-Entwickler gebaut mit gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-23) Konfiguration: --prefix = / root / ffmpeg_build --pkg-config-flags = - statisch --extra-cflags = -I / root / ffmpeg_build / include --extra-ldflags = -L / root / ffmpeg_build / lib - -extra-libs = -lpthread --extra-libs = -lm --bindir = / usr / bin --enable-gpl --enable-libfdk_aac --enable-libfreetype --enable-libmp3lame --enable-libopus - enable-libvorbis --enable-libtheora --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree Libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat 58. 12.100 / 58. 12.100 libavdevice 58. 3.100 / 58. 3.100 libavfilter 7. 16.100 / 7. 16.100 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 libpostproc 55. 1.100 / 55. 1.100 Eingabe # 0, mov, mp4, m4a, 3gp, 3g2, mj2 von '/root/test/test.mov': Metadaten: major_brand: isom Nebenversion: 1 compatible_brands: isomavc1mp42 creation_time: 2016-11-03T20: 11: 18.000000Z Dauer: 00: 00: 09.33, Start: 0.000000, Bitrate: 20807 kb / s Stream # 0: 0 (und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p (tv, bt709), 1920x1080 [SAR 1: 1 DAR 16: 9], 20805 kb / s, 30 fps, 30 tbr, 30 tbn, 60 tbc (Standardeinstellung) Metadaten: creation_time: 2016-11-03T20: 11: 08.000000Z Stream-Mapping: Stream # 0: 0 -> # 0: 0 (h264 (native) -> h264 (libx264)) Drücken Sie die Taste [q], um zu stoppen [libx264 @ 0x2d05c40] mit SAR = 1/1 [libx264 @ 0x2d05c40] Frame-MB-Größe (120x68)> Grenzwert (1620) [libx264 @ 0x2d05c40] DPB-Größe (1 Frames, 3133440 Bytes)> Pegelbegrenzung (0 Frames, 3110400 Bytes) [libx264 @ 0x2d05c40] MB-Rate (244800)> Grenzwert (40500) [libx264 @ 0x2d05c40] mit CPU-Funktionen: keine! [libx264 @ 0x2d05c40] profile Eingeschränkte Basislinie, Ebene 3.0 [libx264 @ 0x2d05c40] 264 - Kern 120 r2151 a3f4407 - H.264 / MPEG-4 AVC-Codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - Optionen: cabac = 0 ref = 1 deblock = 1: 0: 0 analyse = 0x1: 0x111 me = umh subme = 8 psy = 1 psy_rd = 1,00: 0,00 mixed_ref = 0 me_range = 16 chroma_me = 1 spellis = 1 8x8dct = 0 cqm = 0 deadzone = 21,11 fast_pskip = 1 chroma_qp_offset = -2 Threads = 3 sliced_threads = 0 nr = 0 decimate = 1 interlaced = 0 bluray_compat = 0 constrained_intra = 0 bframes = 0 weightp = 0 keyint = 250 keyint_min = 25 scenecut = 40 intra_refresh = 0 rc_lookahead = 50 rc = crf = mbtree = 1 crf = 26,0 qcomp = 0,60 qpmin = 0 qpmax = 69 qpstep = 4 vbv_maxrate = 1500 vbv_bufsize = 3000 crf_max = 0,0 nal_hrd = kein ip_verhältnis = 1,40 aq = 1: 1,00 Ausgabe # 0, mp4 an '/root/test/out.mp4': Metadaten: major_brand: isom Nebenversion: 1 compatible_brands: isomavc1mp42 Drehgeber: Lavf58.12.100 Stream # 0: 0 (und): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1: 1 DAR 16: 9], q = -1-1, 30 fps, 15360 tbn, 30 tbc (default) Metadaten: creation_time: 2016-11-03T20: 11: 08.000000Z Encoder: Lavc58.18.100 libx264 Seitendaten: cpb: Bitrate max / min / Durchschnitt: 1500000/0/0 Puffergröße: 3000000 vbv_delay: -1 [mp4 @ 0x2d04680] Start des zweiten Durchlaufs: Bewegen des Moov-Atoms an den Anfang der Datei.0726x Rahmen = 280 fps = 2,3 q = -1,0 Lsize = 1865 kB Zeit = 00: 00: 09.30 Bitrate = 1642,5 kbit / s Geschwindigkeit = 0,0757x Video: 1863kB Audio: 0kB Untertitel: 0kB andere Streams: 0kB globale Header: 0kB Muxing-Overhead: 0.103491% [libx264 @ 0x2d05c40] Frame I: 2 Avg QP: 37.09 Größe: 36746 [libx264 @ 0x2d05c40] Frame P: 278 Avg QP: 38.97 Größe: 6594 [libx264 @ 0x2d05c40] mb I I16..4: 79.3% 0.0% 20.7% [libx264 @ 0x2d05c40] mb P I16..4: 0.6% 0.0% 0.2% P16..4: 17.3% 2.7% 1.5% 0.0% 0.0% Überspringen: 77.7% [libx264 @ 0x2d05c40] codiert: y, uvDC, uvAC intra: 30,9% 23,0% 0,2% inter: 3,0% 1,5% 0,0% [libx264 @ 0x2d05c40] i16 v, h, dc, p: 33% 28% 9% 31% [libx264 @ 0x2d05c40] i4 v, h, dc, ddl, ddr, vr, hd, vl, hu: 4% 4% 13% 16% 21% 14% 14% 8% 6% [libx264 @ 0x2d05c40] i8c Gleichstrom, h, v, p: 85% 8% 7% 1% [libx264 @ 0x2d05c40] kb / s: 1634.35 122,861 Sekunden bis zum Abschluss 

FFMpeg 2 - 32,378 Sekunden

[root @ staging test] # ./benchmark.sh Prozessor: 0 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 62 Modellname: Intel (R) Xeon (R) CPU E5-2620 v2 bei 2,10 GHz Treten: 4 Mikrocode: 1064 CPU-MHz: 2100.000 Cache-Größe: 15360 KB physikalische id: 0 Geschwister: 1 Kern-ID: 0 CPU-Kerne: 1 apicid: 0 Anfangsapicid: 0 fpu: ja fpu_exception: ja cpuid level: 13 wp: ja Fahnen: FPU vme de pse tsc msr PAE mce CX8 APIC sep mtrr PGE mca cmov pat PSE36 CLFLUSH dts MMX fxsr sse sse2 ss syscall nx rdtscp lm CONSTANT_TSC arch_perfmon PEBS bts xtopology tsc_reliable NONSTOP_TSC aperfmperf unfair_spinlock pni pclmulqdq SSSE3 CX16 PCID sse4_1 sse4_2 x2apic popcnt aes XSAVE avx f16c rdrand hypervisor lahf_lm arat epb xsaveopt pln pts dtherm pti retpoline fsgsbase smep Bogomips: 4200.00 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 40 Bit physisch, 48 Bit virtuell Energieverwaltung:  Prozessor: 1 vendor_id: GenuineIntel CPU-Familie: 6 Modell: 62 Modellname: Intel (R) Xeon (R) CPU E5-2620 v2 bei 2,10 GHz Treten: 4 Mikrocode: 1064 CPU-MHz: 2100.000 Cache-Größe: 15360 KB physikalische id: 2 Geschwister: 1 Kern-ID: 0 CPU-Kerne: 1 apicid: 2 ursprünglicher apicid: 2 fpu: ja fpu_exception: ja cpuid level: 13 wp: ja Fahnen: FPU vme de pse tsc msr PAE mce CX8 APIC sep mtrr PGE mca cmov pat PSE36 CLFLUSH dts MMX fxsr sse sse2 ss syscall nx rdtscp lm CONSTANT_TSC arch_perfmon PEBS bts xtopology tsc_reliable NONSTOP_TSC aperfmperf unfair_spinlock pni pclmulqdq SSSE3 CX16 PCID sse4_1 sse4_2 x2apic popcnt aes XSAVE avx f16c rdrand hypervisor lahf_lm arat epb xsaveopt pln pts dtherm pti retpoline fsgsbase smep Bogomips: 4200.00 Clflush Größe: 64 cache_alignment: 64 Adressgrößen: 40 Bit physisch, 48 Bit virtuell Energieverwaltung:  ffmpeg version 2.2.1 Copyright (c) 2000-2014 der FFmpeg-Entwickler gebaut am 13. April 2014 um 13:00:18 Uhr mit GCC 4.4.6 (GCC) 20120305 (Red Hat 4.4.6-4) Konfiguration: --prefix = / usr --libdir = / usr / lib64 --shlibdir = / usr / lib64 --mandir = / usr / share / man --enable-shared --enable-runtime-cpudetect --enable- gpl --enable-version3 --enable-postproc --enable-avfilter --enable-pthreads --enable-x11grab --enable-vdpau --disable-avisynth --enable-frei0r --enable-libopencv --enable- libdc1394 --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --extra-cflags = '- O2 -g -pipe -Wall -Wp, -D_FORTIFY_SOURCE = 2 -fexceptions - fstack-protector --param = ssp-buffer-size = 4 -m64 -mtune = generic -fPIC '--disable-stripping Libavutil 52. 66.100 / 52. 66.100 libavcodec 55. 52.102 / 55. 52.102 libavformat 55. 33.100 / 55. 33.100 libavdevice 55. 10.100 / 55. 10.100 libavfilter 4. 2.100 / 4. 2.100 libswscale 2. 5.102 / 2. 5.102 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Eingabe # 0, mov, mp4, m4a, 3gp, 3g2, mj2 von '/root/test/test.mov': Metadaten: major_brand: isom Nebenversion: 1 compatible_brands: isomavc1mp42 creation_time: 2016-11-03 20:11:18 Dauer: 00: 00: 09.33, Start: 0.000000, Bitrate: 20807 kb / s Stream # 0: 0 (und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p (tv, bt709), 1920x1080 [SAR 1: 1 DAR 16: 9], 20805 kb / s, 30 fps, 30 tbr, 30 tbn, 60 tbc (Standardeinstellung) Metadaten: creation_time: 2016-11-03 20:11:08 [libx264 @ 0x2139060] mit SAR = 1/1 [libx264 @ 0x2139060] Frame-MB-Größe (120x68)> Grenzwert (1620) [libx264 @ 0x2139060] DPB-Größe (5 Frames, 40800 MBit / s)> Grenzwert (0 Frames, 8100 MBit / s) [libx264 @ 0x2139060] MB-Rate (244800)> Pegelbegrenzung (40500) [libx264 @ 0x2139060] mit CPU-Funktionen: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 0x2139060] profile Eingeschränkte Basislinie, Ebene 3.0 [libx264 @ 0x2139060] 264 - Kern 142 - H.264 / MPEG-4 AVC-Codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - Optionen: cabac = 0 ref = 5 deblock = 1 : 0: 0 analyse = 0x1: 0x111 me = umh subme = 8 psy = 1 psy_rd = 1,00: 0,00 mixed_ref = 1 me_range = 16 chroma_me = 1 Gitter = 1 8x8dct = 0 cqm = 0 deadzone = 21,11 fast_pskip = 1 chroma_qp_offset = -2 Threads = 3 lookahead_threads = 1 sliced_threads = 0 nr = 0 dezimieren = 1 interlaced = 0 bluray_compat = 0 constrained_intra = 0 bframes = 0 weightp = 0 keyint = 250 keyint_min = 25 scenecut = 40 intra_refresh = 50 rc = crf mbtree = 1 crf = 26,0 qcomp = 0,60 qpmin = 0 qpmax = 69 qpstep = 4 vbv_maxrate = 1500 vbv_bufsize = 3000 crf_max = 0,0 nal_hrd = kein Füllstoff = 0 ip_ratio = 1,40 aq = 1: 1,00 Ausgabe # 0, mp4 an '/root/test/out.mp4': Metadaten: major_brand: isom Nebenversion: 1 compatible_brands: isomavc1mp42 Drehgeber: Lavf55.33.100 Stream # 0: 0 (und): Video: h264 (libx264) ([33] [0] [0] [0] / 0x0021), yuv420p, 1920x1080 [SAR 1: 1 DAR 16: 9], q = -1 - 1, max. 1500 kb / s, 15360 TB, 30 TB (Standard) Metadaten: creation_time: 2016-11-03 20:11:08 Stream-Mapping: Stream # 0: 0 -> # 0: 0 (h264 -> libx264) Drücken Sie die Taste [q], um zu stoppen [mp4 @ 0x21357e0] Start des zweiten Durchlaufs: Bewegen des Moov-Atoms an den Anfang der Datei Rahmen = 280 fps = 8,7 q = -1,0 Lsize = 1861 kB Zeit = 00: 00: 09,33 Bitrate = 1633,7 kbit / s Video: 1859kB Audio: 0kB Untertitel: 0 Daten: 0 globale Header: 0kB Multiplexing-Overhead 0.100889% [libx264 @ 0x2139060] Frame I: 2 Avg QP: 36.29 Größe: 46508 [libx264 @ 0x2139060] Frame P: 278 Avg QP: 38.34 Größe: 6512 [libx264 @ 0x2139060] mb I I16..4: 75.4% 0.0% 24.6% [libx264 @ 0x2139060] mb P I16..4: 0.5% 0.0% 0.2% P16..4: 18.6% 2.7% 1.8% 0.0% 0.0% Überspringen: 76.3% [libx264 @ 0x2139060] codiert y, uvDC, uvAC intra: 31,4% 22,8% 0,3% inter: 2,7% 1,1% 0,0% [libx264 @ 0x2139060] i16 v, h, dc, p: 33% 28% 9% 30% [libx264 @ 0x2139060] i4 v, h, dc, ddl, ddr, vr, hd, vl, hu: 4% 4% 13% 17% 20% 14% 14% 8% 6% [libx264 @ 0x2139060] i8c dc, h, v, p: 85% 7% 7% 1% [libx264 @ 0x2139060] ref P L0: 77,6% 9,9% 8,2% 1,8% 2,5% [libx264 @ 0x2139060] kb / s: 1631.45 32,378 Sekunden bis zum Abschluss 
1
Sind Sie sicher, dass Sie richtige Vergleiche zwischen Äpfeln und Äpfeln durchführen? Zum Beispiel gibt es zwei völlig unterschiedliche CPUs (Xeon vs. i7), und eine ist eindeutig für die Verwendung mehrerer Kerne konfiguriert, während eine nicht verwendet wird. Wurden die Vergleiche zwischen ffmpeg 4 und ffmpeg 2 in derselben VM auf demselben Host durchgeführt? jamesdlin vor 5 Jahren 0
Die CPUs unterscheiden sich ja - und das kann ein Faktor sein - die Vergleiche befinden sich jedoch auf demselben Host - und der Befehl ffmpeg wurde so eingestellt, dass er nur 1 Core verwendet. Im Vergleich dazu ist der Test auf denselben Maschinen im Xeon / VMware-Setup proportional langsamer als die lokale i7 / Virtualbox - die Anzahl der Kerne ist irreführend, und ich denke nicht, dass das gleiche Setup einen großen Unterschied ausmachen wird, aber ich werde sichergehen, dass dies der Fall ist (dh, wenn der Vergleich einer Version mit der anderen vergleichbar war) Maschine). Noch heute testen. aernative vor 5 Jahren 0
Ich habe einen Test für identische VMs hinzugefügt, um den Punkt zu demonstrieren - siehe die letzten zwei Tests auf VMWare mit voller Detailgenauigkeit, wenn bei alternativen Setups (Virtualbox) das Gegenteil erlebt wird. aernative vor 5 Jahren 0
Die vollständigen Ausgaben sind oben bereits gezeigt, der Befehl war ein einfacher Transcode eines mov zu mp4 für die Web-Wiedergabe - derselbe Befehl, der in beiden Tests verwendet wird. aernative vor 5 Jahren 0
`using cpu skills: none!` zeigt an, dass Ihre verknüpfte libx264 möglicherweise mit `--disable-asm` oder einem anderen Problem kompiliert wurde, was dazu führte, dass keine Assembly-Optimierungen verwendet wurden. LordNeckbeard vor 5 Jahren 0

1 Antwort auf die Frage

0
aernative

Beim Testen mit 4.0.2 ist das Problem verschwunden, während es jetzt etwas schneller ist als bei der lokalen Installation, aber wir können auf die CPU zurückgreifen.

Ich kann nur zu dem Schluss kommen, dass das, was die Verlangsamung verursacht hat, auf diese Version beschränkt war - (4.0.1).

Obwohl dies nicht die Antwort ist, was die Ursache war, da ein Update der Nebenversion das Problem behebt, sehe ich nicht das Problem, die Ursache zu finden.