Video-Transcodierung auf dem Cloud-Mac-mini: eine FFmpeg + VideoToolbox Batch-Pipeline

Letzte Woche fragte ein Leser, der Videoschnitt im Outsourcing anbietet, in einem Support-Ticket nach: Ein Kunde hat ihm 200 4K-ProRes-Clips zugeschickt, die für die Lieferung in H.264 umgewandelt werden müssen. Auf dem Laptop dauert die Umwandlung eines einzelnen Clips 18 Minuten – bei der Warteschlange zieht sich das bis tief in die Nacht. Der Flaschenhals bei solchen Aufträgen ist nie die Wahl des Algorithmus, sondern der Encoder-Durchsatz – und der Hardware-Encoder VideoToolbox von Apple Silicon ist genau die Kapazität, die von den meisten Leuten unterschätzt wird.

Szenario: Warum die Transkodierung in die Cloud verlagern

Transkodierung ist eine klassische „sporadische Hochlast": Im Alltag ungenutzt, kurz vor der Lieferung geballt. Ein eigener Mac Studio, der die meiste Zeit ungenutzt herumsteht, lohnt sich nicht, und die GPU-Instanzen der Cloud-Anbieter sind meist auf das CUDA-Ökosystem ausgerichtet – H.264/HEVC-Hardware-Encoding muss dort über einen Umweg per Software-Encoding laufen. Der Vorteil eines dedizierten Mac mini liegt hier auf der Hand: VideoToolbox ist eine System-API auf OS-Ebene, die sich nicht um die Virtualisierungsschicht scheren muss. Man mietet tageweise eine Maschine, lässt sie durchlaufen und gibt sie danach zurück – Kosten und Zeitplan bleiben kontrollierbar.

Eine Faustregel: Die Transkodierzeit pro Clip multipliziert mit der maximalen Parallelität, multipliziert mit einem Puffer von Faktor 1,3, ergibt die Anzahl Tage, die du mieten solltest – plane nicht nach der „theoretischen Vollgeschwindigkeit", die Maschine braucht Pausen, Wiederholungsversuche und Puffer.

Was VideoToolbox tatsächlich beschleunigt

VideoToolbox verlagert die rechenintensiven Schritte von H.264/HEVC – Bewegungsschätzung, Transformation und Quantisierung – auf dedizierte Hardwaremodule der Media Engine; die CPU ist nur noch für Scheduling und Containerisierung zuständig. Im Vergleich zum Software-Encoding mit libx264:

Der Preis für diesen Vorsprung ist die Bildqualität: Bei gleicher Bitrate bleibt bei VideoToolbox etwas weniger Detail erhalten als bei x264 im langsamen Preset – bei normalem Betrachtungsabstand fällt das aber nicht auf und reicht für Batch-Lieferungen völlig aus.

Umgebung einrichten

Installation und Erkennung

Sobald der Cloud-Mac-mini bereitsteht, zuerst prüfen, ob der Hardware-Encoder verfügbar ist:

brew install ffmpeg
ffmpeg -encoders 2>/dev/null | grep videotoolbox

Wenn beide Zeilen h264_videotoolbox und hevc_videotoolbox erscheinen, ist alles in Ordnung. Wer nur die Bildqualität testen will, transkodiert zuerst ein kurzes Sample:

ffmpeg -i sample.mov \
  -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
  -c:a aac -b:a 192k \
  sample_out.mp4

Encoding-Parameter-Vergleichstabelle

Vor dem Batch-Lauf sollte eine Parameter-Vorlage festgelegt werden, damit nicht für jeden Clip spontan andere Parameter gesetzt werden und die Ausgabe inkonsistent wird:

Batch-Pipeline

Einen einzelnen Befehl abzusetzen kann jeder – Zeit spart wirklich erst, wer „Datei hineinwerfen, Ergebnis automatisch erhalten" als Pipeline laufen lässt.

Verzeichnis-Überwachungsskript

Ein Polling-Skript überwacht das Eingabeverzeichnis, legt neue Dateien in die Aufgabenwarteschlange und begrenzt die Parallelität, damit sich Jobs nicht um den Hardware-Encoding-Kanal streiten:

#!/bin/bash
WATCH_DIR="$HOME/incoming"
OUT_DIR="$HOME/transcoded"
MAX_JOBS=3

mkdir -p "$OUT_DIR"

while true; do
  for f in "$WATCH_DIR"/*.mov; do
    [ -e "$f" ] || continue
    base=$(basename "$f" .mov)
    lock="$OUT_DIR/${base}.lock"
    [ -e "$lock" ] && continue

    running=$(jobs -r | wc -l)
    if [ "$running" -ge "$MAX_JOBS" ]; then
      sleep 5
      continue
    fi

    touch "$lock"
    (
      ffmpeg -y -i "$f" \
        -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
        -c:a aac -b:a 192k \
        "$OUT_DIR/${base}.mp4" \
        && mv "$f" "$OUT_DIR/${base}.mov.done" \
        && rm -f "$lock"
    ) &
  done
  sleep 10
done

MAX_JOBS=3 ist ein Erfahrungswert, kein Allheilmittel – je nach Modell hat die Media Engine unterschiedlich viele Encoding-Kanäle. Am besten zuerst mit einem einzelnen Clip die Geschwindigkeit testen und die Parallelität schrittweise erhöhen, bis die Dauer pro Clip merklich zu steigen beginnt (meist ab mehr als 2-3 parallelen Jobs) – das ist dann die harte Obergrenze dieser Maschine.

Fallstricke und Checkliste

• Temporäre Dateien auf lokaler SSD ablegen: Kein Netzlaufwerk als Transkodier-Cache verwenden – I/O-Schwankungen lassen den Encoder leerlaufen und bremsen den Gesamtdurchsatz.
• Uneinheitliche Audio-Sample-Raten: Kundenmaterial mischt oft 44,1 kHz und 48 kHz – vor dem Batch-Lauf mit ffprobe durchscannen und vereinheitlichen, sonst kommt es beim Zusammenschnitt zu Bild-Ton-Versatz.
• Verlorene Farbraum-Tags: Bei HDR-Material nach der Transkodierung explizit -colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 setzen, sonst interpretiert der Player das Bild eventuell als SDR und es wirkt ausgegraut.
• Zurückgebliebene Lock-Dateien: Bricht das Skript unerwartet ab, bleiben .lock-Dateien zurück und blockieren die Warteschlange – eine zeitgesteuerte Bereinigung für Locks älter als 2 Stunden ergänzen.
• Speicherplatz-Kontingent: Vor und nach der Transkodierung liegen Dateien gleichzeitig vor und belegen doppelten Speicherplatz – vor dem Batch-Lauf berechnen, ob das Gesamtvolumen des Materials 70 % des eingebauten Speichers überschreitet.

Kapazitätsplanung: Welche Konfiguration mieten

Video-Transkodierung reagiert empfindlicher auf Speicherbandbreite und Storage-Durchsatz als auf das konkrete Chip-Modell – der Chip ist also nicht der entscheidende Faktor. Für den Alltagsbetrieb mit Batch-Lieferungen (jeweils einige Dutzend 4K-Clips) reicht in der Regel M4R M (M4 / 24 GB / 512 GB SSD, 40,8 $/Tag, 203,9 $/Monat) aus; wenn das Material groß ist, mehrere HEVC-Master parallel verarbeitet werden müssen oder Multitrack-Vorschau-Kompositionen anfallen, bietet M4R L (M4 Pro / 64 GB / 2 TB SSD, 60,6 $/Tag, 302,8 $/Monat) mehr Reserven bei Arbeitsspeicher und Storage, damit der Lauf nicht wegen zu wenig Cache mittendrin abbricht.

Häufig gestellte Fragen