media-autobuild_suite

    x265 baut nicht:


    werde es später noch mal antesten

    Ja, ist leider bekannt.

    Die Abhängigkeiten zwischen den Bedingungen ("MinGW und 64 bit?" und "MinGW und 32 bit und WINXP_SUPPORT?") sind noch nicht so ganz korrekt.

    Patch 6625 (3f78e639d9ce) / v0.8+246 sollte funktionieren.
    Patch 6626 (1410caf09a39) / v0.8+247 bringt eine Funktion mit sich, die bei Unicore-CPUs im Single-Thread-Modus abstürzt.*
    Patch 6627 (6f7b323061dc) / v0.8+248 compiliert mit MinGW für Win64 und Win32+WINXP_SUPPORT, aber nicht für Win32 allein.

    Wartet mal lieber noch zwei Tage...
    __

    * Aber das will man nicht. Wirklich nicht. In diesem Modus encodiert Preset ultrafast eine Fläche kleiner als EGA-Auflösung mit 1/2 fps.

    Naja, ich kenne das eigentlich so, dass nichts commited werden darf, was auf einem der unterstützten Compilern nicht compiliert.
    Etwas unklar ist mir noch was denn aktuell kaputt ist:
    MinGW + win32?
    MinGW + win64?
    MinGW + win32 + WindowsXP support?
    MinGW + win64 + WindowsXP support?

    Ohne Gewähr, ich probiere das jetzt nicht noch mal alles durch:

    • MinGW + win32: Müsste compilieren; sollte eigentlich seit Patch 6627 (6f7b323061dc) / v0.8+248 auch den von x264 geborgten XP-Code verwenden, weil der etwas schneller sei als die Kernel-Funktion.
    • MinGW + win32 + WindowsXP support: Compiliert, läuft aber seit Patch 6626 (1410caf09a39) / v0.8+247 nur noch auf Multi-Core-Systemen.
    • MinGW + win64: Compiliert seit Patch 6627 (6f7b323061dc) / v0.8+248 nicht mehr, die Bedingung "Win64" verhindert sowohl XP-Nachbau als auch Vista+-Kernel-Funktion.
    • MinGW + win64 + WindowsXP support: Ist inhaltlich fast Unsinn, weil XP 64-bit exotisch war, es könnte höchstens noch Server 2003 64-bit existieren; daher nicht probiert, ob's klappt.

    Dann sollte das compilieren von x265 32bit ja klappen, aber da krieg ich schon Fehler. :(
    Hatte meinen "H:\media-autobuild_suite\build32\x265-hg"-Ordner gelöscht und kriege:

    -> Liegt das nun an x265 oder am build script?

    jb_alvarado: Nebenbei ist der Code zum Bauen von x264 ja bei https://github.com/jb-alvarado/me…e_videotools.sh in Zeile 78 bis 193.
    Warum ist Zeile 95-97 und Zeile 99-101 identisch? Sind die Zeilen 99-101 nicht unnötig? Analog ist mir der Sinn von Zeile 123-127 unklar. :)

    ------------
    LigH: wie sieht den Dein Configure/CMake Call aus mit dem Du x265 konfigurierst? (irgendwie müsste dieser sich ja von denen die in Zeile 132-193 verwendet sind unterscheiden, wenn das 32bit-Kompilieren bei Dir geht)

    Cu Selur

    Du willst für Windows XP kompilieren?

    Ist denn die Option dafür aktiviert? in CMakelist.txt findet sich:

    Für mich sieht es so aus:

    Damit es unter WinXP kompiliert, muss beim Compiler Aufruf -D_WIN32_WINNT=_WIN32_WINNT_WINXP gesetzt werden.
    Dafür ist in CMAKE die Option WINXP_SUPPORT zuständig, die "manuell" gesetzt werden muss. Es gibt keine automatische WinXP Erkennung, soweit ich das (von Linux aus) sehe.

    Also müsste das Script auf WinXP testen und manuell die Option setzen. (bei cmake Aufruf denke ich)

    Ausgehend von einem frischen x265-Clone, habe ich das Verzeichnis x265/build/msys samt Inhalt kopiert nach

    • x265/build/msys_hbd
    • x265/build/msys64
    • x265/build/msys64_hbd


    und dann das folgende Shell-Skript remake_x265.sh darüber erstellt:


    Ja, das ist sicher nicht lehrbuchmäßig, aber ich hatte nie ein Lehrbuch über Shell-Skripte und make-Tools...

    Das Ergebnis bei Patch "6625 (3f78e639d9ce) restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP …":

    Alles compiliert.

    Das Ergebnis bei Patch "6627 (6f7b323061dc) cmake: allow MinGW to target XP by default …":

    Die Win32-Targets, beide mit aktiviertem WINXP_SUPPORT, compilieren durch; die Win64-Targets, beide ohne WINXP_SUPPORT, finden keine Definitionen für Condition-Variablen, also hat die cmake/configure-Logik da anscheinend beide Varianten deaktiviert...
    __

    P.S.:

    In der Mailingliste wurde noch ein Vorschlag präsentiert, wie man die x265/source/CMakeLists.txt ändern sollte. Findest du den? Als Patch ist der noch nicht raus, und ich habe hier gerade keinen Zugriff auf die Emails, die ich woanders empfangen habe...

    Zitat von Selur

    jb_alvarado: Nebenbei ist der Code zum Bauen von x264 ja bei https://github.com/jb-alvarado/me…e_videotools.sh in Zeile 78 bis 193.
    Warum ist Zeile 95-97 und Zeile 99-101 identisch? Sind die Zeilen 99-101 nicht unnötig? Analog ist mir der Sinn von Zeile 123-127 unklar. :)

    In der tat ist das ganze doppelt gemoppelt, habe es jedoch anders nicht hin bekommen x264 mit libav zu kompilieren, erst beim zweiten Durchlauf wird libav gefunden. Frag mich nicht warum :). 123-127 Spart sich den zweiten Durchlauf wenn vorher ffmpeg noch nicht kompiliert wurde.

    Noch Unklarheiten? :)

    Edit: die 64bit version von x265 wird wieder gebaut.

    Zitat

    ..erst beim zweiten Durchlauf wird libav gefunden.


    Ah okay, damit ist das klar.

    Zitat

    In der Mailingliste wurde noch ein Vorschlag präsentiert, wie man die x265/source/CMakeLists.txt ändern sollte. Findest du den?


    -> https://mailman.videolan.org/pipermail/x265…rch/004071.html
    da LigH auch schon berichtet hat, dass der Patch zu klappen scheint (https://mailman.videolan.org/pipermail/x265…ril/004072.html) sollte vermutlich alles klappen wenn ich nur etwas warte bis des Patch es in den normalen Tree schafft.

    Nein, dieser Vorschlag wurde abgewiesen, statt dessen zwei andere Dateien geändert. Version 0.8+251-ae07405973b7 klappt (Patch 6630 (ae07405973b7) xp: fix header guards for XP support, fixes MinGW build …).

    Zitat von jb_alvarado

    Edit: die 64bit version von x265 wird wieder gebaut.

    Dafür klemmt die 32-bit-Version in der neuesten Revision. Grund: Jemand hat in Patch 6634 (c4ea6cffe2b3) "asm: code for input pixel upShift/downShift" ein Symbol im Assembler-Code verwendet, das nur für 64-bit-Register geeignet ist.

    Was für ein Aprilscherz. Ich musste gleich an "Neues vom Hexer" (Edgar-Wallace-Verfilmung von 1965) denken:

    Zitat von Sir John

    Aber das hätten Sie doch berücksichtigen müssen!

    Die 32-bit-Versionen sollten nun eigentlich automatisch XP-kompatibel werden, weil der Condition-Variable-Nachbau auch noch etwas schneller sein soll als die Vista+-Kernel-Funktion und deshalb standardmäßig verwendet wird.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden