Baut jemand ffmpeg für Windows selber? -> fdk-aac

    Suche jemanden der ffmpeg für Windows selber baut und mit eine Version mit fdk-aac integriert bauen könnte.
    Hintergrund: fdk-aac (https://github.com/mstorsjo/fdk-aac + http://www.hydrogenaudio.org/forums/index.php?showtopic=95989) ist der neue OpenSource Frauenhofer AAC Encoder, da es aber leider keinen eigenständigen Command Line encoder gibt und die Lizenz das Kombinieren in frei verteilbaren ffmpeg Versionen (gpl vs. copyleft style) verbindet, muss man selber eine Version bauen die 'non-free' erlaubt und '--enable-libfdk-aac' verwendet.
    -> würde gerne Support für solche builds in Hybrid hinzufügen, Problem ist nur ich habe keine MinGW&Co Buildumgebung und auch wenig Motivation eine aufzusetzen.

    Falls also jemand ffmpeg eh unter Windows selber baut, wäre es schön, wenn er eine Version mit fdk-aac bauen und mir zukommen lassen könnte,..
    (ja ich könnte selber unter Linux oder Mac so ne Version bauen, da ich aber in nächster Zeit vor allem unter Windows arbeite würde ich gerne eine Windows Version haben,..)

    Cu Selur

    Ps.: wegen genanntem Lizenzproblemen wird Zeranoe fdk-aac auch nicht in seinen build integrieren können,... (hoffe ja noch auf einen StandAlone-Encoder, wie man ihn für LAME (lame) und Vorbis (oggenc2) hat.)

    hui, sieht nett aus, werde ich morgen mal antesten.

    Danke für den Link!

    -> erster rudimentärer Support für fdk-aac enc steht,... (hab noch nicht gecheckt wie das mit erlaubten bzw. nicht erlaubten bitraten&sampleraten Kombinationen steht,..)

    Nein, es wird keine Windows binary von ffmpeg, mit fdk-aac, geben die mit Hybrid verteilt wird, weil das gegen die Lizenzbedingungen verstößt.
    In der nächsten Version von Hybrid wird es aber für die Leute die ffmpeg selber bauen die Möglichkeit geben auf den Encoder zurück zugreifen.
    Ist an sich genau so wie bei FAAC, nur gibt es da einen separates CLI, was es für fdk-aac bis dato noch nicht gibt.
    Sprich, wenn es einen StandAloneEncoder CLI Encoder gibt werde ich für den auch Support in Hybrid integrieren und eine binary mit Hybrid verteilen, sofern es dann nicht andere Lizenz-/Copyright Probleme geben sollte,...

    Cu Selur

    Freut mich zu hören, dass es nützlich ist :). Das Script ist wirklich super! Habe jetzt zwar die neue Version noch nicht compiliert, aber vorher ging es wirklich super! Der Niesel sollte auch eine Version haben, die kein extra Diff File benötigt, damit geht es etwas einfacher. Weiß aber nicht wie die beiden Scripte sich gerade Codec mäßig unterscheiden. Ich hoffe es wird noch frei0r eingebunden - scheint nicht ganz so leicht zu sein. Wie ich sehe tust du dich ja fleißig an der Entwicklung beteiligen :).
    Ich hoffe auch noch, dass die openEXR Unterstützung seitens ffmpeg besser wird, aber das hat ja nichts mit dem Script selbst zu tun.

    Eigentlich sollte das Skript wohl die diff Files selber runterladen&Co, da ist aber momentan der Wurm drinnen, wenn man aber einen git clone macht und dann das Skript ausführt klappt es alles. ;)

    Zitat

    Wie ich sehe tust du dich ja fleißig an der Entwicklung beteiligen


    Nicht wirklich, hab nur Fehler entdeckt, diese gemeldet und soweit wie möglich Feedback gegeben. Hab ja 0% an dem Skript mit programmiert oder so. -> Lob für das Skript geht allein an rdp.

    @all: Falls jemand vergleichbare Skripte für mencoder&mplayer kennt, bitte Bescheid sagen. Interessiert mich immer, da ich der Ansicht bin, das solche Cross-Compile-Skripte bekannter sein sollten, damit mehr Leute in der Lage sind Tools zu kompilieren, selbst wenn sie sonst wenig bis keine Ahnung von Programmieren&Co haben.

    Habe mich heute mal ein wenig mit MSYS und mingw beschäftigt und im Prinzip sollte das compilieren dort auch recht gut gehen. Für mplayer bin ich dabei über diese Anleitung gestoßen:
    http://wiki.ivonet.nl/display/howto/…ayer+with+Mingw wenn du jetzt in Ubuntu bleiben willst, kannst das sicher um münzen. Hier würde ich mir auf jeden Fall auch noch mal WUBI anschauen. Wusste bis vor kurzem nicht, dass es das gibt - finde ich sehr cool.

    Die Links fand ich auch noch nützlich:
    http://wiki.openttd.org/Compiling_on_MinGW
    http://ingar.satgnu.net/devenv/mingw32/local.html
    http://www.finalmediaplayer.com/source.html

    WUBI ist doch nur ein Windows Installationsprogramm um Ubuntu zu installieren,... da installiere ich es lieber in ner VM. :)
    Die Anleitung ist leider zu alt um sie einfach zu portieren und ist auch nicht fürs cross compiling gedacht.
    Als nächstes muss ich aber eh erst mal rausbekommen was ich an den MPlayer build Abhängigkeiten geändert hat, da meine build-Skripte auf dem Mac nicht mehr laufen. :(

    Ja stimmt schon, dass wubi sich über Windows installieren lässt aber das feine ist ja dran, dass es keinen Bootmanager installiert, sondern einen Eintrag in den Windows Bootmanager schreibt. Auch wird nur eine virtuelle HD erzeugt. Man kann also gefahrlos installieren und deinstallieren/löschen, Windows bleibt davon unberührt. Und das schöne dabei ist dann, dass man die volle Hardware Performance in Ubuntu hat, nicht wie in einer VM. Also auch das compilieren geht schneller.

    Schade, dass die Anleitung zu alt ist. Ich hatte mal einige Module von ffmpeg in MSYS kompiliert und das ging recht gut, auch ohne patches wie es teils unter Ubuntu nötig ist. Dachte daher vielleicht geht das mit mplayer auch.

    Entwickeln unter Mac macht ja auch Spaß, wenn es läuft :). Schade, dass das in Windows nicht immer so einfach ist.

    Zitat

    Entwickeln unter Mac macht ja auch Spaß,...


    Ne, gar nicht! Entwickeln unter dem Mac ist alles andere als angenehm. Das fängt schon damit an, dass
    1. die normale Mac Tastatur eine andere Tastaturbelegung hat, was vor allem nervig ist, wenn auf der Tastatur nicht verzeichnet ist wo was liegt. (normalerweise kann ich Blind tippen, geht auf dem Mac gar nicht)
    2. eine stabile build Umgebung um Sachen statisch zu bauen unter dem Mac ein absoluter Krampf ist.
    3. viele Mac Anwender einem so gut wie keinen Feedback geben und es auch wenn sie es gerne wollen nur bedingt können, weil sie sich mit der unterliegenden Mechanik so gut wie nicht auskennen.
    4. es anscheinend niemanden gibt der aktuelle statische ffmpeg, mplayer&mencoder builds für den Mac erstellt, weshalb man sich entweder damit rumschlagen muss die Sachen irgendwie alle selber zu kompilieren oder mit total veralteten Tools arbeiten muss.
    -> Sorry, aber Spaß ist was anderes. :D

    Cu Selur

    Ok, das klingt alles wirklich nicht lustig :). Ich empfand nur einiges angenehmer unter Mac als unter Windows. Z.B. das Terminal, die Entwicklertools, es gibt einen Macport, die verschieden Scriptsprachen. Klar unter Linux alles kein Problem, aber bei Windows fand ich das doch immer recht anstrengend. Das kompilieren von ffmpeg unter Mac sollte aber auch recht gut gehen. Hatte ich vor ein paar Monaten erst gemacht.

    Ja, MacPort&Co sind nett wenn man nicht statisch kompilieren will.
    Ja, kompilieren von ffmpeg ist einfacher. (das Skript geht auch noch,..)

    Zitat

    Problem, aber bei Windows fand ich das doch immer recht anstrengend.


    Windows ist ähnlich kompliziert, da will erst mal der gcc installiert sein und das Abhängigkeiten jagen ist auch nervig. Bei Windows ist aber der Vorteil, dass da mehr Bastler Interesse dran haben und dementsprechend mehr Dokumentationen und hilfsbereite Leute da sind. ;)

    Cu Selur

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden