kaustubhupadhyaya/video-tool-router

Video Tool Router

Choisissez l'outil le moins cher qui satisfait pleinement la tâche. Sur cette machine, la QUALITÉ de transcodage est limitée par la source et non différenciante (tous les outils atteignent VMAF 98.4-99.8), donc ne choisissez jamais un outil « parce qu'il est de meilleure qualité » pour un simple transcodage. Ne choisissez DaVinci Resolve que lorsque la tâche est CORRECTIVE ou CRÉATIVE (étalonnage, mappage tonal, débruitage, stabilisation, upscaling, finition multi-clip) — c'est le seul régime où il est l'outil approprié. Il coûte environ 15x le temps de FFmpeg plus une configuration lourde, et son avantage en matière d'étalonnage/débruitage/stabilisation/upscaling est une attente standard du domaine, PAS ce que le benchmark ci-dessous a mesuré (ce benchmark ne couvre que le simple transcodage).

Arbre de décision (correspond à la PREMIÈRE règle qui s'applique)

1. Aucun changement de pixel — couper / rogner / joindre / concaténer / remuxer / changer de conteneur / extraire l'audio -> FFmpeg stream-copy (-c copy). ~1,2 s, sans perte. Montage réel le plus rapide — toujours le préférer lorsque les pixels ne doivent pas changer. Deux mises en garde : (a) la coupe est précise à la trame clé, pas à la trame — le début s'aligne sur la trame clé la plus proche ; ré-encoder si vous avez besoin d'une limite de trame exacte. (b) la sortie reste dans le codec source (HEVC) — si vous avez besoin d'un livrable H.264, cette règle ne s'applique pas ; passez à la règle 2.

2. Transcoder / mettre à l'échelle / compresser (les pixels changent, sans correction) -> FFmpeg libx264. Par défaut -preset medium -crf 20. Utilisez veryfast/ultrafast quand la vitesse compte — la qualité diffère à peine (ultrafast est toujours à VMAF 99.66). N'utilisez veryslow que lorsque le stockage/la bande passante sont limités — 40x le calcul par rapport à ultrafast pour +0,12 VMAF (invisible) mais réduit presque de moitié le fichier. Même dans ce cas, medium capture déjà presque toute cette réduction (13,3 Mo contre 12,6 Mo pour veryslow), donc veryslow vaut rarement ~6x le temps de medium.

3. Silence / suppression de temps mort sur l'audio d'une tête parlante ou d'un tutoriel -> auto-editor. ATTENTION : très lent sur HEVC (décodage logiciel) et il n'aide QUE si l'audio a réellement des silences. Inutile sur les séquences audio continues (clips de conduite/route/musique) — il tournera pendant ~30+ min et ne coupera rien.

4. Montage programmatique — coupes scriptées + texte/incrustations/transitions en Python -> MoviePy 2.x. Attendez-vous à une vitesse environ égale à celle de FFmpeg plus les frais généraux de Python. À utiliser lorsque la logique de composition est plus facile en code que dans un long filter_complex de ffmpeg.

5. Étalonnage / mappage tonal HLG->SDR / débruitage / stabilisation / upscaling (SuperScale) / finition créative multi-clip -> DaVinci Resolve via l'API Python. Le seul régime où « le faire dans Resolve » est correct. ~15x le temps de FFmpeg, gestion des couleurs (pas une transparence directe). Son avantage qualitatif ici est une norme de domaine, pas un benchmark ci-dessous. Configuration dans sa propre section.

6. Titres 3D / motion-graphics -> Blender headless -> images PNG -> ffmpeg mux. NOTE : L'énumération image_settings.file_format de Blender 5.1 pour le rendu n'a AUCUNE option FFMPEG/vidéo. N'essayez PAS image_settings.file_format='FFMPEG' ou l'export vidéo VSE scripté — c'est cassé sur cette version. Rendez des images fixes, puis muxez-les avec ffmpeg.

7. Montage IA / textuel (éditer par transcription, supprimer les mots de remplissage, « raccourcir ») -> Descript MCP.

Commandes exactes (copiables-collables)

1. Stream-copy (pas de ré-encodage)

# rogner : -t est la DURÉE (sans ambiguïté). La coupe est précise à la trame clé, la sortie reste en HEVC.
ffmpeg -ss 10 -i in.mov -t 15 -c copy out.mov
# concat (list.txt lignes : file 'clip1.mov')
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mov
# remuxer le conteneur / extraire l'audio (pas de ré-encodage)
ffmpeg -i in.mov -c copy out.mp4
ffmpeg -i in.mov -vn -c:a copy out.m4a

(Utilisez -t <secondes> pour la durée. Évitez -ss ... -to ... avec -c copy : le point de référence de -to est ambigu avec la recherche côté entrée et peut produire la mauvaise durée. Pour une limite de trame exacte, supprimez -c copy et ré-encodez — cela réintroduit le coût du décodage HEVC.)

2. Transcoder HEVC -> H.264

# équilibre par défaut
ffmpeg -i in.mov -c:v libx264 -preset medium -crf 20 -c:a aac -b:a 192k out.mp4
# vitesse d'abord (la qualité diffère à peine)
ffmpeg -i in.mov -c:v libx264 -preset veryfast -crf 20 -c:a aac -b:a 192k out.mp4
# mise à l'échelle en 720p pendant le transcodage
ffmpeg -i in.mov -vf scale=-2:720 -c:v libx264 -preset medium -crf 20 -c:a aac out.mp4

3. Suppression de silence

auto-editor in.mp4 --edit audio:threshold=4% -o out.mp4
# vérifiez d'abord la coupe si vous n'êtes pas sûr que l'audio ait même des silences :
auto-editor in.mp4 --edit audio:threshold=4% --preview

4. MoviePy 2.x (API renommée : subclipped / with_position / with_duration)

from moviepy import VideoFileClip, TextClip, CompositeVideoClip
clip = VideoFileClip("in.mov").subclipped(10, 25)
# NOTE : MoviePy 2.x TextClip a besoin d'un CHEMIN DE FICHIER de police, pas d'un nom de famille comme "Arial".
txt = (TextClip(text="Hello", 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 -> images -> mux

# rendu de l'animation en images PNG (NE PAS définir file_format='FFMPEG' sur la version 5.1)
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# mux des images en H.264 (faites correspondre -framerate aux fps de la scène)
ffmpeg -framerate 30 -i frames/f_%04d.png -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p out.mp4

Protection HLG (EXÉCUTEZ CECI AVANT TOUT EXPORT SDR H.264)

Certaines séquences iPhone sont du HLG 10 bits. Un export libx264 naïf vers SDR grisaille / lave les couleurs à moins d'être mappé tonalement.

# 1. sonder la caractéristique de transfert
ffprobe -v error -select_streams v:0 -show_entries stream=color_transfer -of default=nk=1:nw=1 in.mov

• Sortie arib-std-b67 (HLG) ou smpte2084 (PQ) -> la séquence est HDR : mappez tonalement avant/pendant l'encodage.
• Autre chose (bt709, inconnu) -> déjà SDR : utilisez la commande de transcodage normale.

# 2. Mappage tonal HLG/PQ -> SDR BT.709 + H.264 en un seul passage (et taguez la sortie bt709)
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 est la luminance crête nominale utilisée pour la linéarisation ; augmentez-la si les hautes lumières brillantes sont écrasées. Alternative : laissez la gestion des couleurs de DaVinci Resolve faire la conversion Rec.2020-HLG -> Rec.709 (acheminez vers Resolve si vous étalonnez de toute façon — il le fait plus précisément que le mappeur tonal ffmpeg).

Configuration de l'API Python de DaVinci Resolve (le chemin correctif/créatif)

PIÈGES intégrés ci-dessous : doit s'exécuter sur Python 3.11 (py -3.11) — le 3.14 par défaut ne parvient pas à initialiser fusionscript.dll. RESOLVE_SCRIPT_API / RESOLVE_SCRIPT_LIB sont des variables d'environnement persistées. Resolve doit être en cours d'exécution (ou lancez-le -nogui). Utilisez un projet temporaire jetable, définissez le format+codec explicitement, puis effectuez le rendu et interrogez.

# Exécutez avec :  py -3.11 resolve_render.py
import os, sys, time
sys.path.append(os.path.join(os.environ["RESOLVE_SCRIPT_API"], "Modules"))  # en-tête requis
import DaVinciResolveScript as dvr

resolve = dvr.scriptapp("Resolve")          # Resolve doit déjà être en cours d'exécution (ou démarrez -nogui d'abord)
pm      = resolve.GetProjectManager()

proj_name = "temp_render_" + str(int(time.time()))   # gardez le nom pour que le nettoyage puisse le faire correspondre
proj    = pm.CreateProject(proj_name)
pool    = proj.GetMediaPool()
items   = resolve.GetMediaStorage().AddItemListToMediaPool([r"C:\in\clip.mov"])
tl      = pool.CreateTimelineFromClips("temp_timeline", items)   # le définit également comme courant

# ---- appliquez le raffinement qui a justifié Resolve ici ----
# (étalonnage / gestion des couleurs du projet pour HLG->SDR / upscale SuperScale / débruitage / stabilisation)

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

while proj.IsRenderingInProgress():                   # boucle de rendu + attente
    time.sleep(1)
print("rendu :", proj.GetRenderJobStatus(pid))

# nettoyage : fermez le projet courant avant de supprimer le projet temporaire
pm.CloseProject(proj)
pm.DeleteProject(proj_name)                           # correspond au nom que nous avons généré ci-dessus

Variables d'environnement (pour référence / repersistance) :

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

Réalité des performances sur cette machine

• Le décodage logiciel HEVC est le véritable goulot d'étranglement. Chaque transcodage de cette séquence iPhone est lent quel que soit l'outil ; veryslow a pris ~5 min pour 15 s de 720p. Chaque outil paie la même taxe de décodage — le différenciateur est seulement ce qui se passe après le décodage.
• Préférez stream-copy (~1,2 s) à chaque fois qu'aucun changement de pixel n'est nécessaire (et que la sortie HEVC est acceptable). Si vous devez ré-encoder et que la vitesse compte, utilisez FFmpeg ultrafast/veryfast (~7 s).
• DaVinci Resolve est ~15x plus lent que FFmpeg et gère les couleurs en sortie (fichiers plus volumineux, sortie intentionnellement différente de la source). Ne vaut le coup que pour l'étalonnage/le mappage tonal/le débruitage/la stabilisation/l'upscaling/la finition créative.
• auto-editor peut prendre 30+ min sur un long clip HEVC et peut ne rien supprimer — ne l'exécutez que sur des têtes parlantes / des didacticiels audio qui ont réellement des pauses.

Base empirique (fiez-vous au routage, pas à la deuxième décimale)

Tâche : rogner les secondes 10-25 (15 s) puis transcoder HEVC->H.264 720p, exécuter en série pour un timing CPU équitable, VMAF par rapport à la source non modifiée. Séquence : iPhone HEVC 720p30 (un clip représentatif d'un ensemble de 9 clips). Les chiffres sont des exécutions uniques (n=1), sans répétitions — les grands écarts (le routage) sont solides ; les petits (par exemple MoviePy vs ffmpeg medium) sont dans le bruit d'une seule exécution.

Outil / réglage	Temps	Taille	VMAF	Verdict
FFmpeg stream-copy (-c copy, reste HEVC)	1,2 s	11,0 Mo	sans perte	Le plus rapide ; coupe/join/remux uniquement, pas de changement de pixel, sortie reste HEVC
FFmpeg libx264 ultrafast crf20	7,4 s	22,3 Mo	99,66	Transcodage réel le plus rapide ; la qualité est déjà au plafond limité par la source
FFmpeg libx264 medium crf20	47,9 s	13,3 Mo	99,71	Équilibre par défaut ; capture presque tout le gain de taille
FFmpeg libx264 veryslow crf20	297 s (~5 min)	12,6 Mo	99,78	+0,12 VMAF (invisible), ~0,7 Mo de plus que medium — seulement si limité par la taille
MoviePy (x264 medium crf20)	53,5 s	13,4 Mo	99,44*	~ vitesse ffmpeg + frais généraux Python (écart dans le bruit) ; à utiliser pour les compositions scriptées
Export vidéo Blender VSE	ÉCHEC	—	—	Pas d'énumération vidéo sur 5.1 ; rendu d'images + ffmpeg mux
DaVinci Resolve (API, H264 par défaut)	109 s	48,2 Mo	98,40*	~15x plus lent, gestion des couleurs ; correctif/créatif uniquement
auto-editor (clip complet de 81 s)	2021 s (~34 min)	—	—	A coupé 0 s : l'audio était continu — mauvais outil pour cela

* Les VMAF de MoviePy et Resolve ont été remesurées sur un passage sans rognage correspondant, donc elles ne sont pas parfaitement comparables avec les lignes ffmpeg rognées. Les 48,2 Mo et 98,40 pour Resolve proviennent de passages différents (la remesure sans rognage a produit 15,24 Mo) : Resolve lit inférieur par rapport à la source non touchée car il gère les couleurs, pas une transparence directe, et son fichier plus volumineux est un artefact de débit par défaut priorisant la qualité. Un rendu Resolve à taille/CQ adaptée changerait les deux comparaisons — le facteur 3,75x de taille dépend des valeurs par défaut, pas intrinsèque.

Enseignements sur lesquels le routage est construit : (1) La qualité du simple transcodage n'est pas différenciante — ne la cherchez pas. (2) La balayage des préréglages FFmpeg est un compromis vitesse vs efficacité du débit binaire, pas un compromis de qualité. (3) « Le plus raffiné » n'a de sens que pour le travail correctif/créatif ; là, DaVinci Resolve est l'outil approprié (une attente standard du domaine, non mesurée ici) — nulle part ailleurs.