비트레이트와 프록시 설계

#비트레이트란

비트레이트(Bitrate) 는 영상 1초를 표현하는 데 쓰는 데이터량입니다(단위: Mbps, kbps). 같은 코덱에서는 비트레이트가 높을수록 화질이 좋고 파일이 큽니다.

비트레이트에서 파일 크기는 다음처럼 계산합니다.

파일 크기(GB) ≈ 비트레이트(Mbps) × 재생 시간(초) ÷ 8 ÷ 1000
예) 50 Mbps × 3,600초 ÷ 8 ÷ 1000 = 22.5 GB / 1시간

#코덱별 대표 비트레이트

방송 현장에서 자주 보는 값입니다(해상도·프레임레이트에 따라 다름).

용도	코덱/프로파일	대표 비트레이트	1시간 용량
비압축 HD	10bit 4:2:2	약 1.5 Gbps	약 670 GB
편집 마스터	ProRes 422 HQ (1080)	약 220 Mbps	약 100 GB
방송 제작	DNxHD 145/185	145~185 Mbps	약 65~85 GB
방송 제작	XDCAM HD422	50 Mbps	약 22 GB
방송 제작	XDCAM EX/HD	35 Mbps	약 16 GB
배포	H.264 (고화질 HD)	8~20 Mbps	3.6~9 GB
웹 프록시	H.264 (360p~480p)	0.5~2 Mbps	0.2~0.9 GB

용량 계획에서는 이 표처럼 "1시간 소재가 얼마나 차지하는가"를 코덱별로 정리해 두면 연간 증가량, 스토리지 티어 구성을 추정할 수 있습니다.

#CBR과 VBR

CBR(Constant Bitrate): 일정한 비트레이트. 방송 장비·송출 서버·SDI 인터페이스 호환성이 좋습니다.
VBR(Variable Bitrate): 복잡한 장면에는 많이, 단순한 장면에는 적게. 같은 평균 비트레이트에서 화질이 좋지만, 장비에 따라 피크를 제한해야 합니다.

#직접 확인: 같은 프레임, 다른 비트레이트

같은 소스(640×360, 25fps 프랙탈 영상)를 비트레이트만 바꿔 3초씩 인코딩하고, 60번째 프레임의 일부를 3배로 확대해 비교했습니다.

ffmpeg -i source.mp4 -t 3 -c:v libx264 -b:v 120k -maxrate 120k -bufsize 120k -pix_fmt yuv420p br_120k.mp4

같은 프레임을 120kbps, 600kbps, 6000kbps로 인코딩해 확대한 비교. 120kbps에서 경계가 뭉개지고 블록이 보임 — 왼쪽부터 120kbps(43KB), 600kbps(230KB), 6000kbps(2,150KB). 파일 크기는 3초 분량입니다.

120kbps에서는 세밀한 무늬의 경계가 뭉개지고 블록 형태의 열화가 보입니다.
600kbps와 6000kbps는 이 확대 비율에서 육안으로 구별하기 어려웠습니다. 그런데 파일 크기는 약 9배 차이입니다.
필요한 비트레이트는 해상도와 영상 내용(움직임, 무늬의 복잡도)에 따라 크게 달라집니다. 위 결과는 이 소스 하나의 관찰이므로, 프록시 프로파일은 대표 소재 몇 가지로 직접 테스트해서 정하세요.

#원본(Hi-res)과 프록시(Proxy)

MAM에서는 하나의 소재에 대해 보통 두 가지 이상의 파일을 관리합니다.

구분	원본(Hi-res)	프록시(Proxy)
용도	편집, 송출, 보관	검색, 미리보기, 구간 지정, 웹 검수
해상도	방송 해상도(1080 등)	360p~480p 정도
코덱	방송용 코덱	H.264 + AAC
위치	고성능 스토리지/아카이브	웹에서 접근하기 쉬운 스토리지
용량	큼	원본의 1~5% 수준

프록시가 있으면 사용자는 수 기가바이트짜리 원본을 건드리지 않고 브라우저에서 영상을 보고, 마커와 서브클립 구간을 지정할 수 있습니다. 구간 지정 정보는 타임코드(1장)로 기록되므로, 원본과 프록시의 타임코드가 일치해야 합니다.

#프록시 설계 체크리스트

해상도: 모든 소재를 같은 높이(예: 360p 또는 480p)로 맞춥니다. 가로 폭은 DAR에 맞춰 짝수로 자동 계산합니다.
프레임레이트: 원본과 동일하게 유지하는 것이 안전합니다. 타임코드 계산이 단순해지기 때문입니다.
GOP 길이: 1~2초로 짧게 설정해 탐색을 빠르게 만듭니다(앞 글 참고).
faststart: moov를 앞쪽에 둡니다(앞 글 참고).
오디오: 스테레오 AAC로 믹스다운하거나 필요한 채널만 선택합니다.
디인터레이스: 인터레이스 소스는 웹 재생용으로 디인터레이스 필터를 적용합니다.
시작 타임코드: 원본의 시작 타임코드를 프록시의 메타데이터나 DB에 별도로 보관합니다. 컨테이너에 남기기 어려운 경우가 많습니다.
자동화와 검증: 생성 후 길이·프레임 수가 원본과 같은지 검사합니다.

#FFmpeg 예제

#기본 웹 프록시 (360p)

ffmpeg -i input.mxf \
  -vf "yadif=0:-1:0,scale=-2:360" \
  -c:v libx264 -preset medium -crf 28 -g 30 -keyint_min 30 -sc_threshold 0 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 96k -ac 2 \
  -movflags +faststart \
  proxy.mp4

옵션의 의미는 다음과 같습니다.

옵션	설명
`yadif=0:-1:0`	모든 프레임을 디인터레이스(필드 순서 자동 감지). 소스가 프로그레시브이면 이 필터를 빼세요
`scale=-2:360`	높이 360에 맞추고 가로는 비율대로, 짝수 보정
`-crf 28`	화질 기준 값(낮을수록 고화질). 프록시는 26~30 범위가 무난
`-g 30 -keyint_min 30 -sc_threshold 0`	키프레임 간격을 30프레임(약 1초)으로 고정
`-pix_fmt yuv420p`	거의 모든 브라우저와 호환되는 색차 샘플링
`-movflags +faststart`	`moov`를 파일 앞으로 이동

#오디오가 여러 모노 트랙인 경우

방송 소재는 모노 트랙 여러 개로 오디오가 나뉘어 있는 경우가 많습니다. 앞 두 트랙을 스테레오로 합치는 예입니다.

ffmpeg -i input.mxf \
  -filter_complex "[0:a:0][0:a:1]amerge=inputs=2,pan=stereo|c0=c0|c1=c1[a]" \
  -map 0:v:0 -map "[a]" \
  -vf "scale=-2:360" -c:v libx264 -crf 28 -g 30 -c:a aac -b:a 96k \
  -movflags +faststart proxy.mp4

현업 경험 · 용도별 프리셋(프록시 포함)이 바뀐 과정과 병렬 처리

프로파일의 변화. 과거에는 빠르게 트랜스코딩하려고 320p, 300Kbps 정도의 낮은 프로파일을 썼습니다. 이후 시스템 성능이 좋아지고 GPU 트랜스코딩도 쓰게 되면서 720p, 1Mbps 수준으로 올렸습니다.

사용처별 프리셋. 변환 결과를 프록시 하나로 두지 않고, 프록시를 포함해 용도별로 프리셋을 관리해서 처리했습니다.

용도	목적
MAM 프록시	시스템 안에서 보고 검색하는 용도
아카이브용	이후 복원을 위한 보관
메자닌	외부 업체 전달
저해상도	휴대폰에서 보기

병렬 처리와 시스템 관리. 과거에는 작업 하나로는 시스템 성능을 끝까지 쓰지 못해서 여러 작업을 병렬로 돌려 처리량을 높였습니다. 이때 스레드별 작업 상태를 UI에 보여 주는 과정에서 충돌이 나는 문제가 있었습니다. 최근에는 작업 하나만으로도 사용률이 약 90%까지 올라갑니다. 그런데 두 작업을 동시에 돌리면 사용률이 100%가 되면서 외부에서 거는 제어(중지, 상태 확인 등)가 제대로 먹지 않는 시스템 관리 문제가 생겼습니다. 성능이 좋아졌다고 해서 동시 작업 수를 늘리는 것이 항상 이득은 아니었습니다.

#정리

비트레이트로 파일 용량을 추정하고, 코덱별 시간당 용량표를 만들어 스토리지를 계획합니다.
원본과 프록시를 분리 관리하며, 프록시는 짧은 GOP·faststart·디인터레이스를 기본으로 설계합니다.
프록시 설정은 프로파일로 분리해 두면 재생성과 정책 변경이 쉬워집니다.

다음 장에서는 이 파일들을 MediaInfo와 FFprobe로 분석하는 방법을 다룹니다.

#참고 자료

FFmpeg Wiki: H.264 인코딩 가이드

링크는 2026-10-28에 열람이 되는 것을 확인했습니다. 규격과 도구 문서는 개정될 수 있으므로 적용하기 전에 최신 판을 확인하세요.