kaustubhupadhyaya/roteador-de-ferramentas-de-video

Roteador de Ferramentas de Vídeo

Escolha a ferramenta mais barata que satisfaz completamente a tarefa. Nesta máquina, a QUALIDADE da transcodificação é limitada pela fonte e não é um diferencial (todas as ferramentas atingem VMAF 98,4-99,8), então nunca escolha uma ferramenta "porque tem qualidade superior" para uma transcodificação simples. Escolha o DaVinci Resolve apenas quando a tarefa for CORRETIVA ou CRIATIVA (correção de cor, mapeamento de tom, desruído, estabilizar, upscale, finalização de múltiplos clipes) — esse é o único regime onde ele é a ferramenta certa. Ele custa ~15x o tempo do FFmpeg mais uma configuração mais pesada, e sua vantagem em correção de cor/desruído/estabilizar/upscale é uma expectativa padrão do domínio, NÃO algo que o benchmark abaixo mediu (esse benchmark cobre apenas transcodificação simples).

Árvore de decisão (corresponda à PRIMEIRA regra que se encaixa)

1. Nenhuma alteração de pixel — corte / aparar / unir / concatenar / remuxificar / troca de contêiner / extrair áudio -> FFmpeg stream-copy (-c copy). ~1,2s, sem perdas. A edição real mais rápida — sempre preferir quando os pixels não precisam mudar. Duas ressalvas: (a) o corte é preciso no keyframe, não preciso no quadro — o início se encaixa no keyframe mais próximo; recodifique se precisar de um limite de quadro exato. (b) a saída permanece no codec de origem (HEVC) — se precisar de um entregável H.264, esta regra não se aplica; vá para a regra 2.

2. Transcodificar / redimensionar / comprimir (os pixels mudam, sem correção) -> FFmpeg libx264. Padrão -preset medium -crf 20. Use veryfast/ultrafast quando a velocidade importar — a qualidade mal difere (ultrafast ainda tem VMAF 99,66). Recorra a veryslow apenas quando o armazenamento/largura de banda for o gargalo — 40x o processamento sobre ultrafast compra +0,12 VMAF (invisível) mas quase reduz o arquivo pela metade. Mesmo assim, medium já captura quase toda essa redução (13,3 MB vs 12,6 MB do veryslow), então veryslow raramente vale ~6x o tempo do medium.

3. Remoção de silêncio / áudio morto em áudio de cabeça falante ou tutorial -> auto-editor. AVISO: muito lento em HEVC (decodificação por software) e só ajuda se o áudio realmente tiver lacunas. Inútil em gravações de áudio contínuo (clipes de passeio/estrada/música) — ele vai processar por ~30+ min e cortar 0 segundos.

4. Montagem programática — cortes com script + texto/sobreposições/transições em Python -> MoviePy 2.x. Espere aproximadamente velocidade do ffmpeg mais sobrecarga do Python. Use quando a lógica de composição for mais fácil em código do que em um longo filter_complex do ffmpeg.

5. Correção de cor / mapeamento de tom HLG->SDR / desruído / estabilizar / upscale (SuperScale) / finalização criativa de múltiplos clipes -> DaVinci Resolve via API Python. O único regime onde "fazer no Resolve" está correto. ~15x o tempo do FFmpeg, gerenciado por cor (não é uma passagem transparente). Sua vantagem de qualidade aqui é padrão do domínio, não medida abaixo. Configuração em sua própria seção.

6. Títulos 3D / gráficos em movimento -> Blender headless -> quadros PNG -> ffmpeg mux. NOTA: O enum image_settings.file_format do render do Blender 5.1 NÃO tem opção FFMPEG/vídeo. NÃO tente image_settings.file_format='FFMPEG' ou exportação de vídeo VSE com script — está quebrado nesta compilação. Renderize quadros de imagem e depois multiplex com ffmpeg.

7. Edição baseada em IA / texto (editar por transcrição, remover palavras de preenchimento, "tornar mais curto") -> Descript MCP.

Comandos exatos (copiáveis)

1. Stream-copy (sem recodificar)

# aparar: -t é DURAÇÃO (inequívoco). Corte é preciso no keyframe, a saída permanece HEVC.
ffmpeg -ss 10 -i in.mov -t 15 -c copy out.mov
# concatenar (list.txt linhas: file 'clip1.mov')
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mov
# remuxificar contêiner / extrair áudio (sem recodificar)
ffmpeg -i in.mov -c copy out.mp4
ffmpeg -i in.mov -vn -c:a copy out.m4a

(Use -t <segundos> para duração. Evite -ss ... -to ... com -c copy: o ponto de referência de -to é ambíguo com busca no lado de entrada e pode produzir a duração errada. Para um limite de quadro exato, remova -c copy e recodifique — isso reintroduz o custo de decodificação HEVC.)

2. Transcodificar HEVC -> H.264

# equilíbrio padrão
ffmpeg -i in.mov -c:v libx264 -preset medium -crf 20 -c:a aac -b:a 192k out.mp4
# priorizando velocidade (qualidade mal difere)
ffmpeg -i in.mov -c:v libx264 -preset veryfast -crf 20 -c:a aac -b:a 192k out.mp4
# redimensionar para 720p enquanto transcodifica
ffmpeg -i in.mov -vf scale=-2:720 -c:v libx264 -preset medium -crf 20 -c:a aac out.mp4

3. Remoção de silêncio

auto-editor in.mp4 --edit audio:threshold=4% -o out.mp4
# verifique o corte primeiro se não tiver certeza se o áudio tem lacunas:
auto-editor in.mp4 --edit audio:threshold=4% --preview

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

from moviepy import VideoFileClip, TextClip, CompositeVideoClip
clip = VideoFileClip("in.mov").subclipped(10, 25)
# NOTA: O MoviePy 2.x TextClip precisa de um CAMINHO DE ARQUIVO de fonte, não de um nome de família como "Arial".
txt = (TextClip(text="Olá", 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/gráficos em movimento -> quadros -> mux

# renderizar animação para quadros PNG (NÃO defina file_format='FFMPEG' no 5.1)
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# multiplexar quadros para H.264 (corresponda -framerate ao fps da cena)
ffmpeg -framerate 30 -i frames/f_%04d.png -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p out.mp4

Guarda HLG (EXECUTE ANTES DE QUALQUER EXPORTAÇÃO SDR H.264)

Algumas gravações de iPhone são HLG de 10 bits. Uma exportação libx264 ingênua para SDR desbota / lava a cor a menos que seja mapeada por tom.

# 1. investigue a característica de transferência
ffprobe -v error -select_streams v:0 -show_entries stream=color_transfer -of default=nk=1:nw=1 in.mov

• Saída arib-std-b67 (HLG) ou smpte2084 (PQ) -> a gravação é HDR: mapeie o tom antes/durante a codificação.
• Qualquer outra coisa (bt709, desconhecido) -> já é SDR: use o comando de transcodificação normal.

# 2. Mapeamento de tom HLG/PQ -> SDR BT.709 + H.264 em uma passagem (e marque a saída como 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 é a luminância de pico nominal usada para linearização; aumente se realces brilhantes recortarem. Alternativa: deixe o gerenciamento de cores do DaVinci Resolve fazer a conversão Rec.2020-HLG -> Rec.709 (roteie para Resolve se estiver corrigindo de qualquer forma — ele faz isso com mais precisão do que o mapeamento de tom do ffmpeg).

Configuração da API Python do DaVinci Resolve (caminho corretivo/criativo)

ARMADILHAS incorporadas abaixo: deve ser executado no Python 3.11 (py -3.11) — o 3.14 padrão falha ao iniciar fusionscript.dll. RESOLVE_SCRIPT_API / RESOLVE_SCRIPT_LIB são variáveis de ambiente persistentes. O Resolve deve estar em execução (ou iniciar -nogui). Use um projeto temporário descartável, defina formato+codec explicitamente, depois renderize e consulte.

# Execute com:  py -3.11 resolve_render.py
import os, sys, time
sys.path.append(os.path.join(os.environ["RESOLVE_SCRIPT_API"], "Modules"))  # cabeçalho obrigatório
import DaVinciResolveScript as dvr

resolve = dvr.scriptapp("Resolve")          # O Resolve já deve estar em execução (ou iniciar -nogui primeiro)
pm      = resolve.GetProjectManager()

proj_name = "temp_render_" + str(int(time.time()))   # mantenha o nome para que a limpeza possa corresponder a ele
proj    = pm.CreateProject(proj_name)
pool    = proj.GetMediaPool()
itens   = resolve.GetMediaStorage().AddItemListToMediaPool([r"C:\in\clip.mov"])
tl      = pool.CreateTimelineFromClips("timeline_temp", itens)   # também a define como atual

# ---- aplique o refinamento que justificou o Resolve aqui ----
# (correção de cor / gerenciamento de cores do projeto para HLG->SDR / upscale SuperScale / desruído / estabilizar)

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

while proj.IsRenderingInProgress():                   # loop de renderização + espera
    time.sleep(1)
print("render:", proj.GetRenderJobStatus(pid))

# limpeza: feche o projeto atual antes de excluir o temporário
pm.CloseProject(proj)
pm.DeleteProject(proj_name)                           # corresponde ao nome que geramos acima

Variáveis de ambiente (para referência / persistir novamente):

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

Realidade de desempenho nesta máquina

• A decodificação de software HEVC é o verdadeiro gargalo. Toda transcodificação dessa gravação de iPhone é lenta, independentemente da ferramenta; veryslow levou ~5 min para 15s de 720p. Toda ferramenta paga o mesmo imposto de decodificação — o diferencial é apenas o que acontece após a decodificação.
• Prefira stream-copy (~1,2s) sempre que nenhuma alteração de pixel for necessária (e a saída HEVC for aceitável). Se precisar recodificar e a velocidade for importante, use o FFmpeg ultrafast/veryfast (~7s).
• DaVinci Resolve é ~15x mais lento que o FFmpeg e gerencia a saída em termos de cor (arquivos maiores, saída intencionalmente diferente da fonte). Vale a pena apenas para correção de cor/mapeamento de tom/desruído/estabilizar/upscale/finalização criativa.
• O auto-editor pode levar 30+ min em um clipe HEVC longo e pode não remover nada — execute-o apenas em áudio de cabeça falante / tutorial que realmente tenha pausas.

Base empírica (confie no roteamento, não na segunda casa decimal)

Tarefa: aparar segundos 10-25 (15s) e depois transcodificar HEVC->H.264 720p, executar em série para tempo de CPU justo, VMAF vs a fonte intocada. Gravação: iPhone HEVC 720p30 (um clipe representativo de um conjunto de 9 clipes). Números são execuções únicas (n=1), sem repetições — as grandes lacunas (o roteamento) são sólidas; as pequenas (por exemplo, MoviePy vs ffmpeg medium) estão dentro do ruído de execução única.

Ferramenta / configuração	Tempo	Tamanho	VMAF	Veredicto
FFmpeg stream-copy (-c copy, permanece HEVC)	1,2s	11,0 MB	sem perdas	Mais rápido; apenas corte/junção/remux, sem alteração de pixel, saída permanece HEVC
FFmpeg libx264 ultrafast crf20	7,4s	22,3 MB	99,66	Transcodificação real mais rápida; qualidade já no teto limitado pela fonte
FFmpeg libx264 medium crf20	47,9s	13,3 MB	99,71	Equilíbrio padrão; captura quase todo o benefício de tamanho
FFmpeg libx264 veryslow crf20	297s (~5 min)	12,6 MB	99,78	+0,12 VMAF (invisível), ~0,7 MB sobre medium — apenas se limitado por tamanho
MoviePy (x264 medium crf20)	53,5s	13,4 MB	99,44*	~ velocidade ffmpeg + sobrecarga Python (lacuna dentro do ruído); use para composições com script
Exportação de vídeo Blender VSE	FALHOU	—	—	Sem enum de vídeo no 5.1; renderize quadros + ffmpeg mux
DaVinci Resolve (API, H264 padrão)	109s	48,2 MB	98,40*	~15x mais lento, gerenciado por cor; apenas corretivo/criativo
auto-editor (clipe completo de 81s)	2021s (~34 min)	—	—	Cortou 0s: o áudio era contínuo — ferramenta errada para isso

* VMAF do MoviePy e Resolve foram remensurados em uma passagem sem corte correspondente, portanto não são perfeitamente comparáveis com as linhas de ffmpeg com corte. Os 48,2 MB e 98,40 do Resolve vêm de passagens diferentes (a remensuração sem corte produziu 15,24 MB): Resolve lê mais baixo em relação à fonte intocada porque é gerenciado por cor, não é uma passagem transparente, e seu arquivo maior é um artefato de taxa de bits padrão de prioridade de qualidade. Uma renderização Resolve com tamanho correspondente/CQ mudaria ambas as comparações — o tamanho 3,75x maior depende do padrão, não é intrínseco.

Conclusões nas quais o roteamento é construído: (1) A qualidade da transcodificação simples é não-diferenciadora — não a persiga. (2) A varredura de presets do FFmpeg é uma troca de velocidade vs eficiência de taxa de bits, não uma troca de qualidade. (3) "Mais refinado" só significa algo para trabalho corretivo/criativo; lá o DaVinci Resolve é a ferramenta certa (uma expectativa padrão do domínio, não medida aqui) — em nenhum outro lugar.