3단계 파이프라인 — Decode → Filter → Encode

ffmpeg이 매번 실제로 하는 일

모든 ffmpeg 호출은 같은 5단계 파이프라인이야. 냅킨에 그릴 수 있게 되면, 커맨드라인 flag가 더 이상 random하게 안 느껴져.

Demux — input container 열어서 raw stream으로 분리 (video, audio, subtitle, data).
Decode — 압축된 stream 각각을 raw frame/sample로.
Filter — 선택적으로 filter 돌려 (scale, crop, drawtext, loudnorm, fps, …).
Encode — raw frame/sample을 다시 codec으로 압축.
Mux — encode된 stream을 output container로 감싸.

encode 단계 건너뛰면 (-c copy) remux — bit이 demuxer에서 muxer로 바로 흘러, re-encode 없음. 4K 파일이 remux는 1초 안에 끝나는데 같은 파일 re-encode는 분 단위인 이유야.

flag가 단계에 어떻게 매핑되는지

커맨드라인 flag 순서는 실행 순서가 아니야. 위치가 중요해 — input flag는 -i 앞, output flag는 output 파일명 앞. 머릿속 모델:

-ss 30 이 -i 앞 = demux 시간에 seek (30초로 점프) — 빠름.
-ss 30 이 -i 뒤 = 30초까지 decode 후 버림 — 느리지만 frame 정확.
-c:v libx264 가 output 파일명 앞 = stage 4 encoder 선택.
-vf scale=1280:720 = video stream에 적용된 stage 3 filter.

Code

한 줄에 5단계 다·bash

# input.mov demux, video+audio decode, 720p로 scale,
# H.264 + AAC encode, output.mp4 로 mux
ffmpeg -i input.mov \
  -vf "scale=1280:720" \
  -c:v libx264 -crf 20 -preset slow \
  -c:a aac -b:a 192k \
  output.mp4

encode 통째로 건너뛰기 (remux)·bash

# Demux + mux 만 — 같은 압축 bit이 새 container로 떨어져
# 4K source에 30초 vs 30분
ffmpeg -i input.mkv -c copy output.mp4

# re-encode 안 됐는지 확인: byte count가 매우 가까워야 함
ls -lh input.mkv output.mp4

Exercise

30초 짜리 영상 클립 하나 잡아. 명령 두 개 돌려: (1) ffmpeg -i clip.mp4 -c copy out_remux.mp4 그리고 (2) ffmpeg -i clip.mp4 -c:v libx264 -crf 23 -c:a aac out_encode.mp4. 각각 wall-clock 시간 메모 (time 사용). ffprobe 로 out_remux.mp4 의 codec_name이 input과 같고 format_name 만 달라졌는지 확인.