media-autobuild_suite

x265 unterstützt jetzt auch Multi-Library-CLI (z.B. 10-bit-Bibliothek *.a in 8-bit-EXE mit einlinken). Mit der alten MSYS-Umgebung von XhmikosR mit GCC 4.8.2 hab ich da aber Linkerfehler. Vielleicht wird das mit MSYS2 und GCC 4.9.x besser klappen. Auf jeden Fall gibt es noch andere Probleme mit dem älteren GCC 4.8.2, z.B. noch kein threadsicheres fprintf. Also gut, dass ihr da auf Aktualität achtet.

Bei mkvtoolnix fehlt jetzt was, vermutlich seit die die neue GUI haben:

CXX src/mkvtoolnix-gui/app.cpp
     CXX src/mkvtoolnix-gui/chapter_editor/chapter_model.cpp
src/mkvtoolnix-gui/app.cpp:4:24: fatal error: QLocalServer: No such file or directory
 #include <QLocalServer>
                        ^
compilation terminated.
     CXX src/mkvtoolnix-gui/app.cpp
src/mkvtoolnix-gui/app.cpp:4:24: fatal error: QLocalServer: No such file or directory
 #include <QLocalServer>
                        ^
compilation terminated.
mv: der Aufruf von stat für „/local32/bin-video/mkvtoolnix/share/locale“ ist nicht möglich: No such file or directory
cp: das Verzeichnis „/local32/bin-video/mkvtoolnix/bin/examples“ kann nicht angelegt werden: No such file or directory

P.S.: Wenn während der Compilierung neue ffmpeg-Updates kommen, kann man mit "y" das Skript noch mal durchlaufen lassen; mit "n" oder ENTER wird aber nicht beendet, nur eine Endlosschleife eingeleitet.

Build x265 [H.265 encoder]?
1 = Static x265.exe and library with Main and Main10 included
2 = Static library only
3 = No
4 = Static x265.exe [Main] and libx265_main10.dll

Kann man nicht mehr x265.exe und x265-10bit.exe bauen?
(mkvtoolnix wird bei mir nicht neu gebaut und steckt bei der 8.0er Version, werde mal alles im localX/bin-audio und localX/bin-video Ordner und die mkvtoolnix Sourcen löschen eventuell hilft das)

1 ist jetzt eine Multilib-EXE (Profile Main + Main10, ausgewählt durch '-D 8|10').

Läuft die mittlerweile auch mit Windows XP? Das letzte Mal klappte der Multilib Kram noch nicht unter XP. (hoffe mal das man mit -D 10 auch 16bit encoden kann)

mkvtoolnix 8.1 wurde hier ohne Probleme gebaut, aber dafür wurde x265 (und x264) gar nicht gebaut,.. werde also wohl mal da auch die Sourcen löschen und gucken ob es dann gebaut wird.

vpxenc wird aktuell übrigens nicht gebaut (hab nen Eintrag im Bugtracker gemacht)

Zitat

Wenn während der Compilierung neue ffmpeg-Updates kommen, kann man mit "y" das Skript noch mal durchlaufen lassen; mit "n" oder ENTER wird aber nicht beendet, nur eine Endlosschleife eingeleitet.

Kann ich bestätigen.
Liegt vermutlich daran, dass 'new_updates' nur auf 'yes' gesetzt wird im Code, aber nie auf 'No', sprich so bald die einmal auf 'Yes' ist, bleibt man in ner Loop hängen.
Hab mal nen Eintrag in den Bugtracker gemacht: https://github.com/jb-alvarado/me…uite/issues/109

Wie LoRd_MuldeR grad verlinkt hat, könnte "strip --strip-all" bei statischen Builds riskant sein und möglicherweise zu viel entfernen, falls ich das richtig verstanden habe... oder es geht nur um linkbare Bibliotheken, aber nicht um endgültige Programme. Dann hab ich's noch nicht ganz.

Stripping shared libraries

Bei meinen eigenen Builds bleibe ich bei "strip --strip-unneeded", auch wenn die Multilib-EXE dann etwas größer bleibt.

Ich habe da gerade was merkwürdiges festgestellt:

x265 [info]: HEVC encoder version 1.7+286-1162fb0b99f8x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bitx265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNTH:\development\media-autobuild_suite-master\local64\bin-video>x265.exe -D 10 -Vx265 [info]: HEVC encoder version 1.7+286-1162fb0b99f8x265 [info]: build info [Windows][GCC 4.9.2][64 bit][noasm] 10bitx265 [info]: using cpu capabilities: none!H:\development\media-autobuild_suite-master\local64\bin-video>x265.exe -D 12 -Vx265 [info]: HEVC encoder version 1.7+286-1162fb0b99f8x265 [info]: build info [Windows][GCC 4.9.2][64 bit][noasm] 12bitx265 [info]: using cpu capabilities: none!

Dass 10-bit- und 12-bit-Encoder ohne Assembler erzeugt werden, würde ich bei einem 32-bit-Build verstehen. Aber bei einem 64-bit-Build sollte das nicht der Fall sein.

Ich weiß nicht sicher warum, aber meine Vermutung wäre:

if [[ $bits = '32bit' ]]; then
            xpsupport="-DWINXP_SUPPORT=ON"
            assembly="-DENABLE_ASSEMBLY=OFF"
        fi

Wenn für 32 bit compiliert wird, wird es für die HBD-Libraries deaktiviert. Gut.

Und wo wird es wieder aktiviert, bevor nach der 32-bit-Compilierung dann die 64-bit-Compilierung folgt, wenn ich 32 bit und 64 bit nacheinander in einem Skript compilieren lasse?

Ich füge mal das Gegenteil in einen "else"-Zweig ein und schaue, was dabei herauskommt.
__

Mit "else" wird die 64-bit-EXE wie erwartet (und deutlich größer).

Hui,.... das ist wirklich doof. -> melde das am Besten mal im Bugtracker

Hab ich längst. Wurde grad korrigiert.

x265 bauen klappt aktuell nicht. (habs auch im Bugtracker gemeldet)

Im x265-Tracker oder im mas-Tracker?

Multilib compilieren klappt bei mir auch ohne mas nicht.

CMakeFiles/cli.dir/objects.a(x265.cpp.obj):x265.cpp:(.text+0x1bfa): undefined reference to `x265_api_get_63'

Ah, vermutlich haben sich die cmake-Parameter geändert. Es wird jetzt eine Multilib-EXE generiert, die zusätzlich wie eine DLL die Funktionen exportiert, so braucht man eigentlich überhaupt keine DLLs mehr (Programme, welche die x265-Encoder benutzen wollen, können dann die Multilib-EXE wie eine DLL dynamisch einbinden, die Dateiendung ist ja den aufrufenden Routinen egal).

Hier würde ich dann eventuell von --strip-all abraten und --strip-unneeded zur Sicherheit empfehlen.

in den mas-tracker -> https://github.com/jb-alvarado/me…uite/issues/112

Ist das nur bei mir so oder werden einige der Audio tools (lame, aften, fdkaac, speexenc) nicht mehr gebaut?

Bin mir nicht sicher, hab ich wenig drauf geachtet; aber ich glaube schon, dass die nicht mehr aktuell werden. Im Moment bin ich nicht an einem PC, auf dem das noch vernünftig läuft (wegen 32-bit-Windows).

Auch wenn die nicht mehr aktualisiert werden, wäre es zumindest schön, wenn man sie überhaupt noch bauen könnte.

Ja, das meine ich mit "aktuell": Ich glaube, im "local##"-Verzeichnis lagen von denen nur noch alte Versionen. Aber das ist auf einem anderen Rechner.