Files
Flaro/server/Dockerfile
T
ScarriffleandClaude Opus 5 e4a90fce4e Stufe 3: Download mit allen Ton- und Textspuren
**Der Grund, warum es diesen Server gibt.** Eine MKV mit zwei Tonspuren geht
hinein, eine MP4 mit zwei Tonspuren kommt heraus — mitsamt Sprachkennung und
Spurnamen. Im Container nachgewiesen, nicht nur im Test:

    0 video     h264     und
    1 audio     aac      deu   Deutsch
    2 audio     aac      deu   Audiodeskription
    3 subtitle  mov_text deu

Jellyfins Transcode-Endpunkt bildet je Sitzung **eine** Tonspur ab und
verliert beim Umpacken zusätzlich die Sprachkennungen. Der Plan hier hat gar
kein Feld „welche Tonspur" — es gibt nichts auszuwählen, weil alle mitgehen.

**Vorher fragen können.** `GET /files/{id}/delivery` sagt, was geschehen wird:
umgepackt oder nicht, welche Tonspuren neu gerechnet werden müssen, welche
Untertitel nicht mitkönnen. Drei Gigabyte zu laden und erst danach zu merken,
dass die falsche Tonspur drin ist, war der Anlass für das Ganze.

**Umgepackt wird auf die Platte, nicht in die Antwort.** Der bequeme Weg wäre,
ffmpeg durchzureichen. Dann kennt aber niemand die Länge im Voraus: kein
Fortschrittsbalken, kein Fortsetzen, kein Springen. Jetzt kommt beim ersten
Abruf ein 202 mit Fortschritt, danach die fertige Datei mit `Content-Length`
und `Accept-Ranges`.

**Bildbasierte Untertitel fallen weg, und das steht im Plan.** PGS passt in
keine MP4 — betrifft fast jeden Blu-ray-Rip. Stillschweigend wegzulassen
hiesse, jemanden nach Untertiteln suchen zu lassen, die der Server bewusst
entfernt hat.

---

**Zwei Funde aus echten Messungen:**

*Die Spurnamen überlebten das Umpacken nicht* — „Deutsch" kam als `null` an,
und damit wären zwei deutsche Tonspuren hinterher nicht mehr zu unterscheiden
gewesen. Ein Versuch an einer echten Datei zeigte den Grund: **MP4 nennt das
Feld `name`, Matroska nennt es `title`.** ffmpeg schreibt das eine ins andere
um; mein Leser kannte nur `title`. Keine Grenze des Formats, ein Lesefehler.
`handler_name` steht ausdrücklich nicht in der Suche — dort schreibt ffmpeg
„SoundHandler" hinein.

*Der Image-Bau brach mit Code 100 ab.* `intel-media-va-driver` gibt es für
arm64 nicht, und die Meldung verrät nicht, welches von sechs Paketen fehlt.
Die Intel-Treiber kommen jetzt nur auf amd64 dazu; `mesa-va-drivers` bedient
AMD auf beiden.

---

**Die ffmpeg-Zeile ist eine reine Funktion und wird ohne Ausführen geprüft.**
Hier liegt die Erfahrung dieser Woche: eine falsche Parameterkombination
kostete Tage, weil sie nur gegen einen echten Server zu entdecken war. Dazu
gehört die Verwechslung, vor der jetzt ein Test steht: `-c:a:1` meint die
zweite Tonspur der **Ausgabe**, nicht Spur 1 der Datei.

ffmpeg läuft als eigener Prozess, nicht als eingebundene Bibliothek — das
hält die Lizenzen getrennt und lässt einen Absturz dort den Server nicht
mitnehmen.

223 Tests grün (98 Kern, 31 Metadaten, 26 Medien, 68 Schnittstelle).
Image baut für amd64 und arm64, mit ffmpeg 6.1.1 und VAAPI.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-03 17:14:55 +02:00

73 lines
3.0 KiB
Docker

# syntax=docker/dockerfile:1
# Gebaut wird auf der Architektur des Bauwirts, übersetzt wird für die des
# Ziels — `dotnet publish -a` kann das. Ohne diese Trennung liefe der Bau für
# arm64 unter Emulation und dauerte ein Vielfaches.
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build
ARG TARGETARCH
WORKDIR /src
# Erst die Projektdateien, dann wiederherstellen: so bleibt die
# Paket-Wiederherstellung in der Ebenenzwischenablage, solange sich keine
# Abhängigkeit ändert. Ohne diesen Schritt lädt jeder Bau alles neu.
# `--parents` behält die Verzeichnisse bei. **Ein Muster statt einer Liste**,
# weil eine Liste bei jedem neuen Projekt vergessen wird — und dann scheitert
# erst der Bau im Container, nicht der auf dem Arbeitsrechner.
COPY --parents src/*/*.csproj ./
RUN dotnet restore src/Halo.Api/Halo.Api.csproj -a $TARGETARCH
COPY . .
RUN dotnet publish src/Halo.Api/Halo.Api.csproj -a $TARGETARCH -c Release -o /app --no-restore
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
# ffmpeg und die Treiber für Hardware-Beschleunigung.
#
# **Als eigenes Programm, nicht als Bibliothek.** Halo ruft es als Prozess
# auf; damit bleiben die Lizenzen getrennt (ffmpeg steht unter GPL) und ein
# Absturz dort nimmt den Server nicht mit.
#
# `mesa-va-drivers` bedient AMD und ältere Intel, `intel-media-va-driver` die
# neueren Intel — beide über VAAPI an `/dev/dri`. Welcher greift, entscheidet
# sich zur Laufzeit danach, was durchgereicht wurde.
#
# **Die Intel-Treiber nur auf amd64.** Es gibt sie für arm64 nicht, und ein
# unbedingtes `apt-get install` liess den Bau dort mit Code 100 abbrechen —
# eine Meldung, die nicht verrät, welches der sechs Pakete fehlt.
ARG TARGETARCH
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
ffmpeg libva2 libva-drm2 mesa-va-drivers \
&& if [ "$TARGETARCH" = "amd64" ]; then \
apt-get install -y --no-install-recommends intel-media-va-driver i965-va-driver; \
fi \
&& rm -rf /var/lib/apt/lists/*
# **Die Verzeichnisse müssen hier angelegt werden, nicht erst beim Start.**
# Docker legt den Einhängepunkt eines frischen benannten Volumes sonst als
# `root` an und übernimmt für ein leeres Volume die Rechte aus dem Image —
# gibt es das Verzeichnis im Image nicht, erbt es `root:root`, und der erste
# Start scheitert für jeden, der kein Bind Mount benutzt.
RUN mkdir -p /config /cache /transcode && chown -R 1000:1000 /config /cache /transcode
# **Kein root.** Die Kennung 1000 ist die des ersten Benutzers auf fast jedem
# Linux und auf den üblichen NAS-Geräten — wessen Dateien anders gehören, setzt
# in der Compose-Datei `user: "<uid>:<gid>"`. Das ist Docker-Bordmittel und
# braucht weder ein Startskript noch root im Container.
USER 1000:1000
ENV HALO_DATA=/config \
HALO_CACHE=/cache \
HALO_TRANSCODE=/transcode \
ASPNETCORE_URLS=http://+:8080 \
DOTNET_gcServer=0
WORKDIR /app
COPY --from=build /app .
EXPOSE 8080
VOLUME ["/config", "/cache", "/transcode"]
ENTRYPOINT ["dotnet", "Halo.Api.dll"]