비디오 도구 라우터
작업을 완전히 충족하는 가장 저렴한 도구를 선택하세요. 이 시스템에서 트랜스코딩 QUALITY는 소스에 의해 제한되며 차별화되지 않습니다(모든 도구가 VMAF 98.4-99.8 사이). 따라서 일반 트랜스코딩에 "품질이 더 높다"는 이유로 도구를 선택하지 마십시오. DaVinci Resolve는 작업이 교정(CORRECTIVE) 또는 크리에이티브(CREATIVE)(그레이딩, 톤매핑, 노이즈 제거, 안정화, 업스케일, 다중 클립 마무리)인 경우에만 선택하세요. 이것이 바로 이 도구가 적합한 유일한 영역입니다. 이 도구는 FFmpeg보다 약 15배의 시간과 더 무거운 설정이 필요하며, 그레이딩/노이즈 제거/안정화/업스케일에서의 장점은 업계 표준 기대치이며, 아래 벤치마크에서 측정된 것이 아닙니다(해당 벤치마크는 일반 트랜스코딩만 다룹니다).
결정 트리 (일치하는 첫 번째 규칙 적용)
-
픽셀 변경 없음 — 자르기 / 트림 / 결합 / 연결 / 리먹싱 / 컨테이너 변경 / 오디오 추출 -> FFmpeg stream-copy (
-c copy). ~1.2초, 무손실. 픽셀을 변경할 필요가 없을 때 가장 빠른 실제 편집 — 항상 선호하세요. 두 가지 주의사항: (a) 자르기는 키프레임 정확도이며 프레임 정확도가 아닙니다. 시작점이 가장 가까운 키프레임으로 스냅됩니다. 정확한 프레임 경계가 필요하면 다시 인코딩하세요. (b) 출력은 소스 코덱(HEVC)으로 유지됩니다. H.264 출력물이 필요한 경우 이 규칙이 적용되지 않습니다. 규칙 2로 이동하세요. -
트랜스코딩 / 스케일 / 압축 (픽셀 변경, 교정 없음) -> FFmpeg libx264. 기본값
-preset medium -crf 20. 속도가 중요할 때veryfast/ultrafast를 사용하세요 — 품질은 거의 차이가 없습니다(ultrafast도 여전히 VMAF 99.66).veryslow는 스토리지/대역폭이 제한된 경우에만 사용하세요 — ultrafast보다 40배의 계산량으로 +0.12 VMAF(눈에 보이지 않음)을 얻지만 파일 크기는 거의 절반으로 줄입니다. 그렇더라도medium은 이미 거의 모든 크기 감소를 포착하므로(13.3 MB vs veryslow의 12.6 MB),veryslow는 medium보다 약 6배의 시간을 들일 가치가 거의 없습니다. -
말하는 사람 또는 튜토리얼 오디오의 무음 / 데드에어 제거 -> auto-editor. 경고: HEVC에서 매우 느리며(소프트웨어 디코딩) 오디오에 실제로 공백이 있는 경우에만 도움이 됩니다. 연속 오디오 푸티지(주행/도로/음악 클립)에는 쓸모가 없습니다. 약 30분 이상 실행되고 0초를 자를 수 있습니다.
-
프로그래매틱 어셈블리 — Python에서 스크립팅된 컷 + 텍스트/오버레이/전환 -> MoviePy 2.x. 대략 ffmpeg 속도에 Python 오버헤드를 더한 속도를 예상하세요. 구성 로직이 긴 ffmpeg
filter_complex보다 코드에서 더 쉬울 때 사용하세요. -
컬러 그레이딩 / HLG->SDR 톤매핑 / 노이즈 제거 / 안정화 / 업스케일(SuperScale) / 다중 클립 크리에이티브 마무리 -> Python API를 통한 DaVinci Resolve. "Resolve에서 수행"이 올바른 유일한 영역입니다. FFmpeg 시간의 약 15배, 색상 관리(투명한 패스스루가 아님). 여기서의 품질 우위는 업계 표준이며 아래에 벤치마킹되지 않았습니다. 설정은 자체 섹션에 있습니다.
-
3D 타이틀 / 모션 그래픽 -> Blender 헤드리스 -> PNG 프레임 -> ffmpeg 먹싱. 참고: Blender 5.1의 렌더
image_settings.file_format열거형에는FFMPEG/비디오 옵션이 없습니다.image_settings.file_format='FFMPEG'또는 스크립팅된 VSE 비디오 내보내기를 시도하지 마세요 — 이 빌드에서는 작동하지 않습니다. 이미지 프레임을 렌더링한 다음 ffmpeg로 먹싱하세요. -
AI / 텍스트 기반 편집 (대본으로 편집, 불용어 제거, "짧게 만들기") -> Descript MCP.
정확한 명령어 (복사-붙여넣기 가능)
1. Stream-copy (재인코딩 없음)
# 트림: -t는 DURATION입니다(명확함). 자르기는 키프레임 정확도이며 출력은 HEVC로 유지됩니다.
ffmpeg -ss 10 -i in.mov -t 15 -c copy out.mov
# 연결 (list.txt 라인: file 'clip1.mov')
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mov
# 컨테이너 리먹싱 / 오디오 추출 (재인코딩 없음)
ffmpeg -i in.mov -c copy out.mp4
ffmpeg -i in.mov -vn -c:a copy out.m4a
(지속 시간에는 -t <초>를 사용하세요. -c copy와 함께 -ss ... -to ...를 사용하지 마세요: -to의 참조 지점은 입력측 탐색과 모호하여 잘못된 길이를 생성할 수 있습니다. 정확한 프레임 경계가 필요하면 -c copy를 생략하고 다시 인코딩하세요. 그러면 HEVC 디코딩 비용이 다시 발생합니다.)
2. HEVC -> H.264 트랜스코딩
# 기본 균형
ffmpeg -i in.mov -c:v libx264 -preset medium -crf 20 -c:a aac -b:a 192k out.mp4
# 속도 우선 (품질 거의 차이 없음)
ffmpeg -i in.mov -c:v libx264 -preset veryfast -crf 20 -c:a aac -b:a 192k out.mp4
# 트랜스코딩하면서 720p로 크기 조정
ffmpeg -i in.mov -vf scale=-2:720 -c:v libx264 -preset medium -crf 20 -c:a aac out.mp4
3. 무음 제거
auto-editor in.mp4 --edit audio:threshold=4% -o out.mp4
# 오디오에 실제로 공백이 있는지 확실하지 않은 경우 먼저 컷 확인:
auto-editor in.mp4 --edit audio:threshold=4% --preview
4. MoviePy 2.x (API 이름 변경: subclipped / with_position / with_duration)
from moviepy import VideoFileClip, TextClip, CompositeVideoClip
clip = VideoFileClip("in.mov").subclipped(10, 25)
# 참고: MoviePy 2.x TextClip은 "Arial"과 같은 패밀리 이름이 아닌 글꼴 FILE PATH가 필요합니다.
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/모션 그래픽 -> 프레임 -> 먹싱
# 애니메이션을 PNG 프레임으로 렌더링 (5.1에서는 file_format='FFMPEG'로 설정하지 마세요)
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# 프레임을 H.264로 먹싱 (-framerate를 장면 fps와 일치시키세요)
ffmpeg -framerate 30 -i frames/f_%04d.png -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p out.mp4
HLG 가드 (SDR H.264 내보내기 전에 이 작업을 실행하세요)
일부 iPhone 푸티지는 10비트 HLG입니다. 순진한 libx264 SDR 내보내기는 톤매핑되지 않으면 색상이 회색으로 바래거나 / 씻겨 나갑니다.
# 1. 전송 특성 검사
ffprobe -v error -select_streams v:0 -show_entries stream=color_transfer -of default=nk=1:nw=1 in.mov
- 출력
arib-std-b67(HLG) 또는smpte2084(PQ) -> 푸티지가 HDR입니다: 인코딩 전/중에 톤매핑하세요. - 다른 것(
bt709, 알 수 없음) -> 이미 SDR입니다: 일반 트랜스코딩 명령어를 사용하세요.
# 2. HLG/PQ -> SDR BT.709 톤매핑 + H.264를 한 번에 (출력을 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은 선형화에 사용되는 공칭 피크 휘도입니다. 밝은 하이라이트가 클리핑되면 값을 높이세요. 대안: DaVinci Resolve의 색상 관리가 Rec.2020-HLG -> Rec.709 변환을 수행하도록 하세요(어차피 그레이딩 중이라면 Resolve로 라우팅하세요 — ffmpeg 톤맵보다 더 정확하게 수행합니다).
DaVinci Resolve Python API 설정 (교정/크리에이티브 경로)
아래에 내장된 주의사항: 반드시 Python 3.11에서 실행해야 합니다(py -3.11) — 기본 3.14는 fusionscript.dll을 초기화하지 못합니다. RESOLVE_SCRIPT_API / RESOLVE_SCRIPT_LIB은 유지되는 환경 변수입니다. Resolve가 실행 중이어야 합니다(또는 -nogui로 실행). 임시 프로젝트를 사용하고, 포맷+코덱을 명시적으로 설정한 다음 렌더링하고 폴링하세요.
# 다음으로 실행: py -3.11 resolve_render.py
import os, sys, time
sys.path.append(os.path.join(os.environ["RESOLVE_SCRIPT_API"], "Modules")) # 필수 헤더
import DaVinciResolveScript as dvr
resolve = dvr.scriptapp("Resolve") # Resolve가 이미 실행 중이어야 함 (또는 먼저 -nogui로 시작)
pm = resolve.GetProjectManager()
proj_name = "temp_render_" + str(int(time.time())) # 정리 시 일치시킬 수 있도록 이름 유지
proj = pm.CreateProject(proj_name)
pool = proj.GetMediaPool()
items = resolve.GetMediaStorage().AddItemListToMediaPool([r"C:\in\clip.mov"])
tl = pool.CreateTimelineFromClips("temp_timeline", items) # 또한 현재 타임라인으로 설정
# ---- 여기서 Resolve를 정당화한 리파인먼트 적용 ----
# (HLG->SDR용 컬러 그레이드 / 프로젝트 색상 관리 / SuperScale 업스케일 / 노이즈 제거 / 안정화)
proj.SetCurrentRenderFormatAndCodec("mp4", "H264") # 명시적 포맷 + 코덱
proj.SetRenderSettings({
"TargetDir": r"C:\out",
"CustomName": "out",
"SelectAllFrames": True,
})
pid = proj.AddRenderJob()
proj.StartRendering(pid)
while proj.IsRenderingInProgress(): # 렌더링 + 대기 루프
time.sleep(1)
print("render:", proj.GetRenderJobStatus(pid))
# 정리: 임시 프로젝트를 삭제하기 전에 현재 프로젝트 닫기
pm.CloseProject(proj)
pm.DeleteProject(proj_name) # 위에서 생성한 이름과 일치
환경 변수 (참조/재유지용):
RESOLVE_SCRIPT_API = C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting
RESOLVE_SCRIPT_LIB = C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll
이 시스템의 성능 현실
- HEVC 소프트웨어 디코딩이 진정한 병목 현상입니다. 이 iPhone 푸티지의 모든 트랜스코딩은 도구에 관계없이 느립니다.
veryslow는 720p 15초에 약 5분이 걸렸습니다. 모든 도구가 동일한 디코딩 비용을 지불합니다. 차별화 요소는 디코딩 후에만 발생합니다. - 픽셀 변경이 필요하지 않을 때마다(그리고 HEVC 출력이 허용되는 경우) stream-copy(~1.2초)를 선호하세요. 다시 인코딩해야 하고 속도가 중요하다면 FFmpeg
ultrafast/veryfast(~7초)를 사용하세요. - DaVinci Resolve는 FFmpeg보다 약 15배 느리며 색상 관리 출력(더 큰 파일, 출력이 의도적으로 소스와 다름)을 생성합니다. 그레이드/톤매핑/노이즈 제거/안정화/업스케일/크리에이티브 마무리에만 가치가 있습니다.
- auto-editor는 긴 HEVC 클립에서 30분 이상 걸릴 수 있으며 아무것도 제거하지 않을 수 있습니다. 실제로 일시 정지가 있는 말하는 사람/튜토리얼 오디오에서만 실행하세요.
경험적 근거 (라우팅을 신뢰하되, 소수점 둘째 자리는 신뢰하지 마세요)
작업: 10-25초(15초) 트림 후 HEVC->H.264 720p 트랜스코딩, 공정한 CPU 타이밍을 위해 직렬 실행, 변경되지 않은 소스 대비 VMAF. 푸티지: iPhone HEVC 720p30(9개 클립 세트에서 대표 클립 하나). 숫자는 단일 실행(n=1)이며 반복되지 않습니다 — 큰 차이(라우팅)는 확실합니다. 작은 차이(예: MoviePy vs ffmpeg medium)는 단일 실행 노이즈 범위 내입니다.
| 도구 / 설정 | 시간 | 크기 | VMAF | 평결 |
|---|---|---|---|---|
FFmpeg stream-copy (-c copy, HEVC 유지) | 1.2초 | 11.0 MB | 무손실 | 가장 빠름; 컷/결합/리먹싱만, 픽셀 변경 없음, 출력은 HEVC 유지 |
| FFmpeg libx264 ultrafast crf20 | 7.4초 | 22.3 MB | 99.66 | 가장 빠른 실제 트랜스코딩; 품질은 이미 소스 제한 상한선 |
| FFmpeg libx264 medium crf20 | 47.9초 | 13.3 MB | 99.71 | 기본 균형; 거의 모든 크기 이점 포착 |
| FFmpeg libx264 veryslow crf20 | 297초 (~5분) | 12.6 MB | 99.78 | +0.12 VMAF(보이지 않음), medium보다 ~0.7 MB — 크기가 제한된 경우에만 |
| MoviePy (x264 medium crf20) | 53.5초 | 13.4 MB | 99.44* | ~ ffmpeg 속도 + Python 오버헤드(차이는 노이즈 범위 내); 스크립팅된 컴포지션에 사용 |
| Blender VSE 비디오 내보내기 | 실패 | — | — | 5.1에 비디오 열거형 없음; 프레임 렌더링 + ffmpeg 먹싱 |
| DaVinci Resolve (API, 기본 H264) | 109초 | 48.2 MB | 98.40* | ~15배 느림, 색상 관리; 교정/크리에이티브 전용 |
| auto-editor (전체 81초 클립) | 2021초 (~34분) | — | — | 0초 컷: 오디오가 연속적이었음 — 잘못된 도구 |
* MoviePy 및 Resolve VMAF는 일치하는 트림 없음 패스에서 다시 측정되었으므로 트림된 ffmpeg 행과 완전히 동등하지 않습니다. Resolve의 48.2 MB 및 98.40은 다른 패스(트림 없음 재측정에서 15.24 MB 생성)에서 비롯됩니다. Resolve는 색상 관리(투명한 패스스루가 아님)로 인해 변경되지 않은 소스에 비해 더 낮게 읽히며, 더 큰 파일은 품질 우선 기본 비트레이트 아티팩트입니다. CQ/크기 일치 Resolve 렌더링은 두 비교를 모두 변경합니다. 3.75배 크기는 기본값에 의존적이며 본질적이지 않습니다.
라우팅이 구축된 핵심 사항: (1) 일반 트랜스코딩 품질은 차별화되지 않습니다 — 이를 쫓지 마세요. (2) FFmpeg 프리셋 스윕은 속도 대 비트레이트 효율성 간의 트레이드오프이며 품질 트레이드오프가 아닙니다. (3) "가장 정교함"은 교정/크리에이티브 작업에만 의미가 있습니다. 그곳에서 DaVinci Resolve는 올바른 도구입니다(여기서 측정되지 않은 업계 표준 기대치) — 다른 곳에서는 그렇지 않습니다.