Compile ffmpeg, mplayer, mencoder with Xcode 5.1 or newer (Mavericks, ML)

ffmpeg hat ja z.b. auch runtime cpu detection…
 
Harry3 schrieb:
Habe es erst später gesehen, dass die Formulierung mehrdeutig ist. Ich compiliere auf dem Mac Mini (i7) und kann die statischen Binaries (ffmpeg, mplayer, mkvtoolnix, mpv, ...) in der Regel auf dem alten MBP auch nutzen.
Zum Vergrößern anklicken....
Das klappt definitiv nicht bei jeder Software, das kann ich dir jetzt schon sagen.
Außer natürlich du kompilierst mit dem kleinsten gemeinsamen Nenner, aber das scheint ja nicht der Fall.
 
Ist nicht x86_64 dieser kleinste gemeinsame Nenner? Bisher hatte ich eben mit den statischen Builds wenig Probleme.
 
Das Problem sind die Instruktionen, die ein SB i7 beherrscht, aber ein C2D nicht.
Optimiert der Compiler ordentlich für den i7, nutzt er andere Instruktionen als für den C2D, ggf. welche, die er gar nicht hat.
Das endet dann in fiesen Laufzeitfehlern, da es nur bemerkt wird, wenn der entsprechende Code auch versucht wird auszuführen.
 
Kaito schrieb:
Das Problem sind die Instruktionen, die ein SB i7 beherrscht, aber ein C2D nicht.
Optimiert der Compiler ordentlich für den i7, nutzt er andere Instruktionen als für den C2D, ggf. welche, die er gar nicht hat.
Das endet dann in fiesen Laufzeitfehlern, da es nur bemerkt wird, wenn der entsprechende Code auch versucht wird auszuführen.
Zum Vergrößern anklicken....
Glaube ich gerne, aber nutzt du irgendwelche Programme bei denen dieses vorkommt?
 
Jo, auf jeden Fall.
Ich kann sie dir jetzt nicht aufzählen, da ich es (aus diesem Grund) schon länger anders praktiziere, um genau das zu vermeiden.
In den meisten Fällen kam es in einer Dependency vor, welche dann das eigentliche Programm gleich mit in den Abgrund zog, aber das ist wohl nur aufgrund der höheren Anzahl an Dependencies im Vgl. zu den "Haupt"programmen so.
Ich hatte auch mal eine Python Version, in der ich ca. alle Features aktiviert hatte, welche dann auf meinem MBP crashte weil irgendeine der Dependencies ein Problem hatte.

Einst starb die Platte meines MBPs, welches ich mit einer Migeration von meinem Desktop wiederhergestellt hab. Der Migrationsassistent berücksichtigt auch Dinge in /usr/local, hat entsprechend meine selbst gebauten Sachen mit-kopiert, was mir damals recht war. Und während auch die meisten Programme funktionierten, einige taten es nicht und haben sich dann im Dienst verabschiedet.
Das war immer sehr ärgerlich, da man letztlich nie genau wusste, ob ein Programm nun funktioniert, oder ob man die fehlerhafte Stelle nur noch nicht gefunden hat. Letztlich hatte ich dann auf dem MBP alles neu kompiliert.
Damals hatte ich keine Ahnung was das Problem war, google führte mich dann zur Erkenntnis.

Binaries von einem C2D auf einem i7 funktionieren natürlich absolut problemlos (solange die richtigen SDKs verwendet werden), aber sind dann ggf. nicht so effizient/optimiert.

Spätestens seit dem Tag bin ich absolut auf der Seite von Paketmanagern. Kompilieren muss ich eh auf jeder Maschine (also zumindest auf den beiden, die ich hab), wieso also nicht den Prozess von einem Tool abnehmen lassen und mir das Leben erleichtern.
 
Es ist immer interessant wie unterschiedlich die Erfahrungen sind. Bei den von dir beschriebenen Problemen würde ich eher auf Probleme bei den Dependencies tippen. Gerade diese zusätzliche Fehlerdimension hat mich zu statischen Builds wechseln lassen. Und Paketmanager kenne ich eine ganze Weile, hatte aber bisher nie einen gefunden der zu meiner Zufriedenheit die für mich relevanten Anwendungen erzeugt - aktuell wird z.B. die mkvtoolnix-gui nicht gebaut.
 
Das hat nichts mit dem Status eines Programmes als Dependency zu tun, wenn es für sich alleine den selben Fehler produziert.
 
Erst mal Danke für die tolle Anleitung !

Anfängerfrage: ich benutzte seit längerem FFMPEG auf meinem Power PC und bin nun auf einen Intel Mac und Mavericks umgestiegen. Leider kam nun immer folgende Fehlermeldung im Terminal.
" 00004.MTS
-bash: /usr/local/bin/ffmpeg: Bad CPU type in executable"

Daraufhin habe ich neueste Xcode version runtergelassen und habe dann (allerdings alles über Terminaleingaben) deine Anleitung zum Neuaufsetzen von FFMPEG durchgeführt, uff...

Leider kommt trotzdem weiterhin diese Fehlermeldung.

Was muss ich anders machen, muss ich kompilierte/bin Dateien von der "Ram Disk" wo anders hin kopieren, FFMPEG anders anlegen, altes FFMPEG Dateien löschen (wo ?) ? bin ziemlich verzweifelt...

Gruß und Dank,
lank
 
Ich kam nicht ganz mit. Benutzt du die Binary auf dem Computer, auf dem du sie generiert hast?
 
@lank

Installiers doch einfach mit brew oder macports.
 
Ich hatte funktionierende ffmpeg Version auf meinem alten G5 (dort auch erstellt und kompiliert) und habe das komplette System dann mit festplattendienstprogramm auf einen Intel Mac Pro rübergezogen.

Dort hat das weiter funktioniert.

Nach Upgrade auf Mavericks 10.9 kam dann der CPU Fehler.

Hiernach hab ich neuestes Xcode installiert. Damit kenne ich mich aber nicht aus (ebensowenig kenne ich Brew oder macports).
Da ich kein Projekt in Xcode habe, habe ich ebenso keine settings geändert.

Mittels Terminal hab ich dann verschiedenstes ausprobiert. Insbesondere im Netz kursierende andere ffmpeg 'enabler' Sektionen, die das Problem beseitigen sollten.

Zuletzt diese detaillierte Anleitung.

Unter meinen Usernamen sind noch die alten ffmpeg u. Encoder Dateien.

Wenn ich ffmpeg im Terminal aufrufe, woher weiß er zB, dass der neue erstellt Code der 'RAM Disk' verwendet werden soll und nicht der alte Code verwandt wird ?

Vielen Dank für eure Hilfe,
Lank
 
Du musst die alten Binaries mit den neuen ersetzen.
 
Die frage ist nur wo: habe 3 Folder anzubieten:

Altes Xcode Verzeichnis: developer Folder / usr / bin
Neues xcode Verzeichnis: developer Folder / usr / bin
Benutzer Verzeichnis: dort hatte ich alte ffmpeg Installation sowie Folder für die Encoder angelegt (lame etc.): soll ich diese einfach mit den neu erstellten Foldern aus dem Compiler Verzeichnis der RAM Disk ersetzen ?

Oder muss ich die ausführdateien aus dem bin Folder der RAM Disk (wenn ja wohin) kopieren ?

Gruß dank,
Lank
 
Mit dem Kommando 'which' findest Du heraus, welches binary im aktuellen Pfad als erstes aufgerufen wird.
Wenn Du testen willst, ob eines Deiner binaries funktioniert (bzw. welches), kannst Du den vollen Pfad verwenden.
 
Eigentlich solltest du selbst wissen wo was liegt und eine Ordnung drin haben... besteht die nicht, könnten Altreste oder die falschen Dateien "inneinander greifen", was nur zu Problemen führt...
Die erzeugten Binaries und Bibliotheken musst du natürlich von der RAM Disk wieder runterholen, diese ist ja nur temporär.


Anbei Frage an Harry, wieso nur -j2? Dein Mini sollte doch 8 (virtuelle) Kerne haben? Die kannst du ruhig alle verwenden, HyperThreading greift hier wunderbar. Und wieso überhaupt eine RAM Disk? Beim Kompilieren war ich bislang noch nie I/O stalled. Okay, das linken mag noch profitieren, aber das ist ja eh der kleinste Teil des ganzen, aber nur dafür wäre mir die rumkopiererei zu blöd. ;)
 
Nach Ersetzen der alten ffmpeg bin Datei (hier hatte ich mit einigen der angegebenen Libs etwas Probleme beim konfigurieren von ffmpeg, libs wurden teilweise nicht gefunden) mit der neuen funktionierts nun wieder prima !

Besten Dank für eure Hilfe !!! :)
 
Kaito schrieb:
Anbei Frage an Harry, wieso nur -j2? Dein Mini sollte doch 8 (virtuelle) Kerne haben? Die kannst du ruhig alle verwenden, HyperThreading greift hier wunderbar. Und wieso überhaupt eine RAM Disk? Beim Kompilieren war ich bislang noch nie I/O stalled. Okay, das linken mag noch profitieren, aber das ist ja eh der kleinste Teil des ganzen, aber nur dafür wäre mir die rumkopiererei zu blöd. ;)
Zum Vergrößern anklicken....

Sorry für die verspätete Antwort, hatte gar nicht realisiert dass hier noch geschrieben wird.

Irgendwie hatte ich den Eindruck dass -j4 gar nicht so viel mehr bringt und ich wollte die Anleitung allgemein halten. Ramdisk weil ich einen sauberen und nicht zugemüllten /usr/local/-Ordner haben will. In meinem Script werden auch die von mir gewünschten Binaries automatisch in einen nach Datum benannten Ordner kopiert so dass ich da nichts manuell machen muss. Und wenn es bei größeren Projekten Probleme mit einzelnen Komponenten gibt, erstelle ich ich ein Image der Ramdisk und kann so bei der nächsten Gelegenheit genau an dieser Stelle weiterprobieren. Hat z.B. beim Compilieren von Mkvtoolnix sehr geholfen.
 
Zuletzt bearbeitet:
Doch doch, die Jobs skalieren praktisch linear mit der Anzahl deiner Kerne, auch auf einer HDD. Man sagt als Faustregel so -j <Anzahl Threads + 1>. Die Metaarbeit "dazwischen" wird natürlich nicht beschleunigt, wie das auspacken von Daten etc. Auch das linken profitiert nicht ganz so sehr, aber das Kompilieren ist ja ohnehin der Hauptteil.
Deine RAMDisk ist im Filesystem ein Ordner unter /Volumes. Ob dieser Ordner, in dem du arbeitest, nun ~/blubb oder /Volumes/blubb ist, ändert nichts am Grad der Zumüllung, da es das gleiche ist.

Das mit dem letzten Punkt (dem "weiter machen") hab ich nicht ganz verstanden. Klar, eine RAMDisk musst du irgendwie sichern, die ist sonst ja weg, aber ein "normaler" Ordner bleibt je mit all seinen Objektdateien bestehen, d.h. ein erneuter Start des ganzen macht genau da weiter, wo du aufgehört hast (nach einem eingänglichen Check ob die Objektdaten aktuell sind, aber das geht selbst auf einer HDD in nicht-relevanter Zeit).
 
Kaito schrieb:
Deine RAMDisk ist im Filesystem ein Ordner unter /Volumes. Ob dieser Ordner, in dem du arbeitest, nun ~/blubb oder /Volumes/blubb ist, ändert nichts am Grad der Zumüllung, da es das gleiche ist.
Zum Vergrößern anklicken....
Es ist einfach eine persönliche Vorliebe für die Variante mit der Ramdisk, denn es ist mit Sicherheit die schnellste Variante (ob es große Unterschiede gibt sei dahingestellt), es ist die für mich bequemste Variante und für eine Anleitung auch eher einfach zu beschreiben/löschen denn mit dem Auswerfen der Ramdisk sind alle ungewollten Dateien einfach wieder weg. Nachteile sehe ich überhaupt nicht, daher verstehe ich das Hinterfragen dieses Aspekts nicht so wirklich.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten