feat: media bitrate control, HDR (#346)

Fixes: #335 Still a work-in-progress. --------- Co-authored-by: DatCaptainHorse <DatCaptainHorse@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Wanjohi <elviswanjohi47@gmail.com>
2026-10-01 23:22:24 +03:00 · 2026-09-25 12:13:34 +03:00
parent 1c721962f4
commit 0811f57f1a
64 changed files with 15151 additions and 2702 deletions
@@ -0,0 +1,26 @@
+kaldi's i386 and x86_64 builds share one source directory, and its cmake
+writes generated files into it, so proton-ge serializes the two with plain
+ordering rules. Those rules name the i386 steps unconditionally.
+
+A wow64-only build has no i386-unix in ARCHS, so the i386 steps are never
+defined, and make stops with "no rule to make target .kaldi-i386-configure".
+Only order against them when they exist.
+
+diff --git a/Makefile.in b/Makefile.in
+index f8d959c..9b92fec 100644
+--- a/Makefile.in
+++ b/Makefile.in
+@@ -573,9 +573,13 @@ $(eval $(call rules-cmake,kaldi,aarch64,unix))
+ # the same source directory.
+ #
+ # The below assures that only a single configure/build step can run at a time.
+# The i386 steps exist only when i386-unix is in ARCHS; a wow64-only build has
+# none, and ordering against them would ask for a target with no rule.
+ifneq ($(findstring i386-unix,$(ARCHS)),)
+ $(OBJ)/.kaldi-x86_64-configure: $(OBJ)/.kaldi-i386-configure
+ $(OBJ)/.kaldi-i386-build: $(OBJ)/.kaldi-x86_64-configure
+ $(OBJ)/.kaldi-i386-build: $(OBJ)/.kaldi-x86_64-build
+endif
+ 
+ ##
+ ## vosk
@@ -0,0 +1,22 @@
+protonfixes pins unzip to Debian revision 6.0-29 and fetches it from the
+live pool. The pool keeps only current revisions, so once 6.0-31 landed the
+download started failing with a 404 and the build with it.
+
+snapshot.debian.org keeps every revision Debian has published, at a stable
+path per timestamp. This is the first snapshot that carries 6.0-29, and the
+orig tarball has been in the pool since 2009, so both files resolve there
+and are the same bytes the pin always meant.
+
+diff --git a/protonfixes/Makefile b/protonfixes/Makefile
+index 4dcd851..8fab279 100644
+--- a/protonfixes/Makefile
+++ b/protonfixes/Makefile
+@@ -146,7 +146,7 @@ DEFINES = -DACORN_FTYPE_NFS -DWILD_STOP_AT_DIR -DLARGE_FILE_SUPPORT \
+  -DNO_WORKING_ISPRINT
+ UNZIP_VERSION := 6.0
+ UNZIP_DEBIAN_REVISION := 29
+-UNZIP_BASE_URL := https://deb.debian.org/debian/pool/main/u/unzip
+UNZIP_BASE_URL := https://snapshot.debian.org/archive/debian/20250311T215724Z/pool/main/u/unzip
+ UNZIP_ORIG_TARBALL := unzip_$(UNZIP_VERSION).orig.tar.gz
+ UNZIP_DEBIAN_TARBALL := unzip_$(UNZIP_VERSION)-$(UNZIP_DEBIAN_REVISION).debian.tar.xz
+ UNZIP_DOWNLOAD_DIR := $(OBJDIR)/downloads/unzip
@@ -0,0 +1,43 @@
+The x86_64 wine build gets VKD3D_PE_LIBS with a -L to the x86_64 vkd3d
+DLLs. That is right while a separate i386 wine build exists and gets its
+own value.
+
+A wow64-only build has no i386 wine build: the x86_64 one builds the i386
+PE side as well, and wine takes one VKD3D_PE_LIBS for every PE arch. The
+i386 wined3d.dll then links against the x86_64 libvkd3d-1.dll and fails
+with "file format not recognized". ld does not skip a mismatched DLL
+named with -l:, so listing both directories does not work either.
+
+Under wow64, keep the library names in VKD3D_PE_LIBS and pass each arch
+its own directory through i386_LDFLAGS and x86_64_LDFLAGS, which wine's
+configure already takes per arch. The i386 vkd3d was only ever built
+as a dependency of the i386 wine build, so the x86_64 one now waits for it.
+
+diff --git a/Makefile.in b/Makefile.in
+index f8d959c..2ac0b34 100644
+--- a/Makefile.in
+++ b/Makefile.in
+@@ -635,9 +639,23 @@ WINE_aarch64_AUTOCONF_ARGS = \
+ WINE_i386_AUTOCONF_ARGS += \
+   VKD3D_PE_CFLAGS="-I$(VULKAN_HEADERS_i386_DST)/include -I$(VKD3D_i386_DST)/include/vkd3d" \
+   VKD3D_PE_LIBS="-L$(VKD3D_i386_LIBDIR)/vkd3d/i386-windows -l:libvkd3d-1.dll -l:libvkd3d-shader-1.dll -l:libvkd3d-utils-1.dll"
+ifneq ($(findstring i386-unix,$(ARCHS)),)
+ WINE_x86_64_AUTOCONF_ARGS += \
+   VKD3D_PE_CFLAGS="-I$(VULKAN_HEADERS_x86_64_DST)/include -I$(VKD3D_x86_64_DST)/include/vkd3d" \
+   VKD3D_PE_LIBS="-L$(VKD3D_x86_64_LIBDIR)/vkd3d/x86_64-windows -l:libvkd3d-1.dll -l:libvkd3d-shader-1.dll -l:libvkd3d-utils-1.dll"
+else
+# Without i386-unix there is no i386 wine build, and the x86_64 one builds the
+# i386 PE side too (wow64). It links both, but VKD3D_PE_LIBS is one value for
+# every PE arch, so a -L in it would hand the i386 link the x86_64 DLLs. Name
+# the libraries there and give each arch its own directory through its own
+# LDFLAGS instead.
+WINE_x86_64_AUTOCONF_ARGS += \
+  VKD3D_PE_CFLAGS="-I$(VULKAN_HEADERS_x86_64_DST)/include -I$(VKD3D_x86_64_DST)/include/vkd3d" \
+  VKD3D_PE_LIBS="-l:libvkd3d-1.dll -l:libvkd3d-shader-1.dll -l:libvkd3d-utils-1.dll"
+WINE_i386-windows_LIBFLAGS = -L$(VKD3D_i386_LIBDIR)/vkd3d/i386-windows
+WINE_x86_64-windows_LIBFLAGS = -L$(VKD3D_x86_64_LIBDIR)/vkd3d/x86_64-windows
+$(OBJ)/.wine-x86_64-build: $(OBJ)/.vkd3d-i386-post-build
+endif
+ 
+ WINE_DEPENDS = ffmpeg openfst kaldi vosk libxml2 libxkbcommon libpcap
+ WINE_i386_DEPENDS = vkd3d