kaustubhupadhyaya/video-tool-router

Video Tool Router

Wählen Sie das günstigste Werkzeug, das die Aufgabe vollständig erfüllt. Auf diesem Rechner ist die Transkodierungsqualität quellenbegrenzt und nicht differenzierend (jedes Werkzeug erreicht VMAF 98,4–99,8). Wählen Sie niemals ein Werkzeug aus, "weil es qualitativ hochwertiger ist" für eine einfache Transkodierung. Wählen Sie DaVinci Resolve nur, wenn die Aufgabe KORRIGIEREND oder KREATIV ist (Grading, Tone-Mapping, Denoising, Stabilisierung, Upscaling, Multi-Clip-Finish) – nur dort ist es das richtige Werkzeug. Es kostet etwa das 15-fache der FFmpeg-Zeit plus aufwendigere Einrichtung, und sein Vorteil bei Grading/Denoising/Stabilisierung/Upscaling ist eine branchenübliche Erwartung, NICHT etwas, das der untenstehende Benchmark gemessen hat (dieser Benchmark deckt nur einfache Transkodierung ab).

Entscheidungsbaum (die erste passende Regel anwenden)

1. Keine Pixeländerung – Schneiden / Trimmen / Zusammenfügen / Verketten / Remuxen / Containerwechsel / Audio extrahieren -> FFmpeg Stream-Copy (-c copy). ~1,2 s, verlustfrei. Schnellster echter Schnitt – immer bevorzugen, wenn sich Pixel nicht ändern müssen. Zwei Einschränkungen: (a) Der Schnitt ist keyframe-genau, nicht framegenau – der Start rastet auf das nächste Keyframe ein; bei Bedarf an exakten Framegrenzen neu codieren. (b) Das Ausgabeformat bleibt im Quellcodec (HEVC) – wenn ein H.264-Ergebnis benötigt wird, gilt diese Regel nicht; zu Regel 2 gehen.

2. Transkodieren / skalieren / komprimieren (Pixel ändern sich, keine Korrektur) -> FFmpeg libx264. Standard -preset medium -crf 20. veryfast/ultrafast verwenden, wenn Geschwindigkeit zählt – die Qualität unterscheidet sich kaum (ultrafast erreicht immer noch VMAF 99,66). veryslow nur verwenden, wenn Speicher/Bandbreite begrenzt sind – 40-mal mehr Rechenleistung gegenüber ultrafast bringt +0,12 VMAF (unsichtbar), halbiert aber fast die Dateigröße. Selbst dann erfasst medium bereits fast die gesamte Größenreduzierung (13,3 MB vs. 12,6 MB bei veryslow), daher lohnt sich veryslow selten für das etwa 6-fache der Zeit von medium.

3. Stille / tote Luft bei Talking-Head- oder Tutorial-Audio entfernen -> auto-editor. ACHTUNG: Sehr langsam bei HEVC (Software-Decodierung) und hilft NUR, wenn das Audio tatsächlich Lücken hat. Sinnlos bei Aufnahmen mit durchgehendem Audio (Fahrt-/Straßen-/Musikclips) – es wird ~30+ Minuten rechnen und 0 Sekunden schneiden.

4. Programmatische Montage – Skriptgesteuerte Schnitte + Text/Overlays/Übergänge in Python -> MoviePy 2.x. Erwarten Sie etwa FFmpeg-Geschwindigkeit plus Python-Overhead. Verwenden, wenn die Kompositionslogik einfacher im Code als in einem langen ffmpeg filter_complex ist.

5. Color Grading / HLG->SDR Tone-Mapping / Denoising / Stabilisierung / Upscaling (SuperScale) / Multi-Clip kreatives Finish -> DaVinci Resolve über Python API. Der einzige Bereich, in dem "in Resolve machen" richtig ist. ~15-fache FFmpeg-Zeit, farbverwaltet (kein transparenter Durchlauf). Sein Qualitätsvorteil ist hier branchenüblich, nicht unten bewertet. Einrichtung in einem eigenen Abschnitt.

6. 3D-Titel / Motion-Graphics -> Blender Headless -> PNG-Frames -> ffmpeg muxen. HINWEIS: Der Enum image_settings.file_format von Blender 5.1 hat KEINE FFMPEG/Video-Option. Versuchen Sie NICHT image_settings.file_format='FFMPEG' oder skriptgesteuerten VSE-Videoexport – es ist in dieser Version fehlerhaft. Rendern Sie Bildframes, dann muxen Sie mit ffmpeg.

7. KI-/textbasierte Bearbeitung (nach Transkript bearbeiten, Füllwörter entfernen, "kürzer machen") -> Descript MCP.

Exakte Befehle (kopierbar)

1. Stream-Copy (keine Neucodierung)

# trimmen: -t ist DAUER (eindeutig). Schnitt ist keyframe-genau, Ausgabe bleibt HEVC.
ffmpeg -ss 10 -i in.mov -t 15 -c copy out.mov
# concatenate (list.txt Zeilen: file 'clip1.mov')
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mov
# Container remuxen / Audio extrahieren (keine Neucodierung)
ffmpeg -i in.mov -c copy out.mp4
ffmpeg -i in.mov -vn -c:a copy out.m4a

(Verwenden Sie -t <Sekunden> für die Dauer. Vermeiden Sie -ss ... -to ... mit -c copy: Der Referenzpunkt von -to ist bei Eingabe-Suche mehrdeutig und kann die falsche Länge erzeugen. Für eine exakte Framegrenze entfernen Sie -c copy und codieren neu – das führt die HEVC-Dekodierungskosten wieder ein.)

2. HEVC -> H.264 transkodieren

# Standard-Balance
ffmpeg -i in.mov -c:v libx264 -preset medium -crf 20 -c:a aac -b:a 192k out.mp4
# Geschwindigkeit zuerst (Qualität unterscheidet sich kaum)
ffmpeg -i in.mov -c:v libx264 -preset veryfast -crf 20 -c:a aac -b:a 192k out.mp4
# Auf 720p skalieren während der Transkodierung
ffmpeg -i in.mov -vf scale=-2:720 -c:v libx264 -preset medium -crf 20 -c:a aac out.mp4

3. Stille entfernen

auto-editor in.mp4 --edit audio:threshold=4% -o out.mp4
# Schnitt zuerst prüfen, falls unsicher ob Audio überhaupt Lücken hat:
auto-editor in.mp4 --edit audio:threshold=4% --preview

4. MoviePy 2.x (umbenannte API: subclipped / with_position / with_duration)

from moviepy import VideoFileClip, TextClip, CompositeVideoClip
clip = VideoFileClip("in.mov").subclipped(10, 25)
# HINWEIS: MoviePy 2.x TextClip benötigt einen Schriftart-DATEIPFAD, keinen Familiennamen wie "Arial".
txt = (TextClip(text="Hallo", font=r"C:\Windows\Fonts\arial.ttf", font_size=48, color="white")
       .with_duration(5).with_position("center"))
final = CompositeVideoClip([clip, txt])
final.write_videofile("out.mp4", codec="libx264", preset="medium",
                      ffmpeg_params=["-crf", "20"])

6. Blender 3D/Motion-Graphics -> Frames -> muxen

# Animation zu PNG-Frames rendern (NICHT file_format='FFMPEG' auf 5.1 setzen)
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# Frames zu H.264 muxen (-framerate an die Szene-fps anpassen)
ffmpeg -framerate 30 -i frames/f_%04d.png -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p out.mp4

HLG-Guard (VOR JEDEM SDR-H.264-EXPORT AUSFÜHREN)

Einige iPhone-Aufnahmen sind 10-Bit-HLG. Ein naiver libx264-Export nach SDR ergraut/entfärbt das Bild, wenn kein Tone-Mapping durchgeführt wird.

# 1. Übertragungskennlinie auslesen
ffprobe -v error -select_streams v:0 -show_entries stream=color_transfer -of default=nk=1:nw=1 in.mov

• Ausgabe arib-std-b67 (HLG) oder smpte2084 (PQ) -> Aufnahme ist HDR: Tone-Mapping vor/während der Codierung.
• Alles andere (bt709, unbekannt) -> bereits SDR: normalen Transkodierungsbefehl verwenden.

# 2. HLG/PQ -> SDR BT.709 Tone-Mapping + H.264 in einem Durchgang (und Ausgabe als bt709 markieren)
ffmpeg -i in.mov -vf \
"zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" \
-c:v libx264 -preset medium -crf 20 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-c:a aac -b:a 192k out_sdr.mp4

npl=100 ist die nominale Spitzenluminanz für die Linearisierung; erhöhen Sie sie, wenn helle Lichter übersteuern. Alternative: Lassen Sie DaVinci Resolve's Farbmanagement die Konvertierung Rec.2020-HLG -> Rec.709 durchführen (leiten Sie zu Resolve weiter, wenn Sie ohnehin graden – das macht es präziser als das ffmpeg-Tonemap).

DaVinci Resolve Python API Einrichtung (der korrigierende/kreative Pfad)

Eingebaute GOTCHAS: Muss auf Python 3.11 (py -3.11) ausgeführt werden – die Standardversion 3.14 kann fusionscript.dll nicht initialisieren. RESOLVE_SCRIPT_API / RESOLVE_SCRIPT_LIB sind persistierte Umgebungsvariablen. Resolve muss ausgeführt werden (oder starten Sie es mit -nogui). Verwenden Sie ein temporäres Projekt, legen Sie Format+Codec explizit fest, rendern Sie und fragen Sie ab.

# Ausführen mit:  py -3.11 resolve_render.py
import os, sys, time
sys.path.append(os.path.join(os.environ["RESOLVE_SCRIPT_API"], "Modules"))  # erforderlicher Header
import DaVinciResolveScript as dvr

resolve = dvr.scriptapp("Resolve")          # Resolve muss bereits laufen (oder starten Sie es zuerst -nogui)
pm      = resolve.GetProjectManager()

proj_name = "temp_render_" + str(int(time.time()))   # Name erhalten, damit Bereinigung ihn finden kann
proj    = pm.CreateProject(proj_name)
pool    = proj.GetMediaPool()
items   = resolve.GetMediaStorage().AddItemListToMediaPool([r"C:\in\clip.mov"])
tl      = pool.CreateTimelineFromClips("temp_timeline", items)   # setzt es auch als aktuell

# ---- die Verbesserung anwenden, die Resolve hier rechtfertigt ----
# (Color Grading / Projekt-Farbmanagement für HLG->SDR / SuperScale Upscaling / Denoising / Stabilisierung)

proj.SetCurrentRenderFormatAndCodec("mp4", "H264")   # explizites Format + Codec
proj.SetRenderSettings({
    "TargetDir": r"C:\out",
    "CustomName": "out",
    "SelectAllFrames": True,
})
pid = proj.AddRenderJob()
proj.StartRendering(pid)

while proj.IsRenderingInProgress():                   # Render- + Warteschleife
    time.sleep(1)
print("render:", proj.GetRenderJobStatus(pid))

# Bereinigung: aktuelles Projekt schließen, bevor das temporäre gelöscht wird
pm.CloseProject(proj)
pm.DeleteProject(proj_name)                           # entspricht dem oben generierten Namen

Umgebungsvariablen (zur Referenz / erneuten Persistierung):

RESOLVE_SCRIPT_API = C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting
RESOLVE_SCRIPT_LIB = C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll

Leistungsrealität auf diesem Rechner

• HEVC-Softwaredecodierung ist der eigentliche Engpass. Jede Transkodierung dieses iPhone-Materials ist unabhängig vom Werkzeug langsam; veryslow dauerte ~5 Minuten für 15s 720p. Jedes Werkzeug zahlt die gleiche Decodierungssteuer – der Unterschied liegt nur in dem, was nach der Decodierung passiert.
• Stream-Copy bevorzugen (~1,2 s) wann immer keine Pixeländerung nötig ist (und HEVC-Ausgabe akzeptabel). Wenn Sie neu codieren müssen und Geschwindigkeit zählt, verwenden Sie FFmpeg ultrafast/veryfast (~7s).
• DaVinci Resolve ist ~15x langsamer als FFmpeg und farbverwaltet die Ausgabe (größere Dateien, Ausgabe unterscheidet sich absichtlich von der Quelle). Nur wert für Grading/Tone-Mapping/Denoising/Stabilisierung/Upscaling/kreatives Finish.
• auto-editor kann 30+ Minuten für einen langen HEVC-Clip benötigen und möglicherweise nichts entfernen – nur auf Talking-Head-/Tutorial-Audio mit tatsächlichen Pausen anwenden.

Empirische Grundlage (dem Routing vertrauen, nicht der zweiten Dezimalstelle)

Aufgabe: Sekunden 10-25 (15s) trimmen, dann HEVC->H.264 720p transkodieren, seriell ausführen für faire CPU-Zeitmessung, VMAF gegenüber der unbearbeiteten Quelle. Material: iPhone HEVC 720p30 (ein repräsentativer Clip aus einem 9-Clip-Set). Zahlen sind Einzelläufe (n=1), keine Wiederholungen – die großen Lücken (das Routing) sind solide; kleine (z. B. MoviePy vs. ffmpeg medium) liegen innerhalb des Rauschens eines Einzellaufs.

Werkzeug / Einstellung	Zeit	Größe	VMAF	Bewertung
FFmpeg Stream-Copy (-c copy, bleibt HEVC)	1,2s	11,0 MB	verlustfrei	Am schnellsten; nur schneiden/verbinden/remuxen, keine Pixeländerung, Ausgabe bleibt HEVC
FFmpeg libx264 ultrafast crf20	7,4s	22,3 MB	99,66	Schnellste echte Transkodierung; Qualität bereits am quellenbegrenzten Maximum
FFmpeg libx264 medium crf20	47,9s	13,3 MB	99,71	Standard-Balance; deckt fast die gesamte Größeneinsparung ab
FFmpeg libx264 veryslow crf20	297s (~5 Min)	12,6 MB	99,78	+0,12 VMAF (unsichtbar), ~0,7 MB über medium – nur wenn größenbeschränkt
MoviePy (x264 medium crf20)	53,5s	13,4 MB	99,44*	~ ffmpeg Geschwindigkeit + Python-Overhead (Lücke im Rauschen); für skriptgesteuerte Kompositionen verwenden
Blender VSE Videoexport	FEHLGESCHLAGEN	—	—	Kein Video-Enum auf 5.1; Frames rendern + ffmpeg muxen
DaVinci Resolve (API, default H264)	109s	48,2 MB	98,40*	~15x langsamer, farbverwaltet; nur korrigierend/kreativ
auto-editor (ganzer 81s Clip)	2021s (~34 Min)	—	—	0s geschnitten: Audio war durchgehend – falsches Werkzeug dafür

* MoviePy- und Resolve-VMAF wurden in einem angepassten No-Trim-Durchgang erneut gemessen, daher nicht perfekt vergleichbar mit den getrimmten ffmpeg-Zeilen. Die 48,2 MB und 98,40 für Resolve stammen aus anderen Durchgängen (die No-Trim-Neuvermessung ergab 15,24 MB): Resolve liest niedriger im Vergleich zur unberührten Quelle, weil es farbverwaltet ist, kein transparenter Durchlauf, und seine größere Datei ist ein Qualitäts-First-Standardbitraten-Artefakt. Ein CQ/größenangepasster Resolve-Render würde beide Vergleiche ändern – der 3,75-fache Größenunterschied ist standardabhängig, nicht inhärent.

Schlussfolgerungen, auf denen das Routing aufbaut: (1) Die einfache Transkodierungsqualität ist nicht differenzierend – jagen Sie ihr nicht hinterher. (2) Die FFmpeg-Preset-Reihe ist ein Geschwindigkeits-gegen-Bitrateneffizienz-Kompromiss, kein Qualitätskompromiss. (3) "Am verfeinertsten" bedeutet nur etwas für korrigierende/kreative Arbeiten; dort ist DaVinci Resolve das richtige Werkzeug (eine branchenübliche Erwartung, hier nicht gemessen) – sonst nirgends.