- \n
- Der (meist schnellere) Grafikprozessor (die GPU) kann nur in Studio genutzt werden<\/li>\n
- Videos mit einer Aufl\u00f6sung \u00fcber 4k oder mehr als 60 Bildern\/s erfordern Studio<\/li>\n
- „KI“ Funktionen fehlen in der kostenfreien Version<\/li>\n
- K\u00fcnstliches erh\u00f6hen der Aufl\u00f6sung ist eine Studio-Funktion<\/li>\n<\/ul>\n
Neben diesen Beispielen existieren weitere Funktionalit\u00e4ten, auf die Nutzer der kostenfreien Edition verzichten m\u00fcssen. Am schwerwiegendsten sehe ich den ersten Punkt. Alle anderen sind f\u00fcr viele sicherlich vernachl\u00e4ssigbar. Ob man mit dem langsameren Rendern auf lediglich der CPU leben kann, h\u00e4ngt vom Umfang der Projekte ab. Und wie oft man damit arbeitet.<\/p>\n
G\u00e4ngige Codecs hinter Bezahlschranken<\/h2>\n
Ein gr\u00f6\u00dferes Problem erkennt man dagegen erst auf den zweiten Blick. Filmaufnahmen nutzen Container-Formate (oft MP4), die jeweils aus einem Video- und Audio-Codec bestehen. Beide Spuren zusammen bilden das Video mit Bild & Ton. Verschiedene Codecs dabei zum Einsatz kommen. Sehr h\u00e4ufig wird das alte H.264 eingesetzt. Es existiert seit geraumer Zeit, sodass nahezu jedes Ger\u00e4t sowie jede Software damit klar kommt. H.265 soll dies abl\u00f6sen – das j\u00fcngere Format hat sich seit einigen Jahren verbreitet. Weitere existieren, viele haben eine Gemeinsamkeit: Sie sind durch Patente verschiedener Unternehmen belastet. Das macht ihre Verwendung schwierig, sowie ggf. durch Lizenzzahlungen teuer.<\/p>\n
Man kann bereits erahnen, dass es hier komplex wird. DaVinci Resolve ver\u00f6ffentlicht daher zu jeder Version ein umfangreiches PDF-Dokument. Es listet auf, welche Codecs ihre Software pro Betriebssystem unterst\u00fctzt. F\u00fcr Version 20 ist es 14 Seiten lang.1<\/a><\/sup> Ab Seite 11 sind die Listen f\u00fcr GNU\/Linux zu finden, dort am Beispiel von Rocky Linux 8.6 aufgezeigt. Viele werden von der kostenfreien Version zumindest in eine Richtung (Encode\/Decode) unterst\u00fctzt. Doch leider gibt es ausgerechnet bei H.264 und H.265 gro\u00dfe Einschr\u00e4nkungen: Sie sind der kostenpflichtigen Studio-Edition vorbehalten.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2026\/01\/resolve20-codecs-gnu-linux-1024x406.jpg\")
<\/a><\/figure>\n<\/div>\nEs mag nachvollziehbar sein, dass Blackmagic Design dieses Risiko f\u00fcr kostenfreie Nutzer nicht eingehen m\u00f6chte. In der Praxis erzeugt das jedoch erhebliche Probleme: Sehr viele Kameras nutzen standardm\u00e4\u00dfig einen der beiden Video-Codecs. Sie sind in der kostenfreien Edition komplett unbenutzbar – weder f\u00fcr das Quellmaterial, noch als Ziel beim Rendern. Das Kaufen der Studio-Version mag f\u00fcr manche in Frage kommen. Insbesondere wer die Software nur gelegentlich nutzt, empfindet \u00fcber 300\u20ac sicherlich als zu hoch.<\/p>\n
Freie Codecs sind die L\u00f6sung<\/h2>\n
Das Problem kann gel\u00f6st werden, in dem man das Quellmaterial zuvor in ein offeneres Format umwandelt. Neben den belasteten H.264\/265 Codecs existieren l\u00e4ngst freie Alternativen, wie beispielsweise AV1 von der Alliance for Open Media (AOMedia)<\/em>. Oder VP9. Sie k\u00f6nnen frei verwendet werden – ohne problematische Patentanspr\u00fcche, sowie den daraus ggf. entstehenden Zahlungen f\u00fcr Rechtsstreit\/Lizenzkosten. Somit kann DaVinci Resolve diese Formate risikolos einbinden.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2026\/01\/sony-alpha-6400-codec.avif\")
<\/a>H.264 bei einer Sony Alpha 6400 (ab Werk)<\/figcaption><\/figure>\n<\/div>\n Sie m\u00f6gen etwas ungewohnt sein, weil sie bislang eine geringere Verbreitung aufweisen. Doch viele g\u00e4ngige Programme kommen damit zurecht. Schlie\u00dflich ist AV1 bereits 2018 erschienen. Das \u00e4ltere VP9 wurde 2012 erstmals ver\u00f6ffentlicht. Im Alltag sind sie dennoch recht unbekannt, weil Smartphones & Kameras zumindest im Standard bevorzugt klassische Platzhirsche nutzen. Ein MP4-Video mit H.265 funktioniert \u00fcberall. Man geht damit auf Nummer sicher und vermeidet potenzielle Probleme bei den Nutzern, die z.B. zu mehr Support-Anfragen f\u00fchren k\u00f6nnten.<\/p>\n
Schwierigkeiten gibt es nur noch vereinzelt und wenn, dann bei fremden Plattformen – etwa dem Hochladen eines Videos auf externe Dienste oder verschicken per Messenger. Beides soll uns nicht hindern: Schlie\u00dflich ist zun\u00e4chst das Rohmaterial betroffen, welches wir in Resolve importieren m\u00f6chten. Die fertig gerenderten Videos k\u00f6nnen wir optional in z.B. H.264 konvertieren, falls das notwendig ist.<\/p>\n
Passend Umwandeln mit ffmpeg<\/h2>\n
In meinem Beispiel-Szenario habe ich einen 6 Sekunden Clip inklusive Ton mit einer Sony Alpha 6400 aufgenommen. Sie nutzt standardm\u00e4\u00dfig H.264, das Video ist exakt 44 MB gro\u00df. Als Aufl\u00f6sung kommt 3840×2160 zum Einsatz (4K UHD<\/em>). Das verlangsamt die Umwandlung, mit 1080P (Full-HD) Material funktioniert es deutlich z\u00fcgiger. Durchgef\u00fchrt wurden die Tests auf einem AMD Ryzen 9 3900X (12 Kerne) mit 64 GB RAM.<\/p>\n
Viele Codecs k\u00f6nnen eine CQ\/CRF Parameter f\u00fcr die Qualit\u00e4t nutzen. Man erspart sich damit komplexe technische Angaben zur Qualit\u00e4t und sorgt daf\u00fcr, dass diese gleich bleibt. Bei VP9 und X264 ist das ein Wert von 0 – 63, f\u00fcr die h\u00f6chste und 63 f\u00fcr die niedrigste steht. 23 ist meist ein guter Mittelwert, der keine optisch sichtbaren Qualit\u00e4tsverluste zeigt. Die ffmpeg Doku empfiehlt sogar 31 f\u00fcr 1080p (Full-HD) Videos. Da es sich um Rohmaterial sowie eine h\u00f6here Aufl\u00f6sung handelt, nutze ich etwas h\u00f6here Werte.<\/p>\n
AV1 (Empfohlen)<\/h3>\n
In ffmpeg sind insgesamt drei Encoder f\u00fcr AV1 enthalten. Mit
libsvtav1<\/code> erreichen wir deutlich kleinere Dateien (20,1 MB) bei vergleichbarer Qualit\u00e4t. CRF 23 wird als visuell verlustfrei angesehen, mit 20 haben wir also ebenfalls sogar noch etwas puffer. Mit nur 8 Sekunden funktionierte dies beim Testvideo mit Abstand am schnellsten. Er eignet sich daher am besten, um das Quellmaterial f\u00fcr DaVinci Resolve aufzubereiten.<\/p>\nffmpeg -i C0269.MP4 -c:v libsvtav1 -crf 20 -c:a pcm_s16le C0269_crf20_av1_pcm_s16le.mkv<\/code><\/pre>\nVP9<\/h3>\n
Man kann ihn mit den Containerformaten WebM oder MP4 einsetzen. Der VP9 Codec wird von Resolve (kostenfrei) unterst\u00fctzt, allerdings nicht alle Audio-Codecs. Alternativ kann f\u00fcr webm der
libvorbis<\/code> Audio-Codec genutzt werden. Dieser bietet eine schlechtere Qualit\u00e4t, weswegen ichpcm_s16le<\/code> bevorzuge. Dadurch wechseln wir das Container-Format von webm auf mov. Die Dateigr\u00f6\u00dfe erh\u00f6ht sich moderat auf 53,7 MB mit CRF 20. Bei 23 bleibt sie gleich. <\/p>\nffmpeg -i C0269.MP4 -c:v libvpx-vp9 -crf 20 -c:a pcm_s16le C0269_crf20_a-pcm_s16le.mkv<\/code><\/pre>\nAllerdings ist der Prozess langsam: F\u00fcr das 4s Testvideo genehmigte sich ffmpeg insgesamt 2:08 min Zeit. F\u00fcr produktive Aufnahmen kann man ihn daher leider kaum brauchen, weil die Verarbeitungszeit unverh\u00e4ltnism\u00e4\u00dfig hoch ausf\u00e4llt.<\/p>\n
Funktionsf\u00e4hige Alternativen mit Nachteilen<\/h3>\n
Funktionierend, aber nicht empfehlenswert ist DNxHD. Es erzeugt sehr gro\u00dfe Dateien, die selbst als tempor\u00e4res Rohmaterial unn\u00f6tig viel Schreiblast erzeugen. Aus einem 27MB gro\u00dfen H.265 Video wurde damit eine 4,9 GB (!) gro\u00dfe Datei. Hierbei handelte es sich nicht um das 6 Sekunden Testvideo, sondern eines aus dem Alltag. In Anbetracht der L\u00e4nge von lediglich 58 Sekunden ist die Gr\u00f6\u00dfe unverh\u00e4ltnism\u00e4\u00dfig hoch. Sicherlich l\u00e4sst sich das durch z.B. Qualit\u00e4tsreduzierungen noch etwas optimieren. Dennoch ist die Effizienz \u00fcberschaubar und liegt deutlich unter den oben genannten besseren Alternativen.<\/p>\n
ffmpeg -i C0016_x265.mp4 -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le C0016_dnxhd.mov<\/code><\/pre>\nEinfache Nutzung im Alltag mit eigenem Bash-Alias<\/h2>\n
Nun m\u00f6chte man derart lange Befehle nicht st\u00e4ndig eintippen m\u00fcssen: Einsteiger werden anfangs m\u00fche haben, bis sie mit dem Aufbau von ffmpeg vertraut sind. Selbst wenn das gegeben ist, nervt es irgendwann. Daher habe ich mir daf\u00fcr ein Bash-Alias
dar-in<\/code> als Abk\u00fcrzung f\u00fcr DaVinci Resolve Input in der~\/.bashrc<\/code> angelegt:<\/p>\nfunction dar-in() {\n if [ $# -ne 2 ]; then\n echo -e "Fehler: 2 Argumente m\u00fcssen angegeben sein!\\ndar-in \/pfad\/quelldatei.mp4 \/pfad\/zielordner" >&2\n return 1\n fi\n\n\tsrcPath=$1\n\tfileFull=$(basename "$srcPath")\n\tfile="${fileFull%.*}"\n\tdestPath=$2\n\tfullDestFile="$destPath\/${file}_av1-crf20.mkv"\n\n\techo "Ziel: $fullDestFile"\n\ttime ffmpeg -i "$srcPath" -c:v libsvtav1 -crf 20 -c:a pcm_s16le "$fullDestFile"\n}<\/code><\/pre>\nSie erwartet als ersten Parameter den Pfad zur Quelldatei, die von einer Kamera kommend f\u00fcr Resolve aufbereitet werden soll. Es folgt der Zielpfad f\u00fcr das kompatibel umgewandelte Video. Den Dateiname \u00fcbernehmen wir aus der Quelldatei, versehen ihn mit einem Suffix zu Format & Qualit\u00e4t sowie der passenden Erweiterung MKV. Nach dem folgenden Aufruf erhaltet ihr in
~\/Videos\/C0016_av1-crf20.mkv<\/code> eine Videodatei, welche Resolve uneingeschr\u00e4nkt importieren kann.<\/p>\ndar-in C0016.mp4 ~\/Videos<\/code><\/pre>\nRendern des fertigen Videos mit DaVinci Resolve<\/h2>\n
W\u00e4hrend wir damit das erste Problem f\u00fcr die Rohvideos gel\u00f6st haben, k\u00f6nnen sie in Resolve zum gew\u00fcnschten Video geschnitten werden. Doch es gibt noch ein weiteres Problem: Die Software bietet in der kostenfreien Version g\u00e4ngige Codecs wie H.264\/265 \u00fcberhaupt nicht an – weder als Eingangsmaterial, noch f\u00fcr das gerenderte fertige Ausgangsvideo. Hier k\u00f6nnen wir gro\u00dfe Dateien zwar nicht komplett verhindern, doch es gibt ebenfalls L\u00f6sungen mit einem kleinen Umweg.<\/p>\n
Im QuickTime [sic] Format kann der DNxHR-Codec ausgew\u00e4hlt werden. DNxHR HQX<\/em> und DNxHR HQ<\/em> stehen f\u00fcr sehr hohe Qualit\u00e4t mit entsprechender Dateigr\u00f6\u00dfe. Zur Einordnung: Avid DNXHR<\/em> HQ<\/em> (Quality: Best<\/em>) erzeugt aus einem knapp 4 Minuten (3:53 min) langem 4k Rohmaterial satte 20GB. Stellt man die Qualit\u00e4t unten von Best<\/em> auf High<\/em>, reduziert sich die Gr\u00f6\u00dfe im selben Profil auf 13,2 GB. Au\u00dferdem dauert das Rendern nur noch 01:21 Min statt 02:05 Min.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2026\/01\/resolve-render.avif\")
<\/a><\/figure>\n<\/div>\nIch nutze Avid CNxHR SQ 12-bit<\/em> mit Quality: High<\/em>. Der SQ-Codec hat eine Bitrate von 200-300 Mbps und liefert eine visuelle gute Qualit\u00e4t, bei der ich selbst mit dezentem Vergr\u00f6\u00dfern keine Verluste erkennen kann. Wer stark Zoomen m\u00f6chte, mag das letzte Qu\u00e4ntchen heraus kitzeln m\u00fcssen. F\u00fcr mich reicht das v\u00f6llig, die Dateigr\u00f6\u00dfe h\u00e4lt sich damit in Grenzen.<\/p>\n
Archivierung mit H.265<\/h2>\n
In jedem Falle ist die Effizienz der von Resolve bereitgestellten Codecs f\u00fcr die dauerhafte Speicherung nicht zufriedenstellend. Selbst nach den Optimierungen entstehen noch immer riesige Dateien f\u00fcr weniger als 4 Minuten Videomaterial. Das l\u00e4sst sich mit ffmpeg l\u00f6sen: Man kann damit recht einfach das Video in eine MP4-Datei mit H265 Codec umwandeln.<\/p>\n
ffmpeg -i demo.mov -vcodec libx265 demo_x265.mp4<\/code><\/pre>\nWie im obigen Shell-Alias demonstriert, l\u00e4sst sich die Qualit\u00e4t per CRF auf Wunsch beeinflussen. Selbst mit hohem CRF liegt die Dateigr\u00f6\u00dfe weit unter Resolve. Einziges Manko: Das Umwandeln von 4K Videos dauert auf der CPU ziemlich lange (Geschwindigkeit 0,5x). Obwohl es sich um einen leistungsstarken 12-Kerner handelt, der nahezu konstant \u00fcber 80% ausgelastet wird. Mit weniger leistungsstarker Hardware ist es noch langsamer.<\/p>\n
\n![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2026\/01\/ffmpeg-btop.avif\")
<\/a><\/figure>\n<\/div>\nDaf\u00fcr schrumpft die 13,2 GB gro\u00dfe Datei auf 112 MB. Von 4k auf 1080P herunter skaliert, sind es sogar nur 36 MB.<\/p>\n
Reduzierung der Aufl\u00f6sung<\/h2>\n
Wer noch mehr Zeit & Speicherplatz sparen m\u00f6chte, sollte \u00fcber eine Reduzierung der Aufl\u00f6sung nachdenken. Das herunter skalieren von 4K Videos auf 1080P hat in meinen Tests beides deutlich reduziert. W\u00e4hrend DaVinci Resolve Studio durch den GPU-Einsatz auch 4K Videos in akzeptabler Geschwindigkeit verarbeiten kann, l\u00e4uft das auf der CPU leider deutlich schleppender.<\/p>\n
Ich empfehle, zuvor zu \u00fcberlegen, was man mit den Aufnahmen machen m\u00f6chte. 1080P (Full-HD) ist nach wie vor f\u00fcr vieles ausreichend, auch auf dem Desktop. Werden die Videos lediglich auf dem kleinen Handy konsumiert, ist 4K nur unn\u00f6tige Ressourcenverschwendung. Die gr\u00f6\u00dften Vorteile bietet 4K, wenn man st\u00e4rker Vergr\u00f6\u00dfern m\u00f6chte. Selbst in gr\u00f6\u00dferem Umfang reicht die Pixeldichte f\u00fcr ein hochwertiges 1080P Video. Liegt das Eingangsmaterial dagegen bereits in Full-HD vor, kann ein sichtbarer Qualit\u00e4tsverlust entstehen.<\/p>\n
Im Zweifel w\u00fcrde ich mich f\u00fcr die h\u00f6here Aufl\u00f6sung entscheiden. Mit ffmpeg optimiert ist der Speicherverbrauch von etwa 36 MB (FHD) gegen\u00fcber 112 MB (4K) mit Faktor 3 \u00fcberschaubar.<\/p>\n
\u00c4ndern des Formats<\/h2>\n
Handelt es sich um selbst aufgenommenes Videomaterial, lohnt sich ein Blick in die Einstellungen der Kamera. M\u00f6glicherweise l\u00e4sst sich dort ein alternatives Format einstellen, welches von Resolve nativ unterst\u00fctzt wird. Damit entf\u00e4llt zumindest die Umwandlung des Eingangsmaterials. Ob das m\u00f6glich ist, h\u00e4ngt allerdings vom Ger\u00e4t ab. Nicht jedes bringt einen Zoo an Codecs mit. Selbst Systemkameras machen es sich einfach und unterst\u00fctzen nur wenige, um Implementierungsaufwand zu sparen. Einen Versuch ist es dennoch wert, da es etwas Arbeit im Schnitt einsparen kann.<\/p>\n
Fazit: H\u00fcrden lassen sich \u00fcberwinden<\/h2>\n
Leider kann die kostenfreie Edition von Resolve g\u00e4ngige Codecs nicht direkt verarbeiten. Dies zeigt die Problematik von unfreier Software ein weiteres mal. Freie Projekte wie Kdenlive sind leistungsstark geworden, um viele Szenarien abdecken zu k\u00f6nnen – insbesondere f\u00fcr den Hobby-Einsatz. Wer dennoch Resolve ben\u00f6tigt (etwa wegen der m\u00e4chtigen Farbkorrektur), muss einen Umweg gehen. Mit leistungsstarkem Prozessor ist dieser hinnehmbar.<\/p>\n
Insbesondere f\u00fcr die h\u00e4ufigere Nutzung kann eine pragmatische Kompromissl\u00f6sung im Kauf einer Studio-Lizenz bestehen. Sie ist mit gut 300\u20ac nicht absurd teuer und bietet neben der g\u00e4ngigen Codecs noch weitere Vorteile, wie etwa das Rendern \u00fcber den Grafikprozessor. Das kann die Arbeit deutlich beschleunigen, insbesondere mit h\u00f6heren Aufl\u00f6sungen.<\/p>\n
Quellen<\/h2>\n
- \n
- https:\/\/documents.blackmagicdesign.com\/SupportNotes\/DaVinci_Resolve_20_Supported_Codec_List.pdf?_v=1751871610000<\/a> \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Videoschnitt mit GNU\/Linux ist l\u00e4ngst kein K.O. Kriterium mehr. Neben freier Software wie Kdenlive existieren sehr umfangreiche propriet\u00e4re Programme, wie DaVinci Resolve. Es wurde bereits f\u00fcr die Produktion von Blockbustern genutzt und l\u00e4sst dem Nutzer die Wahl: GNU\/Linux, oder die unfreien Betriebssysteme Windows & MacOS. W\u00e4hrend Resolve grunds\u00e4tzlich funktioniert, gibt es allerdings Schwierigkeiten mit g\u00e4ngigen …<\/p>\n","protected":false},"author":5,"featured_media":16189,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"https:\/\/documents.blackmagicdesign.com\/SupportNotes\/DaVinci_Resolve_20_Supported_Codec_List.pdf?_v=1751871610000<\/a>\",\"id\":\"81ec3380-5729-40b0-a811-7654c233f8db\"}]"},"categories":[74],"tags":[1078],"class_list":["post-16164","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","tag-davinci-resolve"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=16164"}],"version-history":[{"count":20,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16164\/revisions"}],"predecessor-version":[{"id":16194,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/16164\/revisions\/16194"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/16189"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=16164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=16164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=16164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- https:\/\/documents.blackmagicdesign.com\/SupportNotes\/DaVinci_Resolve_20_Supported_Codec_List.pdf?_v=1751871610000<\/a> \u21a9\ufe0e<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"