mich treibt derzeit ein Phänomen beim Verarbeiten von Videos um. Unter OS X 10.8.3 dauert die Verarbeitung eines 20minütigen Videos mit FFMPEG 1.2 gut eine Stunde, auf meinem Notebook mit etwas schwächerer CPU unter Windows 8 Professional (64 Bit) nur halb so lange. Auch hier erfolgt die Verarbeitung mit FFMPEG. Die gleiche Datei wird auf meinem Hauptrechner, einen Windows 8 Professional (64 Bit) PC mit AMD Phenom II X4 955 CPU, mal eben in 15 Minuten verarbeitet.
Natürlich habe ich in meinem Mac Mini 5.1 von 2011 nur eine Intel DualCore CPU vom Typ Core i5 (I5-2415M), doch sollte diese CPU nicht schneller sein, als die CPU in meinem Notebook vom Typ Intel Core i3-350M?
Speicher hat der Mac Mini 5.1 satt, 16 GB sind eingebaut. Das Notebook hat nur 8 GB. Meines Wissens nutzt FFMPEG nur die CPU zum Verarbeiten. Die GPU ist also irrelevant.
Hat jemand ähnliche Erfahrungen gemacht? Oder wäre so nett, dass mal an der eigenen Hardware vergleichsweise zu überprüfen?
willkommen hier bei den Minis im Forum und noch viel Spaß mit dem :mmini: .
Deine Beobachtung verwundert mich nicht weiter. Die guten Mac Entwickler sind bei der Abspaltung von FFmpeg und Libav bei Libav gelandet. Wie nutzt du denn FFmpeg auf dem Mac? Mit Perian unter QuickTime (hoffentlich QuickTime Player Pro 7.7) direkt im Terminal oder mit der grafischen Oberfläche von ffmpeg.com (die ja nur bis Lion [10.7] optimiert ist, die letzte Version stammt von August 2011, entsprechend kann die Version ggf. mit den aktuellen Codec 1.2 möglicherweise nicht optimal umgehen - von Mountain Lion [10.8] ganz zu schweigen). Da hat die Grafik GUI von Windows/Linux WinFF natürlich Vorteile, sie ist angepasst von Win95 bis Win8 verfügbar. Meines Wissens wird 64bit von der Mac GUI noch gar nicht unterstützt.
Falls Du wirklich einen Vergleich der Hardwareleistung haben möchtest, solltest Du mit Bootcamp Windows 8 auf dem Mini installieren und mit der gleichen GUI arbeiten. Dann hast Du handfestere Vergleichswerte. Bis jetzt hast Du Äpfel mit Birnen verglichen.
Scheint also nichts ungewöhnliches zu sein? Dabei sollte doch der Mac als Arbeitspferd dienen. Nun ja.
Was genau meinst du mit “Die guten Mac Entwickler sind bei der Abspaltung von FFmpeg und Libav bei Libav gelandet.”? Den Satz verstehe ich nicht, sorry. Ich benutze die Kommandozeilenversion, die über das Macports-Repository herunterzuladen und zu kompilieren ist. Die ganzen GUIs sind irgendwie beschränkt im wahrsten Sinne des Wortes. Da benutze ich lieber FFMPEG selbst. Es funktioniert ja auch alles. Ich kann mit der gleichen Kommandofolge unter Windows und OS X das Video bearbeiten. Nur die Verarbeitungsgeschwindigkeit des gleichen Videos ist zu unterschiedlich auf den verschiedenen Systemen.
Natürlich habe ich Äpfel mit Birnen verglichen, darum geht es ja. Der Apfel ist größer als die Birne aber die Birne ist schneller…
Und das kann doch eigentlich nicht sein? Ich rede hier von durchschnittlich 70 Frames Verarbeitungsleistung auf meinem 4 Kern AMD Rechner, 30 Frames auf meinem i3-Notebook und 10 Frames auf dem i5-Mac Mini.
Dafür dann extra Bootcamp einzurichten, ist mir zu umständlich, zumal ich auf dem Mac Mini niemals Windows einsetzen möchte. Dafür habe ich 6 andere Rechner. Ich hatte gehofft, dass jemand mal vor einem ähnlichen Problem stand, dass er hoffentlich lösen konnte.
[quote=„surogat“]…
Was genau meinst du mit „Die guten Mac Entwickler sind bei der Abspaltung von FFmpeg und Libav bei Libav gelandet.“? Den Satz verstehe ich nicht, sorry.[/quote]
Wow, da beherrscht noch jemand Komandozeile - gut dann kann man die unterschiedlichen GUIs ja ausschließen.
[quote=„surogat“]Natürlich habe ich Äpfel mit Birnen verglichen, darum geht es ja. Der Apfel ist größer als die Birne aber die Birne ist schneller…
Und das kann doch eigentlich nicht sein? Ich rede hier von durchschnittlich 70 Frames Verarbeitungsleistung auf meinem 4 Kern AMD Rechner, 30 Frames auf meinem i3-Notebook und 10 Frames auf dem i5-Mac Mini.[/quote]
Wenn der AMD ein Desktop Rechner ist, wundert mich das nicht. Bei Intel bezeichnet man mit den unterschielichen Prozessorserien i3/i5/i7 mehr die Ausstattungsmerkmale eines Prozessors, als deren Geschwindigkeit, so kann es durchaus sein, das ein i3 Notbook den 2011er Mini mit i5 Prozessor schlägt, schließlich besteht dieser auch nur aus Notebook Technik und die Mac Mini i5 aus 2011 sind Dual Core Rechner (Quad-Core war nur der i7 Server, wenn ich mich richtig erinnere), Details im Wiki
Wenn dann ein i3 Notebook auf Performance getrimmt ist, kann das durchaus das Mac OS X 10.8.3 alt aussehen lassen - es haben hier schon Mitglieder ihren neuen Mini (Late 2012) zurückgehen lassen, weil ihnen die Performance des Minis mit Festplatte nicht ausreichte, es heißt, es wäre nur mit Combo Drive oder SSD erträglich - die verbauten Festplatten im Mini sind eher mittelmäßig.
Allerdings ist der Unterschied zum i3 Notebook schon erschrekend - wie hoch ist das denn getaktet?
Ich bin mir mit MacPorts nicht 100%ig sicher - gab es mit da nicht Probleme mit der 64bit Nutzung bei X11 (Apple selber hat ja ab 10.7 die Entwicklung eingestellt) oder einer nötigen Lib oder API abseits von XCode? Das würde natürlich den erheblichen Unterschied erklären, wenn man im Speicher bei Videobearbeitung nur 4 GB nutzen kann und der Prozessor mangels Datennachschub nur Däumchen dreht, müssen ja solche Ergebnisse herauskommen. Wäre vielleicht mal eine Spur um den Nachzugehen.
Na ja, um solche Kandidaten zu finden ist so ein Forum ja da und wenn man so mit Windows versorgt ist, würde ich das auch vom Mini fernhalten.
Ja, diese Frage stelle ich mir so in etwa derzeit. Man darf dabei nicht vergessen, dass FFMPEG die gleiche Codebasis benutzt. Es gibt keine extra OS X Version mit anderen Features.
[quote=„surogat“]…
Was genau meinst du mit „Die guten Mac Entwickler sind bei der Abspaltung von FFmpeg und Libav bei Libav gelandet.“? Den Satz verstehe ich nicht, sorry.[/quote]
Kein Problem, das kannst Du → hier ← nachlesen.[/quote]
Ach das meinst du. Jetzt verstehe ich den Satz erstmal.
Dabei dachte ich, dass es besser wäre bei FFMPEG und dessen Bibliotheken zu bleiben, weil der Hauptentwickler nun mal zu diesem Projekt gehört. Könnte natürlich nur für WIndows-Benutzer von Vorteil sein. So habe ich das bisher nicht betrachtet.
[quote=„chrispiac“]
[quote=„surogat“]Natürlich habe ich Äpfel mit Birnen verglichen, darum geht es ja. Der Apfel ist größer als die Birne aber die Birne ist schneller…
Und das kann doch eigentlich nicht sein? Ich rede hier von durchschnittlich 70 Frames Verarbeitungsleistung auf meinem 4 Kern AMD Rechner, 30 Frames auf meinem i3-Notebook und 10 Frames auf dem i5-Mac Mini.[/quote]
Allerdings ist der Unterschied zum i3 Notebook schon erschrekend - wie hoch ist das denn getaktet?[/quote]
Ungefähr so wie der i5 im Mac Mini. Also circa 2,3-2,6 GHz. Das ist es ja, dieser Unterschied ist einfach zu groß. Ich meine da geht es um Zeitunterschiede von 30-40 Minuten. Das dürfte so nicht sein.
X11 wäre nur bei einer GUI von Bedeutung.
FFMPEG ist als reines 64 Bit Kommandozeilenprogramm kompiliert, das war kein vorgefertigtes Binary. Auch die ganzen Bibliotheken wurden mit Xcodes Clang bei der Installation kompiliert. Ausserdem würde es bei langsamen Datennachschub eher stocken als kontinuierlich bei 9-10 Frames maximale Verarbeitungsleistung bleiben. Das ist für mich ganz klar, ein wesentlich ineffizienteres Encodieren als unter Windows.
Wenn mal jemand die Zeit und die Muße hat das in einer ähnlichen Konstallation zu testen, also gleiche Videodatei unter Windows und OS X encodieren, wären die Verarbeitungszeiten echt interessant.
Dies hier soll nur als Hilfestellung für Leute dienen, die nach einer Lösung für das gleiche Problem suchen.
Da leider niemand hier mit der Problematik vertraut war, musste ich natürlich zwangsweise selbst nach einer Lösung für das eingangs genannte Problem suchen. Und was soll ich sagen, ich habe eine gefunden.
Dort wird zwar die Kompilierung des avconv Forks von FFMPEG unter OS X besprochen, doch gelten die dort aufgezeigten Hilfestellungen auch für FFMPEG selbst. Es scheint so zu sein, dass der Macports Port nicht mit allen nötigen Flags installiert/kompiliert wird. Tatsächlich fehlen die CPU spezifischen Optimierungen. Was dann zu einer unterirdischen Verarbeitungsgeschwindigkeit führt.
Hat man über Macports FFMPEG installiert, muss man noch folgenden Macports Befehl auf der Kommandozeile eingeben, um x264 dazu zu bewegen, CPU spezifische Optimierungen zu verwenden:
sudo port upgrade --enforce-variants x264 +asm
Danach steigt die Verarbeitungsgeschwindigkeit von durchschnittlich 10 fps auf 40 fps, wie es für einen Intel i5 zu erwarten ist.
Hallo,
“sudo port upgrade --enforce-variants x264 +asm”
Ich bewege mich mit meinem Terminal ja schon in einer “Art Todesstreifen” aber Du!
Was wird mit dem o.g. denn genau eingeschaltet?
Gruß und Dank
Andreas
[quote=“SkobyMobil”]…
“sudo port upgrade --enforce-variants x264 +asm”
[/quote]
Bin mir nicht 100%ig sicher (hab’s gerade nicht vorliegen), MacPorts wurde mit dem Ziel entwickelt, möglichst einfach Portierungen aus dem Linux/Freeware Bereich auf den Mac zu übertragen. Da hat man möglichst auf allgemeine Unterstützung Wert gelegt.
x264 ist entweder die 2te Version der 64bit Unterstützung (würde meine irgendwo noch im Hinterkopf vorhandene Erinnerung auf 32bit Beschränkung erklären) oder die Dual-Core Unterstützung (halt x2… für Dual Core Code oder für beides Dual Core 64 bit Unterstützung). Es spezifiziert also den erzeugten Code auf bestimmte Maschinen und ist daher auf älteren Macs (PPC Macs sowieso nicht) nicht Ausführbar. ASM ist -sofern ich mich richtig erinnere - auch eine prozessorspezifische Eigenschaft (hab’s gerade auch nicht vorliegen, meine (a)syncron s? (m)emory), dient bei Mehrprozessorberechnungen dazu, das Ergebnisse die im einem Prozessorkern schon abgearbeitet wurden in einem prozessornahen Cache vorgehalten werden, bis die zugehörige Berechnung im anderen Kern abgeschlossen ist und zur Weiterbearbeitung entweder erneut in einen der Kerne zugeführt wird oder ins RAM zurückgeleitet wird. Das sorgt dafür, das der mit der Berechnung fertige Kern mit der nächsten Berechnung beginnen kann ohne auf den anderen Kern warten zu müssen. Das Beschleunigt das Mehrkernprozessing.
Daher wundere ich mich nicht, das mit diesen Parametern erzeugter Code auf einem i5 um einiges schneller läuft. Wahrscheinlich könnten mit weiteren Optionen noch mehr herausgekitzelt werden, wenn man die spezifischen Eigenschaften des Prozessors beim compilieren stärker Berücksichtigt. Allerdings wird der Code dann auf immer weniger Macs lauffähig sein.
Ich fürchte aber, das ich daneben gegriffen haben. x264 scheint eine Bibliothek für H.264 Unterstützung zu sein. Sorry, habe seit PPC nichts mehr selbstgebacken, da überfliege ich die Artikel zur Programmierung nur noch vereinzelnd.
@archie79muc
Mit dem Befehl werden CPU Optimierungen wie SSE4 und neuer in den Encodingprozess mit eingebunden. Intels Core Baureihe verfügt über eine ganze Reihe an Zusatzfunktionen, unter anderem auch über Funktionen zum beschleunigten Berechnen von Videodatenströmen, unabhängig von der GPU-Einheit. Die sind in dem MarPorts Port per Voreinstellung nicht aktiviert, warum auch immer.
@chrispiac
Genau, eine freie Bibliothek für den H264-Codec, der von FFMPEG verwendet wird.
Nein, Prozessorzezifische Erweiterungen kannst Du natürlich auch mit einem Core2Duo nutzen, nur mußt Du dazu Macport installieren + Anhang (wozu auch das aktuelle XCode, die ganzen zu dem FFMPEG gehörenden weiteren Programmbiblioteken etc.). Ich bin darauf gekommen, als ich surogats Link zum Superuserforum gefolgt bin (wie bei großen Programmierprojekten üblich alles in Englisch…
Man sollte aber ein wenig Erfahrung mit Programmierung mitbringen, sonst dürfte das wie Scotish Highlands (oder was ist die Entsprechung für Böhmische Dörfer ) klingen.
ja, ein bißchen bekannt sind die Böhmischen Dörfer, immerhin kommt da ein Teil meiner Verwandtschaft her und ein paar wesentliche Grundkenntnisse in Sachen Programmierung sind bekannt. Ich suche da halt mal wieder einen Anhaltspunkt für einsame Abende/Nächte. Und nur mit Google stochere ich da momentan bei Mac Ports noch zuviel in “trüben” Gewässern
