DaVinci Resolve gibt es für Linux. D astimmt erst mal alles dran. Nur einfach es tatsächlich zum Laufen zu bringen, war es nicht.

Ich wollte meine MKV-Aufnahmen aus OBS unter Fedora schneiden. Kein exotisches Kameramaterial, keine Kinoproduktion, keine acht verschiedenen RAW-Formate. Einfach Aufnahmen aus meinem Stream, dazu eine getrennte Facecam und später automatisch erzeugte Untertitel. Auf dem Papier ist das ein ziemlich überschaubarer Wunsch.

Mein Stand dabei: Fedora 44, eine Nvidia RTX 2070 Super und Resolve als Flatpak. AutoSubs lief bei der Einrichtung zunächst in Version 3.6.2. Bei anderen Versionen können Pfade und einzelne Schritte inzwischen anders aussehen.

In der Praxis musste ich erst Resolve in ein Flatpak verpacken, meine Videos in ein anderes Format umrechnen, Verzeichnisse durch eine Sandbox reichen und am Ende Steam davon überzeugen, einen Port freizugeben, den AutoSubs für sich beanspruchte.

Jetzt läuft es. Und wenn ich mir den Weg dorthin anschaue, ist das entweder eine Erfolgsgeschichte für Linux oder ein ziemlich gutes Beispiel dafür, wie unterschiedlich Menschen das Wort „läuft“ verwenden.

Resolve in eine passende Schachtel packen

Blackmagic Design bietet Resolve zwar für Linux an, richtet sich dabei aber offiziell an eine recht fest umrissene Umgebung. Fedora gehört nicht dazu. Ich hätte nun anfangen können, Bibliotheken auf meinem System passend zu biegen. Das war mir für eine große proprietäre Anwendung allerdings zu heikel.

Meine Lösung wurde resolve-flatpak von pobthebuilder. Das Projekt nimmt den offiziellen Installer von Blackmagic Design und baut daraus ein Flatpak. Resolve landet damit in einer eigenen Umgebung und verteilt seine Erwartungen nicht quer über mein Fedora-System.

Das Projekt beschreibt den grundsätzlichen Bau so:

git clone https://github.com/pobthebuilder/resolve-flatpak.git --recursive
cd resolve-flatpak

flatpak-builder \
  --install-deps-from=flathub \
  --force-clean \
  --repo=.repo \
  .build-dir \
  com.blackmagic.Resolve.yaml

flatpak --user remote-add --no-gpg-verify resolve-repo .repo
flatpak --user install resolve-repo com.blackmagic.Resolve

In meiner Installation heißt die Anwendung com.blackmagic.Resolve. Nicht com.blackmagic.ResolveStudio. Diese kleine Unterscheidung hat mich später beschäftigt, als ich mit remote-info nach einem Update suchen wollte und nur die Meldung bekam, das lokale Repository habe keine Summary-Datei. Denn: Mein resolve-repo war schlicht kein gewöhnlicher Flatpak-Server, sondern das lokale Ergebnis meines eigenen Builds. Ein Update kommt deshalb nicht automatisch über flatpak update. Ich muss das Git-Repository aktualisieren, Resolve neu bauen und die vorhandene Installation ersetzen:

git pull

flatpak-builder \
  --install-deps-from=flathub \
  --force-clean \
  --repo=.repo \
  .build-dir \
  com.blackmagic.Resolve.yaml

flatpak --user install --reinstall resolve-repo com.blackmagic.Resolve

Das ist mehr Arbeit als ein Klick im Software-Center. Dafür weiß ich ziemlich genau, woher das Paket kommt und was bei einem Update passiert. Ich finde diesen Tausch in Ordnung.

Resolve startete danach. Damit war ungefähr die Hälfte des Problems gelöst.

Eigentlich müsste alles laufen... Eigentlich.

Meine OBS-Aufnahme sah technisch vollkommen normal aus: H.264 Main, yuv420p, 30 Bilder pro Sekunde und AAC-Ton mit 48 Kilohertz. Genau die Art von Datei, die auf ziemlich jedem Gerät abgespielt wird, das nicht gerade eine Digitaluhr ist.

Resolve Free unter Linux hat bei H.264 und AAC allerdings eigene Vorstellungen. In der offiziellen Liste der unterstützten Formate für Resolve 19 ist H.264 unter Rocky Linux der Studio-Version mit Nvidia-Grafik vorbehalten. AAC wird dort gar nicht unterstützt. Fedora ist nicht Rocky Linux, aber an der entscheidenden Stelle half mir dieser Unterschied nicht: Mein Material ließ sich nicht so verwenden, wie es aus OBS kam.

Zuerst hoffte ich, ein einfaches Remuxing würde reichen. Dabei wird nur der Behälter gewechselt, ohne Bild und Ton neu zu codieren. Das wäre schnell gewesen und hätte keine zusätzliche Generation erzeugt. Aber ein H.264-Video mit AAC-Ton bleibt auch danach ein H.264-Video mit AAC-Ton.

Die funktionierende Lösung war deshalb FFmpeg und ein Schnittformat, mit dem Resolve unter Linux zuverlässig arbeiten konnte: DNxHR SQ in einer MOV-Datei, dazu unkomprimierter PCM-Ton.

ffmpeg -hide_banner -y \
  -i "$input" \
  -map 0:v:0 \
  -map 0:a? \
  -c:v dnxhd \
  -profile:v dnxhr_sq \
  -pix_fmt yuv422p \
  -c:a pcm_s16le \
  -f mov \
  "$output"

Das Video wird dabei deutlich größer. Sehr deutlich. Dafür kann Resolve es öffnen, flüssig bearbeiten und samt Ton wiedergeben. DNxHR LB und zusätzliche MOV-Metadaten hatte ich ebenfalls ausprobiert. In meinem Ablauf machten sie Probleme. DNxHR SQ mit PCM funktionierte.

Also blieb es dabei.

Aus dem einzelnen Befehl wurde später ein kleines Skript. Es beobachtet einen Eingangsordner mit inotifywait, nimmt neue MKV-Dateien und legt die umgerechneten MOV-Dateien in einem Resolve-Ordner ab. Dafür braucht es unter Fedora neben FFmpeg die inotify-tools:

sudo dnf install ffmpeg inotify-tools

Das ist zusätzlicher Speicherbedarf und ein weiterer Verarbeitungsschritt. Aber es ist auch eine klare Grenze zwischen Aufnahme und Schnitt: OBS produziert sichere MKV-Dateien, das Skript übersetzt sie automatisch und Resolve bekommt genau das Material, mit dem es umgehen kann.

Nicht elegant im Sinne von „Ich werfe jede Datei hinein und alles funktioniert“. Und leider auch nicht angenehm im Sinne von „Ich muss nicht mehr darüber nachdenken“.

Mein Videoschnitt ist eine Konvertierungsstrecke

Die Skripte nehmen mir die Befehle ab. Das Warten, die großen Zwischendateien und die zusätzlichen Arbeitsschritte bleiben.

Bei einem längeren Video sieht mein Ablauf inzwischen so aus: Ich lade die Aufzeichnung von Twitch herunter, weil ich natürlich immer vergesse, rechtzeitig meine lokale Aufnahme zu starten. Dann konvertiere ich sie in ein Format, das Resolve unter Linux zuverlässig verarbeitet. Genauso wie die Files, die OBS produziert. Ich schneide das Video und exportiere es. Anschließend konvertiere ich den Export noch einmal, damit daraus eine vernünftig große Datei wird, die ich bei YouTube hochladen kann.

Das Video wird also vor dem Schnitt übersetzt und danach wieder zurückübersetzt. Dazwischen liegt die eigentliche Arbeit, wegen der ich Resolve überhaupt geöffnet habe.

Bei Social-Media-Clips ist es nicht besser. Die Videos sind zwar kürzer, aber der Ablauf bleibt: schneiden, exportieren, erneut konvertieren. Ohne den letzten Schritt sind die Dateien für ein paar Sekunden oder Minuten Video erstaunlich unhandlich. Mit dem Schritt sind sie gut zu speichern und hochzuladen. Nur muss ich ihn eben jedes Mal machen.

Das funktioniert inzwischen zuverlässig. Der Workflow steht. Aber ein funktionierender Workflow ist nicht automatisch ein guter Workflow. Ich habe aus einem Kompatibilitätsproblem eine kleine Produktionsstraße gebaut. Sie rattert ordentlich vor sich hin, nur möchte ich eigentlich Videos schneiden und nicht hauptberuflich Dateiformate ineinander umfüllen.

Die Sandbox macht ihren Job

Das Flatpak löste meine Bibliotheksprobleme, brachte aber seine eigene Grenze mit. Eine Anwendung in einer Sandbox darf nicht einfach überall auf meine Dateien zugreifen. Das ist grundsätzlich gut. Beim Videoschnitt fällt es nur sofort auf, wenn das Rohmaterial außerhalb der freigegebenen Verzeichnisse liegt.

Einen Ordner kann ich Resolve gezielt mit Schreibzugriff freigeben:

flatpak override --user \
  --filesystem=~/Streaming/Rohmaterial:rw \
  com.blackmagic.Resolve

Anschließend lässt sich das Verzeichnis in Resolve unter Preferences, System und Media Storage eintragen. Ich gebe damit nicht pauschal mein gesamtes Home-Verzeichnis frei, sondern nur den Ort, an dem Resolve tatsächlich arbeiten soll.

Genau für solche Grenzen mag ich Flatpak. Bis ein Plugin auftaucht, das fest davon ausgeht, Resolve liege unter /opt/resolve und könne selbstverständlich auf /usr/lib zugreifen.

AutoSubs trifft auf zwei verschiedene Welten

Für meine Social-Media-Clips wollte ich AutoSubs verwenden. Das Projekt transkribiert lokal und kann die Untertitel direkt als gestaltete Clips in eine Resolve-Timeline schreiben. Unter Fedora kam AutoSubs 3.6.2 bei mir als RPM auf das System. Resolve lief aber im Flatpak.

Damit lebten beide zunächst nebeneinander her.

Das RPM legte sein Lua-Skript hier ab:

/opt/resolve/Fusion/Scripts/Utility/AutoSubs.lua

Die benötigten Ressourcen lagen unter anderem hier:

/usr/lib/autosubs/resources

Resolve im Flatpak konnte mit diesen Orten nichts anfangen. Der erste deutliche Hinweis war:

Could not find the AutoSubs app resources

Mein erster Versuch bestand darin, die Verzeichnisse per Flatpak-Override freizugeben. Das reichte nicht. Innerhalb eines Flatpaks ist /usr Teil der eigenen Laufzeitumgebung. Ein Verzeichnis vom Host lässt sich dort nicht so einhängen, wie ich es zunächst erwartet hatte.

Funktioniert hat ein anderer Weg: Ich habe das Lua-Skript in den Script-Ordner von Resolve innerhalb des Flatpak-Datenbereichs kopiert. Auch die AutoSubs-Ressourcen liegen nun innerhalb dieses Bereichs. Den fest eingetragenen Ressourcenpfad im Lua-Skript habe ich entsprechend angepasst.

Die entscheidenden Orte lagen damit nicht mehr unter /opt und /usr, sondern unterhalb von:

~/.var/app/com.blackmagic.Resolve/

Das ist kein besonders schöner Installationsweg. Er macht aber sichtbar, was hier eigentlich passiert: Das native RPM weiß nichts von der Flatpak-Installation, und das Flatpak weiß nichts von den Dateien des RPM. Ich musste die Brücke selbst bauen.

AutoSubs tauchte danach unter Workspace und Scripts in Resolve auf. Später fehlten noch Teile des Caption-Templates. Auch das war am Ende kein geheimnisvoller Resolve-Fehler, sondern eine unvollständige Ressourcenkette. Lua-Skript, Module, Bilder, Schriften und Fusion-Template müssen gemeinsam in der Umgebung liegen, die Resolve tatsächlich sieht. Nur die Startdatei zu kopieren genügt nicht.

Steam und der Untertitelserver

Als dann alles richtig aussah, meldete AutoSubs trotzdem:

Failed to send Exit via socket

Die Resolve-Integration von AutoSubs startet innerhalb von Resolve einen kleinen Lua-Server. Die AutoSubs-Oberfläche spricht ihn über 127.0.0.1 auf Port 56002 an.

Also habe ich nachgesehen, wer diesen Port benutzte:

ss -tanp | grep 56002

Die Antwort war Steam.

Nicht Resolve. Nicht AutoSubs. Steam hatte zufällig eine lokale Verbindung mit genau diesem Port aufgebaut. Wahrscheinlich war das kein dauerhaft reservierter Port, sondern schlicht Pech bei der automatischen Vergabe. Für AutoSubs war er trotzdem belegt.

Die Lösung war entsprechend unspektakulär:

steam -shutdown
pkill -f /usr/bin/autosubs

Danach habe ich AutoSubs einmal neu gestartet. Es funktionierte.

Es läuft, weil ich die Übergänge kontrolliere

Resolve unter Fedora zum Laufen zu bringen war bei mir nicht die eine Installation mit dem einen geheimen Befehl. Es waren vier Übergänge, die nicht zusammenpassten:

1. Der offizielle Linux-Installer erwartete eine andere Distribution. Das Flatpak gab ihm eine passende Umgebung.
2. OBS und Twitch liefern Material, das Resolve Free unter Linux nicht so verarbeitet, wie ich es brauche. Vor dem Schnitt übersetzt FFmpeg es in DNxHR SQ und PCM. Nach dem Export folgt die Übersetzung zurück in ein handliches Format für YouTube und Social Media.
3. AutoSubs wurde nativ installiert. Skript und Ressourcen mussten in den Datenbereich des Resolve-Flatpaks.
4. Die Verbindung lief über einen lokalen Port. Steam saß zufällig darauf.

Keines dieser Probleme war für sich besonders dramatisch. Zusammen erzeugten sie aber dieses typische Linux-Gefühl: Das Programm ist installiert, das Fenster geht auf und trotzdem beginnt die eigentliche Einrichtung erst jetzt.

Ich würde diesen Weg nicht allen empfehlen. Wer einfach nur Videos schneiden möchte, hat wenig davon, Dateiformate, Sandboxes und lokale Socket-Verbindungen kennenzulernen. Ich mag an meiner Lösung trotzdem, dass ich sie inzwischen verstehe. Meine Aufnahmen bleiben im offenen OBS-Workflow, die Untertitel entstehen lokal und die notwendigen Übersetzungen übernehmen kleine Skripte.

Nur unsichtbar werden die Übersetzungen dadurch nicht. Jede längere Twitch-Aufzeichnung läuft vor und nach dem Schnitt durch FFmpeg. Jeder kleine Social-Media-Clip wird erst exportiert und anschließend noch einmal auf eine handliche Größe gebracht. Die Skripte verhindern, dass ich jedes Mal Befehle zusammensuchen muss. Zeit, Speicherplatz und einen zusätzlichen Schritt kosten sie trotzdem.

Resolve läuft unter Fedora. Ich kann so arbeiten, das am Ende was rauskommt. Es nervt jetzt nur zuverlässig.