Wer DaVinci Resolve auf Linux mit einer AMD-Radeon-Karte einsetzt, kennt das Ritual. Footage importieren, Resolve startet, das Material erscheint mit rotem Rahmen und der Hinweis „media offline“ oder einer leeren Wellenform für das Audio. Trotz der aktuellen Resolve-Version 20.3.2 vom 12. Februar 2026 und dem inzwischen sehr stabilen Linux-Build hat sich an dieser Grundproblematik nichts geändert. H.264, H.265, AV1 und AAC sind aus Lizenzgründen entweder gar nicht oder nur eingeschränkt unterstützt, je nach Version und GPU. Mit Mesa 26.1 und dem freigeschalteten AV1-Encoder-Pfad auf AMD-Karten gibt es allerdings 2026 erstmals eine echte Chance, das Problem auf einer Debian-Workstation produktiv zu lösen, ohne ständig auf Handbrake auszuweichen.
Was Resolve auf Linux mit AMD wirklich nicht kann
Die offizielle Codec-Matrix von Blackmagic Design ist eindeutig. DaVinci Resolve free unterstützt auf Linux weder das Encoding noch das Decoding von H.264 und H.265, weil die entsprechenden Lizenzkosten von Blackmagic nicht in die kostenfreie Variante eingerechnet werden. Resolve Studio bringt H.264- und H.265-Unterstützung mit, aber auch hier nur eingeschränkt. Auf Linux funktioniert die Hardware-Beschleunigung dieser Codecs ausschließlich über CUDA und damit faktisch nur auf Nvidia-Karten. Wer eine Radeon RX 7000 oder neuer einsetzt, sieht in der Deliver-Tab-Auswahl zwar Resolve-eigene Hardware-Optionen, kann sie aber nicht nutzen, weil Blackmagic den AMD-Pfad auf Linux schlicht nicht freigeschaltet hat.
AAC-Audio ist ein eigenes Kapitel. Weder die Free- noch die Studio-Version decodiert oder encodiert AAC unter Linux. Ein MP4 mit H.265-Video und AAC-Tonspur ist damit auf einer Resolve-Linux-Installation doppelt unbrauchbar. AV1 ist die einzige nahezu positive Ausnahme. Die Free-Version dekodiert AV1-Streams, solange die Tonspur in PCM, MP3 oder einem unterstützten Format vorliegt, encodieren kann sie das Format aber nicht.
Warum das nicht an Linux liegt
In der Community taucht die Annahme regelmäßig auf, Linux selbst sei das Problem. Das ist nicht richtig. Mesa unterstützt AV1-Encoding via VAAPI seit Version 24.1, mit Mesa 26.1 vom Mai 2026 ist der Pfad auf RDNA-3- und RDNA-4-Karten so gut wie ausgereift. OBS Studio, FFmpeg, Kdenlive und Handbrake nutzen diese Pipeline routinemäßig. Was fehlt, ist die Anbindung in Resolve selbst. Blackmagic verlangt für proprietäre Codecs Lizenzen und schreibt den Hardware-Pfad nur für CUDA-Hardware aus, was AMD-Nutzer ausschließt.
Die Mesa-26.1-Wende und was sie für die Resolve-Pipeline bedeutet
Mesa 26.1 schaltet den AV1-Encoder auf AMD-Karten breit frei und behebt mehrere Stabilitätsprobleme früherer Versionen, insbesondere bei Constant-Bitrate- und Constant-Quality-Profilen. Für Debian-Nutzer heißt das konkret zwei Dinge. Wer eine Debian-Testing- oder Sid-Installation betreibt, hat Mesa 26.1 entweder bereits in den Paketquellen oder bekommt es in den nächsten Tagen über das normale Upgrade. Wer auf Debian 13 Trixie stable bleibt, kann Mesa über das Backports-Repository auf eine aktuellere Version ziehen, was bei Multimedia-Workstations ohnehin sinnvoll ist.
Mit Mesa 26.1 lässt sich der Resolve-Workflow neu aufbauen. Statt Material direkt in Resolve zu importieren, läuft eine Vorverarbeitung über FFmpeg mit VAAPI-Hardware-Encoding. Das Originalmaterial wird in ein Resolve-kompatibles Intermediate-Format überführt, in der Regel DNxHR HQ in einer MOV-Hülle mit PCM- oder ALAC-Audio. Diese Schicht legt zwar zusätzlichen Speicherbedarf auf die Festplatte, dafür arbeitet Resolve mit dem Intermediate so flüssig, wie es auf macOS oder Windows mit nativem H.265 läuft.
Warum DNxHR HQ und nicht ProRes
ProRes 422 wäre in vielen Schnitt-Pipelines die natürliche Wahl, ist auf Linux aber nicht vollständig in Resolve verfügbar. DNxHR HQ ist von Avid offen lizenziert, FFmpeg unterstützt es nativ über den dnxhd-Encoder, und Resolve liest und schreibt es ohne Einschränkungen. Für 4K-UHD-Material reicht DNxHR HQ in 10-Bit-Tiefe in den meisten Fällen aus, wer mit HDR oder höheren Anforderungen arbeitet, kann auf DNxHR HQX in 12 Bit wechseln. Die Dateigröße steigt deutlich gegenüber H.265, dafür entfallen alle Decodierungsprobleme.
Workflow 1: Transcoden auf DNxHR vor dem Resolve-Import
Der bewährte Ablauf für Debian-Nutzer mit AMD-GPU sieht so aus. Auf der Kommandozeile installiert man zunächst FFmpeg in einer aktuellen Version aus den Debian-Repos oder über deb-multimedia, falls die Repo-Version zu alt ist. Anschließend lassen sich die Quelldateien mit einem kurzen Befehl in das Intermediate-Format umwandeln. Für H.264- oder H.265-Eingaben mit PCM- oder MP3-Audio reicht ein direktes Umpacken des Videos in DNxHR, während die Tonspur unangetastet kopiert wird. Liegt AAC-Audio vor, muss zusätzlich auf PCM oder ALAC transcodiert werden, weil Resolve AAC weder lesen noch schreiben kann.
Wer regelmäßig größere Mengen Material verarbeitet, kann ein einfaches Bash-Skript anlegen, das einen Quellordner durchläuft und jede Datei in einen Zielordner mit der gewünschten DNxHR-Variante schreibt. Solche Skripte zirkulieren seit Jahren in den Foren von Blackmagic Design, Nobara Project und Arch Wiki. Eine sinnvolle Variante schreibt das Video in DNxHR HQ mit dem Pixelformat yuv422p, kopiert eine MP3- oder PCM-Tonspur unverändert und transcodiert AAC-Audio nach ALAC, das verlustfrei ist und sowohl von Resolve als auch von macOS- und Windows-Pipelines verstanden wird.
Der entscheidende Vorteil: Resolve kann mit DNxHR-Material vollständig hardwarebeschleunigt arbeiten, weil Decoding intern in der Resolve-eigenen Pipeline läuft und nicht über H.264- oder H.265-Pfade. Die fertigen Schnitte exportiert man wahlweise als ProRes, DNxHR oder über den nächsten Schritt direkt in AV1.
Audio-Sonderfall AAC
Ein Detail, das viele Einsteiger unterschätzt: Resolve verweigert Material mit AAC-Audio selbst dann, wenn das Video in einem kompatiblen Codec vorliegt. Eine MP4-Datei mit AV1-Video und AAC-Tonspur lädt zwar ein, zeigt aber stumme Wellenformen. Die saubere Lösung ist das vorzeitige Umwandeln des Audios. PCM in 24 Bit ist die universellste Variante, ALAC ist kompakter und ebenfalls verlustfrei. Beides funktioniert in Resolve ohne Probleme.
Workflow 2: AV1- und H.265-Export über das FFmpeg-Encoder-Plugin
Für Resolve Studio existiert seit längerem ein Encoder-Plugin von Blackmagic, das externe FFmpeg-Encoder im Deliver-Tab freischaltet. In der Arch-Welt heißt das Paket davinci-ffmpeg-encoder-plugin, auf Debian gibt es kein offizielles Äquivalent. Das Plugin selbst ist allerdings ein simpler FFmpeg-Wrapper und lässt sich nach Anleitung aus dem Blackmagic-Forum unter Debian manuell bauen. Voraussetzung sind installierte Header-Pakete von FFmpeg sowie ein zur Resolve-Version passendes SDK von Blackmagic.
Sobald das Plugin korrekt installiert ist, erscheinen im Deliver-Tab neue Encoder-Optionen für AV1 über SVT-AV1, für H.265 über x265 und für H.264 über x264. Diese laufen rein softwareseitig, was bei H.265 und AV1 spürbar Zeit kostet, dafür sind sie deterministisch und qualitativ kontrollierbar. Hardware-Beschleunigung bietet das Plugin offiziell nur über NVAPI, also für Nvidia-GPUs. Auf AMD-Karten lässt sich Hardware-AV1 außerhalb von Resolve über FFmpeg-VAAPI nutzen, indem man den DNxHR-Master aus Resolve exportiert und in einem separaten Schritt mit FFmpeg in AV1 oder H.265 umwandelt.
Genau dieser Zweistufenprozess hat sich als pragmatischste Lösung etabliert. Resolve liefert einen verlustarmen DNxHR-HQ-Master ab, FFmpeg übernimmt anschließend die hardwarebeschleunigte Auslieferung. Das spart Zeit gegenüber rein softwareseitigem Encoding, vermeidet Lizenzärger und nutzt die AV1-Hardware-Engine moderner Radeon-Karten optimal.
Beispielbefehle, die auf Debian funktionieren
Ein vereinfachter FFmpeg-Aufruf für AV1-Hardware-Encoding mit VAAPI sieht im Kern so aus, dass das DNxHR-Master als Input geöffnet, in NV12 konvertiert und über den av1_vaapi-Encoder geschrieben wird, mit Constant-Quality-Werten zwischen 24 und 30 für ausgewogene Qualität. Wer H.265 statt AV1 möchte, ersetzt av1_vaapi durch hevc_vaapi. Für CBR-Profile bei Streaming-Workflows lässt sich zusätzlich eine Zielbitrate setzen. Die exakten Befehle hängen vom jeweiligen Mesa-Build und der genutzten GPU-Generation ab, einen guten Ausgangspunkt bietet die offizielle Mesa-Dokumentation und das Arch-Wiki.
Debian-spezifische Einrichtung
DaVinci Resolve ist offiziell nur auf einigen Linux-Distributionen unterstützt, Debian gehört nicht dazu. Der Installer kommt im Zip-Format und richtet sich an CentOS- und Rocky-basierte Systeme. Auf Debian funktioniert die Installation trotzdem zuverlässig, wenn man die fehlenden Abhängigkeiten vorab nachpflegt. Das Tool makeresolvedeb von Daniel Tufvesson hat sich seit Jahren als Standardweg etabliert. Es nimmt den offiziellen Resolve-Zip-Installer entgegen, baut daraus ein sauberes Debian-Paket und installiert dieses inklusive der korrekten Pfade.
Wer Resolve Studio nutzt, sollte vor der Installation prüfen, ob die eingesetzte AMD-Karte über die OpenCL- oder ROCm-Pipeline angesprochen wird. Auf RDNA-3-Karten arbeitet Resolve produktiv mit der ROCm-Stack, was zusätzliche Pakete erfordert. Auf älteren Karten ist OpenCL über Mesa der zuverlässigere Pfad. Beide Wege sind in der Resolve-Dokumentation beschrieben, der praktische Konfigurationsschritt liegt in der Auswahl der GPU-Compute-API in den Resolve-Einstellungen.
Für die GUI-Integration auf Plasma, GNOME oder XFCE liefert makeresolvedeb sauberes Desktop-Entry-Material mit, sodass Resolve im Anwendungsmenü unter „Sound & Video“ oder „Multimedia“ erscheint. Wer mit Wayland auf Plasma 6.6 arbeitet, sollte sicherstellen, dass die GPU-Treiber-Pakete mesa-vulkan-drivers und firmware-amd-graphics aktuell sind. Resolve nutzt Vulkan-Pfade für Teile der UI-Beschleunigung.
Pakete, die unter Debian Trixie aktuell bleiben sollten
Drei Pakete entscheiden über den Erfolg der Pipeline. Erstens mesa und mesa-vulkan-drivers in einer Version ab 26.1, idealerweise über Backports oder Testing. Zweitens FFmpeg in einer Version, die SVT-AV1 und VAAPI vollständig mitbringt, was ab FFmpeg 7.x der Fall ist und in Debian Trixie standardmäßig vorhanden ist. Drittens libva und libva-drivers in aktuellen Versionen, weil die VAAPI-Pipeline ohne sie nicht arbeitet. Wer auf Debian 12 Bookworm bleibt, wird mit deutlich mehr Reibung leben müssen, der Sprung auf Trixie ist für Resolve-Workflows mit AMD-GPU faktisch Pflicht.
Wann sich der Aufwand lohnt und wann nicht
Der hier beschriebene Workflow ist alles andere als trivial. Wer nur gelegentlich kurze Videos schneidet, fährt mit Kdenlive oder Shotcut besser, weil beide nativ alle relevanten Codecs lesen und schreiben. Resolve lohnt sich für Color Grading, Fairlight-Audio-Mixing und komplexe Multitrack-Setups, in denen das volle Studio-Featureset gefragt ist. Sobald diese Anforderungen ins Spiel kommen, gibt es auf Linux praktisch keine ernsthafte Alternative.
Mit Mesa 26.1, der Resolve-20.3.2-Linux-Version und einer geordneten FFmpeg-Pipeline lässt sich auch auf einer Debian-Workstation mit Radeon-GPU ein vollständiger Editing- und Color-Grading-Workflow betreiben. Der Zwischenschritt über DNxHR HQ ist unbequem, dafür stabil und reproduzierbar. Der Ausstieg über AV1 via VAAPI nutzt die GPU-Hardware optimal aus und liefert kleinere Dateien als H.265 bei gleicher Qualität, was insbesondere für YouTube- und Streaming-Pipelines relevant ist.
Wohin sich die Resolve-Linux-Lage entwickelt
Die Hoffnung, dass Blackmagic Design die proprietären Codec-Pfade auf AMD-Linux freischaltet, ist nicht gestorben. Mit jeder neuen Resolve-Generation wächst die Liste der Linux-Verbesserungen, und der Druck steigt mit jeder neuen Radeon-Karte, die für Content-Creator-Workloads beworben wird. Bis dahin bleibt der hier beschriebene Zweistufenprozess der pragmatischste Weg, eine professionelle Editing- und Grading-Pipeline auf Debian zu betreiben. Wer ihn einmal eingerichtet hat, kommt damit zuverlässig durch komplette Projekte, einschließlich HDR-Color-Grading, mehrspuriger Audio-Mischung in Fairlight und finalem Mastering über AV1 oder H.265. Die fehlende native Codec-Unterstützung in Resolve auf Linux ist ein Ärgernis, aber kein Showstopper, solange Mesa und FFmpeg die Lücke füllen.
