Mit ein wenig Anpassung hätte man sicher auch GIT in die Toolchain reinbekommen.
aaaaarrrrrgghhhhh,.... falls wer ne neue Quelle für ffmpeg build weiß her damit,..
seit die ffmpeg-Quelltexte von SVN zu Git als Versionssystem gewechselt haben.
liegt vermutlich weniger am SVN -> Git Wechsel, sondern eher an der generellen Umstrukturierung des FFmpeg Teams,...
falls wer ne neue Quelle für ffmpeg build weiß her damit,..
git clone git://git.ffmpeg.org/ffmpeg.git(gehe davon aus du nimmst Ubuntu, Debian ist ein etwas anderer Syntax.)
Falls du nach Debian Art kompilierst muss die changelog-Datei ungefähr so abgeändert werden. dass sich folgendes ergibt : ffmpeg_git-d1b6f33-1_i386.deb
Falls du mit checkinstall arbeitest :
sudo checkinstall --pkgname=ffmpeg --pkgversion "4:SVN-r`svn info | grep Revision | awk '{ print $NF }'`" --backup=no --deldoc=yesEdit : Sehe gerade du meintest sicherlich Windows :(.
Ich habe wenig Ahnung wie kompliziert das unter Windows ist, bzw die zusätzlichen Pakte einzuspielen.
Unter Linux ziemlich einfach..
FFmpeg version git-d1b6f33, Copyright (c) 2000-2011 the FFmpeg developers
built on Jan 27 2011 11:43:27 with gcc 4.4.5
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-pthreads --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libvpx --enable-libxvid --enable-x11grab --enable-libdc1394 --enable-libgsm --enable-libspeex --enable-runtime-cpudetect --disable-vdpau
libavutil 50. 36. 0 / 50. 36. 0
libavcore 0. 16. 1 / 0. 16. 1
libavcodec 52.108. 0 / 52.108. 0
libavformat 52. 94. 0 / 52. 94. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 74. 0 / 1. 74. 0
libswscale 0. 12. 0 / 0. 12. 0
libpostproc 51. 2. 0 / 51. 2. 0
Vereinfacht dargestellt, ein Verzeichnis erstellen mit git und svn Quellen, Abhängigkeiten auflösen, kompilieren, installieren. Je nach Architektur deb, rpm oder ein anderes Paketformat vorher erstellen. Zum Updaten, alles in ein Script packen (svn update, git pull), Abhängigkeiten neu prüfen lassen und kompilieren.
Ist genau einmal Arbeit, der Rest Automation.
Kann nicht verstehen, wie am sich fremde Builds einspielen kann. Da kann sonst was mit drin sein....Bundestrojaner oder so...:)
Warum wählt ihr nicht einen Forum Gleitz Builder...dem kann man auch vertrauen.
Da hast du Recht. Die Dokumentation ist ziemlich dürftig, bis totaler Mist.
Man muss ffmpeg ja nicht unter Windows kompilieren um Windows Binaries zu erzeugen. Hat man eine funktionierende Cross-Compiler-Kette unter Linux (da dort die Abhängigkeiten wesentlich einfacher aufzulösen sind), dann reicht das allgemein aus.
Sind denn eigentlich für die Gleitz-Projekte tägliche builds nötig? Oder reicht es, wenn da jemand auf Abruf sitzt, der das mit den benötigten Optionen compiliert?
1. Wöchentliche builds würden mir und vermutlich den meisten anderen schon reichen
2. Nicht nur regelmäßige ffmpeg, sondern auch mplayer&mencoder builds wären interessant (bei MPlayer z.B. ganz aktuell wäre eine Version mit libbluray Unterstützung interessant)
3. Stimme LigH zu, nicht das Kompilieren, der Basisprojekte ist das eigentliche Problem, sondern das integrieren der gänigsten Patches und libaries von die man so braucht. (lame, faac, vorbis, flac, libbluray, x264, xvid,..)
Cu Selur
Zu libbluray unter Linux :
git clone git://git.videolan.org/libbluray.git./bootstrap./configuremakemake install
(Viel komplizierter dürfte es doch auch unter Windows nicht sein)
Bei ./configure sind zwar einige Optionen, ich habe nur shared gewählt. Schien mir am sinnvollsten. Ohne Präfix wird /usr/local/bin und /usr/local/lib als Installationspfad genommen.
Muss mal schauen, wie man den Source "debianisiert".
Da bei der MPlayer Konfiguration Blu-ray support auf autodetect steht, braucht man sich auch beim nächsten Kompilieren von MPlayer um nichts zu kümmern.
Kompilieren von Mplayer unter Debian/Ubuntu ist mittlerweile recht angenehm, da der Source "debianisiert ist.
Habe das in der Debian Wiki zusammengefasst.
Für Buntus muss lediglich der Syntax von Changelog verändert werden .
Beispiel : mplayer (2:1.0~rc4+svn20101213) maverick; urgency=low
sondern das integrieren der gängigsten Patches und libaries von die man so braucht. (lame, faac, vorbis, flac, libbluray, x264, xvid,..)
Den meisten Ärger macht bei mir X264 im Zusammenspiel mit ffmpeg.
Ein über das andere Update erzeugt beim Kompilieren Fehlermeldungen zu einer undefinierten Referenz...Lästig.
Der Rest der Libaries ist ok.
Bei ffms2 erkenne ich den Sinn nicht unter Linux.
Ich schätze mal das einer der größten Unterschiede ist, dass ihr unter Windows X Patches zu den einzelnen Libaries einpflegt. Geht es da wirklich um objektive Verbesserungen, oder ist das mehr eine Machbarkeitsstudie.
Und wenn es objektive Verbesserungen gibt, warum ist das so unzureichend dokumentiert.
MPlayer, FFmpeg, usw. kompilieren stößt bei mir unter Windows i.d.R. auf folgende Probleme:
1. ein BuildEnviroment zum Laufen zu bringen in dem auch alle Tools vorhanden sind von denen die ffmpeg&Co Leute ausgingen,.. (MingW, MSYS mit eventuellen Erweiterungen usw.)
2. man muss i.d.R. noch X patches aktivieren, damit man den SourceCode überhaupt kompiliert bekommt (z.T. grottige configure Skripte anstatt z.B. cmake zu nutzen sind eines der Probleme)
3. man darf nach allem Googeln weil es keine ordentlichen halbwegs aktuellen Anleitungen gibt ("warum ist das so unzureichend dokumentiert" -> weil sich niemand drum schert,..)
4. wenn man mal nach einigen Stunden endlich eine Buildumgebung hat und der Spaß mal kompiliert ist man froh und darf beim nächsten Release wieder von vorne Anfangen, weil irgendein neues Problem auftaucht,..
5. die rechtliche Lage ist für meinen Geschmack nicht klar genug geklärt, als dass ich irgendwo selber MPlayer&FFmpeg builds als hosten würde.
Hab selber schon einige Male drüber nachgedacht, MPlayer&Co selber zu kompilieren, aber i.d.R. bei 3. schon irgendwann keinen Nerv mehr gehabt. 
-> Freue mich ja, dass es unter Linux einfach zu bauen geht, aber das hilft auch nicht weiter.
Cu Selur
("warum ist das so unzureichend dokumentiert" -> weil sich niemand drum schert,..)
Das verstehe ich eben nicht, vor allem da großes Interesse bei so vielen Usern besteht.
Mittlerweile gibt es Builds von Hinz und Kunz.
Unsigniert, kein GPG Key, nichts.
Wäre ich das BKA, würde ich Codecs kompilieren.
Unter Linux leider in letzter Zeit ein ähnliches Bild, dank Ubuntu Usern :(.
Builds bei D10 werden bereitgestellt, die a) am Paket-Management völlig vorbei gehen, keine separaten Libs/devs als Deb-Paket bereitstellen und somit auch fehlerhaft sind. Null Signatur, oder GPG Key. Für Ubuntu wird auf eine Anleitung zum Kompilieren verwiesen, die für private Zwecke ok ist, aber nicht als offizielle Empfehlung gelten darf und streng genommen, von der ersten bis zur letzten Seite falsch ist.
die rechtliche Lage ist für meinen Geschmack nicht klar genug geklärt, als dass ich irgendwo selber MPlayer&FFmpeg builds als hosten würde.
Schwierig..
Ein Build Script wäre erlaubt...:)
Aber das will auch gepflegt werden...
PS: Gestern habe ich ffmpeg/Mplayer mit X264.113.1884 kompiliert.
Ich sehe keinen Unterschied zu 112. Frage mich eh, ob ich mir das weiter an tun soll, jeden Build zu kompilieren und in ffmpeg/Mplayer etc einzubinden.
Siehst du da irgendeinen Unterschied?
Ich sehe keinen Unterschied zu 112. Frage mich eh, ob ich mir das weiter an tun soll, jeden Build zu kompilieren und in ffmpeg/Mplayer etc einzubinden.
wenn Du die ganzen Bauroutinen nicht in ein Skript gepackt hast, würde ich mir bevor ich mir das alles antue erst ins x264 Changelog gucken, ob da was interessantes drinnen ist.
Das interessanteste der letzten Wochen war für mich "VBV emergency mode" welcher aber auch nur interessant ist, wenn man VBV braucht.
Tägliche Builds sind i.d.R. total unnötig.
i.d.R. reicht sicher ein Wöchentlicher build + Build bei größeren Neuerungen
Ein Build Script wäre erlaubt...
Aber das will auch gepflegt werden...
Problem an BuildSkripten ist, dass die Buildumgebung natürlich auch gepflegt sein muss.
Interessant wäre es, wenn sich motivierte Leute hinsetzen würden
1. z.B. für Ubuntu, oder ein anderes kostenloses System was man in eine VM packen kann, ein Paket zusammenstricken&pflegen würden, welches einem eine fertige Cross-Plattform Buildumgebung aufbaut
2. es dann entsprechende build Skripte für die einzelnen Tools geben würde, welche wirklich alles machen
So wäre es dann nicht schwer für Leute AutoBuilds&Co zu erstellen und wenn ein Anbieter solcher builds keine Lust mehr hat (z.B. weil ihm Entwicklerteam X zu unfreundlich gegenüber war) könnte es schnell Alternativen geben.
(vermutlich könnte man die Builds ja auch bei SourceForge oder GoogleCode hochladen)
Wäre ich das BKA, würde ich Codecs kompilieren.
Brauchst nur ne kleine Anwendung schreiben, die Du closed source hältst, welche aber viele Leute interessiert und die sie deshalb installieren.
Cu Selur
So I've built MPlayer-uau for Windows.
Fun Fact: This involved around 70 patches for
Unglaublich.....
aber ...:seher:
I will also upload a working toolchain for cross-compiling on Linux, including scripts for downloading, patching and building all the dependencies (and possibly other multimedia-related software), as well as a Live CD/HDD image/OVF with everything set up. Maybe it is of use to someone
Das hört sich ja mal cool an! (hoffe mit der ToolChain kann man dann auch mencoder bauen, denn mplayer alleine ist zwar nett aber nicht das Wahre.;))
Update:
Im englischen Doom9 Forum stellt der User Midzuki jetzt bei http://www.shragle.com/folder/f2f83fcc tägliche ffmpeg AutoBuilds zur Verfügung.
(Quelle: http://forum.doom9.org/showthread.php?p=1477407#post1477407 <- Danke and LigH für den Hinweis)
Im englischen Doom10 Forum macht sich lachs0r's daran mplayer und ffmpeg zu bauen. (siehe: http://doom10.org/index.php?topic=1269.msg6291#msg6291)
Leider fehlt zumindest mir noch eine aktuelle Quelle für Mencoder (&MPlayer) mit libbluray, falls jemand über so eien Quelle stolpert bitte Bescheid sagen.
Cu Selur
Baut jemand git://http://git.videolan.org/ffmpeg.git win32 builds?
Cu Selur
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!