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

H

Harry3

unregistriert
Thread Starter
Dabei seit
19.04.2014
Beiträge
157
Reaktionspunkte
0
Diese Anleitung ist eine Weiterentwicklung der Anleitung hier funktioniert aber auch mit aktuellem Xcode.

Vorbereitung: folgende Dateien runterladen (etliche ändern sich sehr selten)
amrnb-7.0.0.2.tar.bz2, amrwb-7.0.0.4.tar.bz2, bzip2-1.0.6.tar.gz, cmake-2.8.12.1.tar.gz, faac-1.28.tar.gz, faad2-2.7.tar.gz, fdk-aac-0.1.3.tar.gz, flac-1.3.0.tar, georgmartius-vid.stab-release-0.98b-0-g3b35b4d.tar.gz, git-1.9.0.tar.gz, gsm-1.0.13.tar.gz, lame-3.99.5.tar.gz, libilbc-master.zip, libogg-1.3.1.tar.gz, libtheora-1.1.1.tar.bz2, libvorbis-1.3.4.tar.gz, libvpx-v1.3.0.tar.bz2, openal-soft-1.13.tar.bz2, openal-soft-1.15.1.tar.bz2, opencore-amr-0.1.3.tar.gz, opus-1.1.tar.gz, pkg-config-0.28.tar.gz, soxr-0.1.1-Source.tar, speex-1.2rc1.tar.gz, twolame-0.3.13.tar.gz, vo-aacenc-0.1.3.tar.gz, vo-amrwbenc-0.1.3.tar.gz, wavpack-4.70.0.tar.bz2, xvidcore-1.3.2.tar.gz, yasm-1.2.0.tar.gz, zeromq-3.2.4.tar.gz, zlib-1.2.8.tar.gz

Zuerst eine Ramdisk mit 2GB anlegen und ein paar Umgebungsvariablen setzen.

Code:
VOLNAME=Ramdisk
DISK_ID=$(hdid -nomount ram://4194304)
newfs_hfs -v ${VOLNAME} ${DISK_ID}
diskutil mount ${DISK_ID}

export TARGET="/Volumes/${VOLNAME}/"
export CMPL="/Volumes/${VOLNAME}/compile"
export PATH=${TARGET}/bin:$PATH
export CC="clang"
export CPP="clang -E"
export CXX="clang++"
export CXXCPP="clang++ -E"
export LDFLAGS="-stdlib=libc++"
export CXXFLAGS="-stdlib=libc++"
mkdir ${CMPL}
Jetzt auf der Ramdisk einen Ordner "source" erstellen und alle Dateien hinkopieren.
Code:
# Building xvidcore and removing the dynamic library
cd ${CMPL}
tar xzpf ../source/xvidcore-1.3.2.tar.gz
cd xvidcore
cd build/generic
./configure --prefix=${TARGET}
make -j 2 && make install
rm ${TARGET}/lib/libxvidcore.4.dylib

# yasm
cd ${CMPL}
tar xzpf ../source/yasm-1.2.0.tar.gz
cd yasm-1.2.0
./configure --prefix=${TARGET}
make -j 2 && make install

# pkg-config
cd ${CMPL} 
tar xzpf ../source/pkg-config-0.28.tar.gz
cd pkg-config-0.28
./configure --prefix=${TARGET} --with-pc-path=${TARGET}/lib/pkgconfig --with-internal-glib 
make -j 2 && make install

# git
cd ${CMPL}
tar xzpf ../source/git-1.9.0.tar.gz
cd git-1.9.0
./configure --prefix=${TARGET}/git --with-iconv=/Volumes/Ramdisk
make && make install

# wavpack
cd ${CMPL}
tar xjpf ../source/wavpack-4.70.0.tar.bz2
cd wavpack-4.70.0
./configure --prefix=${TARGET} --enable-static --disable-shared --with-iconv=/usr/
make -j 2 && make install

# lame
cd ${CMPL}
tar xzpf ../source/lame-3.99.5.tar.gz
cd lame-3.99.5
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# faac
cd ${CMPL}
tar xzpf ../source/faac-1.28.tar.gz
cd faac-1.28
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# faad
cd ${CMPL}
tar xjpf ../source/faad2-2.7.tar.gz
cd faad2-2.7
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# x264
cd ${CMPL}
curl -O ftp://ftp.videolan.org/pub/videolan/x264/snapshots/last_stable_x264.tar.bz2
tar xjpf last_stable_x264.tar.bz2
cd x264*stable 
./configure --prefix=${TARGET} --disable-shared --enable-static 
make -j 2 && make install && make install-lib-static

# ogg
cd ${CMPL}
tar xzpf ../source/libogg-1.3.1.tar.gz
cd libogg-1.3.1
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# vorbis
cd ${CMPL}
tar xzpf ../source/libvorbis-1.3.4.tar.gz
cd libvorbis-1.3.4
./configure --prefix=${TARGET} --with-ogg-libraries=${TARGET}/lib --with-ogg-includes=${TARGET}/include/ --enable-static --disable-shared
make -j 2 && make install

# theora
cd ${CMPL}
tar xjpf ../source/libtheora-1.1.1.tar.bz2
cd libtheora-1.1.1
# in order to compile with Xcode 5.1 
perl -p -i -e "s/-falign-loops=16//g" configure
perl -p -i -e "s/-fforce-addr//g"     configure
./configure --prefix=${TARGET} --disable-asm --with-ogg-libraries=${TARGET}/lib --with-ogg-includes=${TARGET}/include/ --with-vorbis-libraries=${TARGET}/lib --with-vorbis-includes=${TARGET}/include/ --enable-static --disable-shared
make -j 2 && make install

# libopus
cd ${CMPL}
tar xjpf ../source/opus-1.1.tar.gz
cd opus-1.1
./configure --prefix=${TARGET} --disable-shared --enable-static 
make -j 2 && make install

# gsm
cd ${CMPL}
tar xzpf ../source/gsm-1.0.13.tar.gz
cd gsm-1.0-pl13
mkdir -p ${TARGET}/man/man3
mkdir -p ${TARGET}/man/man1
mkdir -p ${TARGET}/include/gsm
perl -p -i -e  "s#^INSTALL_ROOT.*#INSTALL_ROOT = $TARGET#g"  Makefile
perl -p -i -e  "s#_ROOT\)/inc#_ROOT\)/include#g"             Makefile
sed "/GSM_INSTALL_INC/s/include/include\/gsm/g"              Makefile > Makefile.new
mv Makefile.new Makefile
make -j 2 && make install

# amrwb
cd ${CMPL}
tar xjpf ../source/amrwb-7.0.0.4.tar.bz2
cd amrwb-7.0.0.4
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# amrnb downloads additional sources
cd ${CMPL}
tar xjpf ../source/amrnb-7.0.0.2.tar.bz2
cd amrnb-7.0.0.2
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# opencore_amr
cd ${CMPL}
tar xzpf ../source/opencore-amr-0.1.3.tar.gz
cd opencore-amr-0.1.3
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# speex
cd ${CMPL}
tar xzpf ../source/speex-1.2rc1.tar.gz
cd speex-1.2rc1
./configure --prefix=${TARGET} --with-ogg-libraries=${TARGET}/lib --with-ogg-includes=${TARGET}/include/ --enable-static --disable-shared
make -j 2 && make install

# flac
cd ${CMPL}
tar xpf ../source/flac-1.3.0.tar
cd flac-1.3.0
./configure --prefix=${TARGET} --disable-asm-optimizations --disable-xmms-plugin --with-ogg-libraries=${TARGET}/lib --with-ogg-includes=${TARGET}/include/ --enable-static --disable-shared
make -j 2 && make install

# xavs
cd ${CMPL}
svn co https://svn.code.sf.net/p/xavs/code/ xavs
cd xavs/trunk
# in order to compile with Xcode 5.1 
perl -p -i -e "s/-falign-loops=16//g" configure
perl -p -i -e "s/-fforce-addr//g"     configure
./configure --prefix=${TARGET} --disable-asm
make -j 2  && make install

# vo-aacenc
cd ${CMPL} 
tar xzpf ../source/vo-aacenc-0.1.3.tar.gz
cd vo-aacenc-0.1.3
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2  && make install

# vo-amrwbenc
cd ${CMPL} 
tar xzpf ../source/vo-amrwbenc-0.1.3.tar.gz
cd vo-amrwbenc-0.1.3
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2  && make install

# libvpx
cd ${CMPL} 
tar xjpf ../source/libvpx-v1.3.0.tar.bz2
cd libvpx-v1.3.0
./configure --prefix=${TARGET} --as=yasm --disable-shared --enable-static --enable-vp8
make -j 2 && make install

# fdk-aac
cd ${CMPL} 
tar xzpf ../source/fdk-aac-0.1.3.tar.gz
cd fdk-aac-0.1.3
./configure --prefix=${TARGET} --enable-static --disable-shared
make -j 2 && make install

# twolame
cd ${CMPL} 
tar xzpf ../source/twolame-0.3.13.tar.gz
cd twolame-0.3.13 
./configure --prefix=${TARGET} --disable-shared --enable-static
make -j 2 && make install

# libutvideo
cd ${CMPL}
git clone https://github.com/qyot27/libutvideo
cd libutvideo
./configure --prefix=${TARGET}
make -j 2 && make install

# zeromq
cd ${CMPL}
tar xzpf ../source/zeromq-3.2.4.tar.gz
cd zeromq-3.2.4
./configure --without-documentation --prefix=${TARGET} --enable-static --disable-shared 
make -j 2 && make install

# cmake
cd ${CMPL}
tar xzpf ../source/cmake-2.8.12.1.tar.gz
cd cmake-2.8.12.1
./configure --prefix=${TARGET}
make -j 2 && make install

# OpenAl
cd ${CMPL}
tar xjpf ../source/openal-soft-1.13.tar.bz2
cd openal-soft-1.13
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DLIBTYPE=STATIC .
make -j 2 && make install

# libsoxr
cd ${CMPL}
tar xpf ../source/soxr-0.1.1-Source.tar
cd soxr-0.1.1-Source
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DBUILD_SHARED_LIBS=OFF .
make -j 2 && make install

# libvidstab
cd ${CMPL}
tar xzpf ../source/georgmartius-vid.stab-release*
cd georgmartius-vid.stab*
perl -p -i -e 's/vidstab SHARED/vidstab STATIC/' CMakeLists.txt
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET}  .
make -j 2 && make install

# libilbc
cd ${CMPL}
unzip -a ../source/libilbc-master.zip
cd libilbc-master
sed '/TARGETS/s/ ilbc / /' CMakeLists.txt >CMakeLists.txt.new
mv CMakeLists.txt.new CMakeLists.txt
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} .
make -j 2 && make install

# zlib
cd ${CMPL}
tar xzpf ../source/zlib-1.2.8.tar.gz
cd zlib-1.2.8
./configure --prefix=${TARGET} --static
make -j 2 && make install

# bzip2
cd ${CMPL}
tar xzpf ../source/bzip2-1.0.6.tar.gz
cd bzip2-1.0.6
make
make install PREFIX=${TARGET}

# Building FFMPEG
cd ${CMPL} 
curl -O http://www.ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2
tar xjpf ffmpeg-snapshot.tar.bz2
cd ffmpeg 
export LDFLAGS="-L${TARGET}/lib $CFLAGS"
export  CFLAGS="-I${TARGET}/include $LDFLAGS"
# utvideo, limzmq not enabled
./configure --prefix=${TARGET} --as=yasm --disable-shared --disable-ffplay --enable-static --disable-ffserver --enable-gpl --enable-pthreads --enable-postproc --enable-gray --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-libspeex --enable-bzlib --enable-zlib --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libxavs --enable-nonfree --enable-version3 --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvpx --enable-libgsm --enable-libopus --enable-libtwolame --enable-openal --enable-libsoxr  --enable-libfdk-aac --enable-libwavpack --enable-libvidstab --enable-libilbc --enable-runtime-cpudetect
make -j 2 && make install

# Building Mplayer/Mencoder
cd ${CMPL}
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
cd mplayer
./configure --prefix=${TARGET} --extra-cflags="-I${TARGET}/include/" --extra-ldflags="-L${TARGET}/lib"
make -j 2 && make install

Auf einem Mac Mini (i7) läuft ein persönliches Shell-Script das alles compiliert in weniger als 15 Minuten komplett durch und am Ende befinden sich die Binaries in dem bin-Unterordner auf der Ramdisk.
 
Blöde Frage... warum nutzt man dafür nicht MacPorts oder Homebrew? Also was macht deine Variante jetzt genau besser?
 
Blöde Frage... warum nutzt man dafür nicht MacPorts oder Homebrew? Also was macht deine Variante jetzt genau besser?
Besser ist dass

- man das reincompilieren kann was man will
- man es mit aktuellem Xcode compilieren kann
- man nicht auf ports warten muss, falls es sie überhaupt gibt. Mkvtoolnix gab es über 1 Jahr gar nicht (und gibt es immer noch nicht), die Anleitung werde ich demnächst posten.
- man sich nicht das ganze System zumüllt. Hier werden statische Programme erzeugt, die man nach /usr/local/bin kopieren kann und mehr braucht man nicht.

Aber letztendlich muss es jeder selber wissen, denn ich nenne nur eine Option. ;) Mein Shell-Script braucht ca. 15 Mins um mir eine tagesaktuelle ffmpeg-Version zu erzeugen, mit den Systemen wie Brew, Mac Ports, ... warte ich teilweise Monate.
 
- man das reincompilieren kann was man will
- man es mit aktuellem Xcode compilieren kann
- man nicht auf ports warten muss, falls es sie überhaupt gibt. Mkvtoolnix gab es über 1 Jahr gar nicht (und gibt es immer noch nicht), die Anleitung werde ich demnächst posten.
- man sich nicht das ganze System zumüllt. Hier werden statische Programme erzeugt, die man nach /usr/local/bin kopieren kann und mehr braucht man nicht.
- kann ich mit brew auch, selbst wenn er eine Option nicht anbietet, genügen 1-2 Zeilen um das zu ändern
- macht brew per default sowieso
- die hier genannten Dinge sind in brew aktuell enthalten, selbst wenn nicht, hast du mit gefühlt 5 Zeilen Code eine Formel gebastelt, die mit der sauberen Buildumgebung von brew dein Zeug kompiliert [0]
- ich behaupte das Gegenteil: gerade damit müllst du das System zu, da du keine richtige Möglichkeit der Organisation hast. Brew beispielsweiße packt jedes Programm (bzw. jede Version davon) in seinen eigenen Prefix—ein löschen des Ordners entfernt absolut alles, auch manpages und andere shared Reste. Ob ich mir die Sachen in den Pfad linken will, kann ich jederzeit frei entscheiden und natürlich rückgängig machen.

Nur deinen resultierenden bin Ordner zu kopieren genügt nicht, da du dann weder manpages noch sonst etwas hast (shared Skripte etc., z.b. quvi). Wenn du all diese Dinge doch mitkopierst, musst du penibel Buch darüber führen, wer was wo hinpackt, um sie jemals wieder sauber entfernen zu können.
Die static Sache ist ansich ja für ein Vorhaben ganz nett, aber was, wenn du zig Dinge hast, die auf ffmpeg dependen? Es jedes mal aufs neue zu kompilieren und für jedes upzugraden wäre mir zu blöd. Dynamisch hat schon auch seinen Nutzen.

Früher hab ich das ja auch so gemacht. Erst hat man sich alle nötigen Dinger per Hand kompiliert, irgendwann hat man Skripte geschrieben, die wiederum die Buildsysteme der jeweiligen Programme nutzen, damit gleich Dependencies mitversorgt etc.pp. Aber irgendwann, mit einer stetig wachsenden Anzahl an Programmen—durch Dependencies sicher ein paar hundert (alleine dein eines Skript kommt ja schon auf ~34)—wird nicht nur der Overhead an "Arbeit" unzumutbar, es wird auch immer unsauberer, weil es einfach nicht möglich ist, eine jede einzelne Datei von ein paar hundert Programmen zu tracken, sofern man keine Listen pflegt.
Da wünscht man sich dann schon etwas, das einem hier unter die Arme greift, vor allem, wenn es dann auch noch darum geht, all diese Programme aktuell zu halten. Von dem Spaß, der beginnt, wenn man für verschiedene Programme verschiedene Versionen des gleichen Programms braucht, haben wir dabei noch gar nicht geredet.

Mein Shell-Script braucht ca. 15 Mins um mir eine tagesaktuelle ffmpeg-Version zu erzeugen, mit den Systemen wie Brew, Mac Ports, ... warte ich teilweise Monate.
Dass beides nichts miteinander zu tun hat, ist dir hoffentlich klar. Mein brew lässt clang jedenfalls nicht langsamer arbeiten, als er es "per Hand" gespawned täte. ;) [1]


Ich sehe, dass du x264 mit drin hast, aber nur einmal. Die Sache ist die: x264 kann von ffmpeg genutzt werden und selbst ffmpeg nutzen. Du solltest daher zuerst x264 kompilieren, anschließend ffmpeg und danach nochmal x264, sodass sie sich beidseitig linken können. Das ist hauptsächlich relevant, wenn du damit encodieren willst, aber wenn nicht wäre die Dependency selbst ja schon unnötig.

Des weiteren würde ich dir mpv empfehlen. Sofern du deinen Videoplayer nicht gerade auf einem Toaster laufen lässt, solltest du hier nur Vorzüge haben (gerade unter OSX—natives OpenGL Backend und so Späße).
https://github.com/mpv-player/mpv
https://github.com/mpv-player/mpv/blob/master/DOCS/man/en/changes.rst
Das Kompilieren via https://github.com/mpv-player/homebrew-mpv inkorporiert dabei noch eine für OSX gepatchte Version von libass, welche das unsägliche Hashen aller Fonts durch fontconfig extrem reduziert.


[0] Etwas das ich immer mehr zu schätzen weiß. Umso mehr Zeug du in deinem Pfad ansammelst—ganz egal wie du es kompiliert hast—umso "gefährlicher" droht das Kompilieren einer neuen Sache zu scheitern. Brew erzeugt beim Kompilierprozess darum eine völlig leere Umgebung für den Prozess: nichts störendes wird mehr gesehen. Was das jeweilige Buildskript (zu welchem Zeitpunkt in welcher Version) sehen darf, kann ich mittels weniger Worte Ruby definieren. Das ist einfach wunderbar, weshalb ich zunehmend immer mehr auf brew als mein "Framework" zum bauen von Dingen setze. Die Sache hat noch den Vorteil, dass ich durch den Austausch einer kleinen Ruby Datei gleich noch anderen ermöglichen kann, das eben gebaute praktisch zu "one-click-compilen".

[1] Das enthält natürlich nicht die Dependencies, aber die sind zum einen sowieso da, ich muss sie also eh nur neu kompilieren, wenn es mal ein Update gab, zum anderen dauert das Laden länger als das Kompilieren selbst.
Code:
[...] brew install ffmpeg mit meinen Optiönchen
/usr/local/Cellar/ffmpeg/2.2.1: 192 files, 38M, built in 91 seconds
$ which ffmpeg
/usr/local/bin/ffmpeg
$ ffmpeg
ffmpeg version 2.2.1 Copyright (c) 2000-2014 the FFmpeg developers
  built on Apr 27 2014 00:52:35 with Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.2.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=clang --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-libfreetype --enable-libtheora --enable-libvorbis --enable-libvpx --enable-librtmp --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-aacenc --enable-libass --enable-ffplay --enable-libspeex --enable-libschroedinger --enable-libfdk-aac --enable-openssl --enable-libopus --enable-frei0r --enable-libcaca --enable-libquvi --enable-libvidstab --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1_1/include/openjpeg-1.5 '

Ich habe Macports nicht lang genug genutzt, um es hier anführen zu können, nehme aber einfach mal an, die Entwicklung stand dort auch nicht still.
Mir gefällt lediglich deren Philosophie "alles selbst neu bauen, egal ob schon in OSX vorhanden" nicht.
 
Zuletzt bearbeitet:
@ Kaito

Danke für deinen sehr informativen Beitrag. Mir geht es in keinster Weise gegen Brew, Mac Ports, ... Im Gegenteil hoffe ich ja dass z.B. mkvtoolnix bald verfügbar sein wird. Meine sehr lange Erfahrung ist halt, dass ich eben auf Programme die mir wichtig waren, teils sehr lange warten musste. Mktvtoolnix war eben auch ein Jahr nicht verfügbar.

Zu statisch vs dynamisch: bei ffmpeg ist es relativ gleich, so lange man es nicht in anderen Tools nutzen will. Bei mkvtoolinx dagegen hatte ich richtig Probleme mit dem dynamischen Build und den Pfaden als ich versucht hatte ein Application Bundle zu erzeugen. Natürlich weiß ich dass man den Pfad ändern kann, der Aufwand war aber nicht unerheblich. Daher bleibe ich in der Regel bei statischen Builds da ich diese auch sofort auf andere Mac kopieren und nutzen kann.

Ich sehe, dass du x264 mit drin hast, aber nur einmal. Die Sache ist die: x264 kann von ffmpeg genutzt werden und selbst ffmpeg nutzen. Du solltest daher zuerst x264 kompilieren, anschließend ffmpeg und danach nochmal x264, sodass sie sich beidseitig linken können. Das ist hauptsächlich relevant, wenn du damit encodieren willst, aber wenn nicht wäre die Dependency selbst ja schon unnötig.
Das braucht man doch nur wenn man mit x264 kodieren will und nicht unbedingt wenn man mit ffmpeg (aber x264) als encoder kodieren will. Oder habe ich was falsch verstanden?
Des weiteren würde ich dir mpv empfehlen. Sofern du deinen Videoplayer nicht gerade auf einem Toaster laufen lässt, solltest du hier nur Vorzüge haben (gerade unter OSX—natives OpenGL Backend und so Späße).
https://github.com/mpv-player/mpv
https://github.com/mpv-player/mpv/blob/master/DOCS/man/en/changes.rst
Das Kompilieren via https://github.com/mpv-player/homebrew-mpv inkorporiert dabei noch eine für OSX gepatchte Version von libass, welche das unsägliche Hashen aller Fonts durch fontconfig extrem reduziert.
Habe mplayer hauptsächlich mit angeführt weil er beim compilieren von mencoder eben mit compiliert wurde. VLC und auch MplayerX sind mir natürlich lieber als mplayer.

gibt doch wieder eine aktuelle fertige app:
http://jonthn.free.fr/MKVtoolnix/

das hauptproblem bei macports und mkvtoolnix war halt lange der compiler von Xcode, da fehlte halt der C++11 support.
Der Build hat noch das Problem dass mkvmerge nicht gefunden wird, was dort durch einen vollständigen Pfad gelöst wird. Im GIT wurde schon die Änderung eingearbeitet so dass mkvmerge auf dem Mac automatisch im Application Bundle gesucht wird, wenn man in den Optionen nur "mkvmerge" eingibt. So kann man in Zukunft verschiedene Mkvoolnix-Versionen nutzen und muss auch mkvmerge nicht nach /usr/local/bin kopieren sondern kann die App einfach mac-like nutzen.

Interessanterweise gab es ziemlich genau 1 Jahr keinen aktuellen Build. Nachdem ich hier im Forum geschrieben hatte dass es mit clang und statisch geht, gab es 2 Tage später einen statischen Build. Aber das ist ja auch genau meine Ziel: Informationen verbreiten in der Hoffnung dass es dann entsprechende Versionen bei Brew, Mac Ports oder auch eigene Builds gibt.

Die Information zum fehlenden C++11-Support (z.B. Initializer lists) ist so nicht richtig. Richtig ist dass gcc erst ab 4.7.1 (meine ich) die entsprechenden C++11-Libraries unterstützt, Clang/LLVM dagegen schon seit Version 3.1 und laut Wikipedia ist Clang/LLVM 3.1 schon seit Xcode 3.0 dabei.
 
Das braucht man doch nur wenn man mit x264 kodieren will und nicht unbedingt wenn man mit ffmpeg (aber x264) als encoder kodieren will. Oder habe ich was falsch verstanden?
Den habe ich mit "damit" in meinem Satz gemeint. :)

Habe mplayer hauptsächlich mit angeführt weil er beim compilieren von mencoder eben mit compiliert wurde. VLC und auch MplayerX sind mir natürlich lieber als mplayer.
Das ändert nichts, da MplayerX selbst nur eine (sehr alte) mplayer Binardy nutzt und dabei auf OSX nicht einmal das Farbmanagement richtig bekommt (die ausgegegeben Farben sind inkorrekt). mpv ist die aktuell beste Wahl bezüglich Qualität und Performance.

Mkvtoolnix ist in brew übrigens seit über 4 Jahren enthalten. Das ist so ungefähr die Zeit, in der das Programm (also brew) erst entstanden ist, die Community sich also erst im Aufbau befand. Dinge, die nicht in den Repos sind, kann man sich mit einer kleinen Formel ja einfach selbst bauen, so mach ich das z.B. und für die meisten Sachen ist das erstaunlich einfach (Formel für die libStorm, die ich nutze). Hierbei profitiert man stark von der, von brew erzeugten, "sauberen" Umgebung, wodurch man nicht darauf achten muss, was so in seinen Pfaden rumfliegt. Man kann auch Dinge, die man gänzlich selbst gebaut hat, zur Verwaltung an brew übergeben, in dem man blos den Ordner, in den man das Programm kompiliert hat (--prefix) in brews Cellar schiebt.
 
Die Information zum fehlenden C++11-Support (z.B. Initializer lists) ist so nicht richtig. Richtig ist dass gcc erst ab 4.7.1 (meine ich) die entsprechenden C++11-Libraries unterstützt, Clang/LLVM dagegen schon seit Version 3.1 und laut Wikipedia ist Clang/LLVM 3.1 schon seit Xcode 3.0 dabei.

naja, mit Xcode 3.0 und dessen LLVM ging das compilieren nicht, gab immer einen fehler wegen fehlenden C++11 support (bzw C++0x stand da noch).
klappte erst ab Xcode 5 und LLVM 3.3…
 
Mkvtoolnix ist in brew übrigens seit über 4 Jahren enthalten.
Hatte es via Brew probiert und da der Vorgang mit einem Fehler abgebrochen wurde, nicht mehr weiter verfolgt. Selbst wenn es via Brew funktioniert, was ganz offensichtlich bei etlichen Leuten der Fall ist, werden nur die CLI-Tools erstellt aber nicht die GUI (mmg) die wxwidgets nutzt.

Werde aber das nächste Mal nicht so schnell aufgeben wenn ich mal Brew probieren sollte.

naja, mit Xcode 3.0 und dessen LLVM ging das compilieren nicht, gab immer einen fehler wegen fehlenden C++11 support (bzw C++0x stand da noch).
klappte erst ab Xcode 5 und LLVM 3.3…

Hatte nur nachgeschaut wann manche Funktionen die mkvtoolnix nutzt von LLVM unterstützt wurden und via Wikipedia geschlussfolgert, was wie man sieht nicht immer genaue Ergebnisse liefert. Daher danke für die Klarstellung.
 
Ich finde es sehr gut, dass Du die Anleitung gepostet hast.
Kommt leider viel zu selten vor, dass Leute bereit sind, Ihre Erfahrungen zu teilen.

Dass es auch andere Wege zum Ziel gibt, tut der Sache keinen Abbruch, zumal man die Vorgehensweise an sich auch auf andere Aufgaben übertragen kann.

Gruß
maceis
 
Hatte es via Brew probiert und da der Vorgang mit einem Fehler abgebrochen wurde, nicht mehr weiter verfolgt. Selbst wenn es via Brew funktioniert, was ganz offensichtlich bei etlichen Leuten der Fall ist, werden nur die CLI-Tools erstellt aber nicht die GUI (mmg) die wxwidgets nutzt.
Das stimmt natürlich, aber die App Bundles kann man sich ja von der Seite laden.
 
Ich finde es sehr gut, dass Du die Anleitung gepostet hast.
Kommt leider viel zu selten vor, dass Leute bereit sind, Ihre Erfahrungen zu teilen.
Im Prinzip ist es auch ein kleines bisschen egoistisch denn so hoffe ich dass manch andere ähnliche Erfahrungen mit anderen Projekten posten und ich so auch was davon habe. ;)
Dass es auch andere Wege zum Ziel gibt, tut der Sache keinen Abbruch, zumal man die Vorgehensweise an sich auch auf andere Aufgaben übertragen kann.
Wie erwähnt ist der Build von ffmpeg sehr eng an die Anleitung im oben angeführten Link angelehnt, mit ein paar Modifikationen so dass hier alles via Skript und unter 10.8 mit allerneuestem Xcode funktioniert.
Das stimmt natürlich, aber die App Bundles kann man sich ja von der Seite laden.
Leider nicht, denn man muss mmg (die GUI für die anderen Tools) mit wxwidgets compilieren (entsprechende Optionen für configure setzen). Aber die Anleitung kommt später, vielleicht gibt es dann ja demnächst auch eine Brew-Lösung.
 
Leider nicht, denn man muss mmg (die GUI für die anderen Tools) mit wxwidgets compilieren (entsprechende Optionen für configure setzen). Aber die Anleitung kommt später, vielleicht gibt es dann ja demnächst auch eine Brew-Lösung.

ich verweise noch mal auf den app build von jonathan http://jonthn.free.fr/MKVtoolnix/
da ist die mmg GUI dabei.
der hat das builden nach einem jahr pause mal wieder aufgenommen.
wird ja auch von der mkvtoolnix bunkus seite bei downloads verlinkt.

hatte vorher auch schon versucht das ganze über brew und wxwidgets 3 zu machen, aber crashte mmg dann immer wieder beim schließen.

bei macports ist es aufgrund der compiler abhängigkeiten halt auch schwieriger.
 
ich verweise noch mal auf den app build von jonathan http://jonthn.free.fr/MKVtoolnix/
da ist die mmg GUI dabei.
der hat das builden nach einem jahr pause mal wieder aufgenommen.
Ich habe seine Version sehr gerne und dankbar genutzt so lange er sie aktualisiert hatte. Würde mich auch freuen wenn er in Zukunft weiterhin aktuelle Versionen zur Verfügung stellt denn ich persönlich werde es eher nicht machen. Der aktuelle Build hat aber noch Mängel weil eben das Problem mit dem Pfad zu mkvmerge erst nach Veröffentlichung von 6.9.1 gelöst wurde.

Hatte das in einer anderen Antwort schon erwähnt, dass interessanterweise dieser Build 2 Tage nachdem ich hier geschrieben hatte dass es mit clang (Xcode 5.1) und statisch geht - vorher waren sie (5.8, 5.9, 6.0 und 6.2) dynamisch. Hatte es auch zuerst dynamisch probiert, es hatte aber Probleme gegegen da ich für dutzende Libraries @executable_path setzen musste, es aber bei manchen z.B. gar nicht ging da zu wenig Platz und mir das Problem zu Mac-spezifisch war. Wollte Moritz Bunkus nicht damit auch noch nerven.

Sollte da irgendein Zusammenhang bestehen würde es mich freuen denn dann hätte sich die Arbeit gelohnt. Wenn nicht ist es ein interessanter Zufall.
 
musst du den mal fragen, warum es erst dynamisch war und jetzt statisch ist.
bei dynamisch musst ja die einzelnen libs nicht immer neu builden, aber dann musst dann mit dem install_name_tool rum hantieren.
ob der mach-o header da begrenzungen hat, weiß ich spontan nicht.

bei einer app hat dynamisch ja auch nur sinn, wenn man die shared libs eh im system zur verfügung stellt und nicht nur im app package.
 
Des weiteren würde ich dir mpv empfehlen. Sofern du deinen Videoplayer nicht gerade auf einem Toaster laufen lässt, solltest du hier nur Vorzüge haben (gerade unter OSX—natives OpenGL Backend und so Späße).
https://github.com/mpv-player/mpv
https://github.com/mpv-player/mpv/blob/master/DOCS/man/en/changes.rst
Das Kompilieren via https://github.com/mpv-player/homebrew-mpv inkorporiert dabei noch eine für OSX gepatchte Version von libass, welche das unsägliche Hashen aller Fonts durch fontconfig extrem reduziert.
Kannst du mir zu dem Brew-System und insbesondere zu dem libass-Patch noch ein paar Details nennen?

mpv (ohne libass) mit dem hier angeführten Prozedere zusätzlich zu kompilieren ist genau 0 Aufwand. Habe aber aktuell noch Probleme ffmpeg mit libass zu kompilieren.
Code:
echo
echo ------------------ Building mpv ++++++++++++++++++++++++++++
echo

cd ${CMPL} 
curl -L -O -s https://github.com/mpv-player/mpv/archive/master.zip
unzip -q master.zip
cd mpv-master
./bootstrap.py
export PKG_CONFIG=pkg-config
./waf configure  --prefix=${TARGET} --disable-libass-osd --disable-libass --enable-static
./waf build
./waf install
Der Vorteil hier ist dass ich eben nur auf einem Rechner das Binary erzeugen muss, es aber auf anderen Rechnern eben auch nutzen kann. Das ist ein ziemlich großes Problem das ich mit Brew habe.
 
libass nutzt fontconfig und das hat ein kleines Designproblem: wenn sich in einer deiner Ordner, die überwacht werden, etwas ändert (eine neue/geänderte Schrift z.B.), wird das vollständige Verzeichnis komplett neu gehasht. Das ist auf linuxoiden kein wirkliches Problem, da hier selten viele Fonts vorhanden sind, aber (im Vergleich zumindest) OSX und Windows dagegen kommen mit einer ganzen Wagenladung an Fonts daher. Bei mir dauert das rehashen einer der üblichen OSX Font Ordner inzwischen mehrere Minuten.
Ansich wäre das selbst kein Problem, würde fontconfig hier eine Kommunikation ermöglichen. Das macht die Bib aber nicht. Der Player hat, wenn er fontconfig nutzt, keine Ahnung ob und weshalb er da ewig blockiert wird und kann es dem Nutzer entsprechend nicht mitteilen. VLC hat sich da was heuristisch timeout-basiertes reingepatched, aber das ist natürlich auch nicht schön.
Dieser libass Fork nutzt CoreText um nach Fonts zu suchen, was deutlich schneller ist.

Für mpv gibt es übrigens mpv-build zum bauen. Das kümmert sich dabei auch um ffmpeg selbst, sodass du nicht die (idR ältere) Version des Systems überschreiben musst (gut, auf OSX ist das wohl weniger relevant). mpv wird recht aktiv entwickelt und greift auf aktuellste ffmpeg APIs zurück, welche sich von Version zu Version leider doch recht zügig ändert.
Weiteres kann ich dir dazu aber nicht sagen, da ich diese Build Skripte nicht nutze. Ich weiß aber, dass sie erfolgreich auch von Leuten mit OSX eingesetzt wurden.

Der Vorteil hier ist dass ich eben nur auf einem Rechner das Binary erzeugen muss, es aber auf anderen Rechnern eben auch nutzen kann. Das ist ein ziemlich großes Problem das ich mit Brew habe.
Hm, okay. Das war für mich noch kein Thema. Wenn ich etwas an meinem Desktop installiert habe, das ich auf meinem Notebook später auch will, hab ich das eben dort auch installiert (ist ja nur eine Zeile Text).
Binaries kopieren mach ich gar nicht, da sich, auf meinem IvyBridge i7 optimierte Binaries, erwartungsgemäß ganz böse mit dem C2D im MBP beißen. ;) Da hab ich zwei Möglichkeiten: entweder kompatible Binaries erzeugen (jedes mal & überall), oder auf jeder Architektur einzeln bauen. Dabei bevorzuge ich persönlich letzteres.
 
libass nutzt fontconfig und das hat ein kleines Designproblem:
Die nächsten Tage werde ich die Anleitung modifizieren da das libass-Problem gelöst wurde und z.B. auch libbluray ohne Probleme compiliert wird.
Binaries kopieren mach ich gar nicht, da sich, auf meinem IvyBridge i7 optimierte Binaries, erwartungsgemäß ganz böse mit dem C2D im MBP beißen. ;) Da hab ich zwei Möglichkeiten: entweder kompatible Binaries erzeugen (jedes mal & überall), oder auf jeder Architektur einzeln bauen. Dabei bevorzuge ich persönlich letzteres.
Ich baue hier für mehrere Rechner und x264 nutzt für den jeweiligen Rechner die entsprechenden Optimierungen.

MMX2 SSE2Fast SSSE3 SSE4.2 AVX auf dem i7-Mac Mini und MMX2 SSE2Fast SSSE3 SSE4.1 Cache64 auf dem steinalten MBP late 08 (C2D).
 
Auf einem für mehrere oder auf jedem selbst?
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.
 
Zurück
Oben Unten