media-autobuild_suite

Ich habe den Verdacht, dass die Bibliotheken von MSYS2 zur Windows-Konsolen-Kompatibilität da vielleicht involviert sind. Kann mich schwach erinnern, dass es schon mal ein Projekt gab, wo eine Sonderbehandlung wegen Binär-Pipes nötig war.

Mit reichlich Hilfe habe ich es geschafft, in der Umgebung der media-autobuild suite einen modifizierten x265-Encoder (Yuuki-Asuna mod / Asuna branch = basierend auf v3.4-stable) zu compilieren. Voraussetzung: Man hat schon mal alle wichtigen Tools damit compiliert, speziell auch x264 mit L-SMASH und LAVF ("light ffmpeg" nur mit Video-Decodern, Option 6).

An der MinGW64-Konsole muss man noch L-SMASH im System installieren, dann holt man sich einen aktuellen Auszug des Asuna-Zweiges:

cd /build/liblsmash-git/
./configure --prefix="/local64"
make install-lib
cd /trunk
git clone https://github.com/msg7086/x265-Yuuki-Asuna.git --branch Asuna x265-Yuuki-Asuna-Asuna

Dann patcht man das CMake-Modul zur Erkennung der ffmpeg-Bibliotheken.

Mein Build-Script hänge ich komplett an. Das basiert auf dem Multilib-Script von Multicoreware für msys, hat aber einige Änderungen. Dazu zählen ein paar exportierte Umgebungsvariablen (zum einen der erweiterte pkgconfig-Aufruf für mehrere Parameter aus der Suite, zum anderen der eingeschobene Pfad zu den Light-ffmpeg-Bibliotheken) und zusätzliche CMake-Direktiven. Hinweis: Die MKV-Ausgabe von Haali ist veraltet, MP4 via L-SMASH wird deutlich empfohlen.

makehdr10_w64_Asuna.sh

#!/bin/sh

export PKG_CONFIG=$LOCALDESTDIR/bin/ab-pkg-config-static.bat
export PKG_CONFIG_PATH=$LOCALDESTDIR/opt/lightffmpeg/lib/pkgconfig:$LOCALDESTDIR/lib/pkgconfig

mkdir -p x265-Yuuki-Asuna-Asuna/build/msys64_hdr10_ml

export CXXFLAGS=
cd x265-Yuuki-Asuna-Asuna/build/msys64_hdr10_ml/
mkdir -p 8bit 10bit 12bit

cd 12bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=ON -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON
make --no-print-directory ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main12.a

cd ../10bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DHIGH_BIT_DEPTH=ON -DMAIN12=OFF -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON
make --no-print-directory ${MAKEFLAGS}
cp libx265.a ../8bit/libx265_main10.a

cd ../8bit
make --no-print-directory clean-generated
cmake -G "MSYS Makefiles" ../../../source -DHG_EXECUTABLE=/usr/bin/hg.bat -DCMAKE_CXX_COMPILER=/local64/bin/g++.bat -DCMAKE_TOOLCHAIN_FILE=/local64/etc/toolchain.cmake -DEXPORT_C_API=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON -DHIGH_BIT_DEPTH=OFF -DENABLE_HDR10_PLUS=ON -DENABLE_LIBVMAF=ON -DENABLE_LSMASH=ON -DENABLE_MKV=ON -DENABLE_AVISYNTH=ON -DENABLE_VPYSYNTH=ON -DENABLE_LAVF=ON -DENABLE_ZIMG=ON -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make --no-print-directory ${MAKEFLAGS}

# rename the 8bit library, then combine all three into libx265.a using GNU ar
mv libx265.a libx265_main.a

ar -M <<EOF
CREATE libx265.a
ADDLIB libx265_main.a
ADDLIB libx265_main10.a
ADDLIB libx265_main12.a
SAVE
END
EOF

/mingw64/bin/strip.exe --strip-unneeded libx265.dll
/mingw64/bin/strip.exe --strip-unneeded x265.exe

x265 3.4-Asuna+54

x265 [info]: HEVC encoder version 3.4+-+54
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.65.101)
x265 [info]: (libavcodec 58.117.101)
x265 [info]: (libavutil 56.63.101)

Die Entwicklung schreitet voran. Mittlerweile wird uvg266, der VVC-Encoder des Kvazaar-Teams, unterstützt, und der Autor des VVCEasy-Paketes, Martin Eesmaa, hilft mit beim Einbinden von Fraunhofer VVenC und VVdeC (die separat auch schon compilierbar sind, wenn man seinen Fork testet).

Denke richtig interessant wird das Ganze erst wenn der Decoder in libav unterstützt wird, so dass man seine Standardmediaplayer und Libavsource&co nutzen kann. Aber schön zu sehen das sich da was tut.

kann man die leute anhauen, dass die das machen?

oder sind die schon fleißig am werkeln und wollen nicht gestört werden?

Es geht ganz gut vorwärts. Aber nur im Rahmen der Möglichkeiten. Zum Beispiel ist es gut, VVenC und VVdeC einzeln zu haben, aber die Integration in ffmpeg würde Patches erfordern, die irgendwann wohl sowieso integriert werden, da kann es sein, dass die erst mal eine Weile im Fork von Martin bleiben und nicht gleich zurück ins Hauptprojekt kommen.