홈 › 4장 FFmpeg 실전 변환

4.5 인터레이스, 화면비, 프레임레이트 변환

디인터레이스 필터(yadif, bwdif)와 출력 프레임 수, 픽셀 종횡비(SAR/DAR) 처리, 레터박스, 29.97에서 25fps 변환의 두 가지 방식과 부작용을 실제 실행 결과로 설명합니다.

최종 수정 2026-10-28 · 읽는 시간 약 5분 · 운영 프리즘(Prism) · 편집 원칙

#1) 디인터레이스

1장에서 설명했듯 인터레이스 소스를 웹(프로그레시브)용으로 변환할 때는 디인터레이스가 필요합니다. FFmpeg에는 yadif와 bwdif 같은 필터가 있고, 두 가지 모드를 선택합니다.

모드 의미 1080i 29.97 입력의 결과
mode=0 (send_frame) 프레임당 1장 출력 29.97fps (150프레임)
mode=1 (send_field) 필드당 1장 출력 59.94fps (300프레임)

5초(150프레임) 인터레이스 소스로 직접 실행한 결과입니다.

yadif=0  → 150프레임, 30000/1001fps
yadif=1  → 300프레임, 60000/1001fps
bwdif=0  → 150프레임, 30000/1001fps
bwdif=1  → 300프레임, 60000/1001fps
  • 프록시: 프레임 수가 같은 mode=0이 간단하고 타임코드 계산도 원본과 동일합니다.
  • 스포츠처럼 움직임이 빠른 소재의 고품질 변환: mode=1로 모든 필드를 살려 59.94fps로 만들 수 있지만, 용량이 늘고 프레임 번호와 원본 타임코드가 1:2로 달라집니다.

bwdif는 yadif와 같은 인터페이스를 가지며 일반적으로 화질이 더 좋지만 처리 시간이 더 걸립니다.

#필터 적용 여부 판단

-vf "yadif=0:-1:0"   # 모든 프레임에 디인터레이스 (필드 순서 자동)
-vf "yadif=0:-1:1"   # 인터레이스로 표시된 프레임에만 적용

세 번째 값이 1이면 소스의 인터레이스 플래그가 있는 프레임에만 필터가 적용됩니다. 그러나 방송 소재에서는 플래그가 정확하지 않은 경우가 있으므로, 3장에서 소개한 프레임 통계(interlaced_frame)와 MediaInfo의 Scan type을 먼저 확인하세요. 프로그레시브 소스에 디인터레이스를 적용하면 화질이 불필요하게 떨어집니다.

#직접 확인: 빗살 무늬와 디인터레이스

60fps 프로그레시브 영상에서 흰 사각형이 프레임당 8픽셀씩 움직이도록 만들고, interlace 필터로 인터레이스(TFF)화한 뒤 yadif로 되돌렸습니다. 사각형의 가장자리를 3배로 확대한 결과입니다.

ffmpeg -i prog.mp4 -vf interlace=scan=tff -c:v libx264 -crf 12 -flags +ilme+ildct -pix_fmt yuv420p int.mp4
ffmpeg -i int.mp4 -vf yadif=0:-1:0 -c:v libx264 -crf 12 -pix_fmt yuv420p deint.mp4
움직이는 흰 사각형의 가장자리 확대. 원본 프로그레시브는 깨끗하고 인터레이스 프레임은 좌우 가장자리에 빗살 무늬가 있으며 yadif 적용 후 빗살이 사라짐
왼쪽: 원본 프로그레시브(60p), 가운데: 인터레이스 변환 프레임, 오른쪽: yadif 적용 후.

인터레이스 프레임의 좌우 가장자리에 줄무늬가 보입니다. 한 프레임 안의 홀수 줄과 짝수 줄이 1/60초 간격으로 찍힌 서로 다른 시점이어서, 움직인 8픽셀만큼 줄마다 위치가 엇갈린 것입니다. yadif를 적용하면 줄무늬가 사라지지만 윗가장자리에 흐린 띠가 약간 남았습니다. 디인터레이스는 없는 줄을 보간으로 채우는 처리라 원본을 완벽하게 복원하지는 못합니다.

#2) 픽셀 종횡비(SAR)와 화면비(DAR)

1장에서 SD 소재는 정사각형이 아닌 픽셀을 쓴다고 설명했습니다. 720×480 안에 16:9 화면을 담은 파일(SAR 32:27)을 웹 프록시로 만드는 경우를 보겠습니다.

원본: 720x480, SAR 32:27, DAR 16:9

#단순 스케일 (SAR을 신경 쓰지 않은 경우)

ffmpeg -i sd169.mxf -vf "scale=-2:360" -c:v libx264 naive.mp4
결과: 540x360, SAR 32:27, DAR 16:9

SAR 정보가 유지되었으므로 SAR을 지원하는 플레이어는 올바른 비율(640×360)로 보여 줍니다. 그러나 SAR을 무시하는 환경(일부 플레이어, 이미지 변환, 캔버스 처리)에서는 540×360(3:2)으로 보여 영상이 눌립니다.

#정사각형 픽셀로 정규화

DAR을 알고 있다면 목표 해상도를 DAR에 맞춰 직접 지정하고 SAR을 1로 고정하는 것이 가장 확실합니다.

ffmpeg -i sd169.mxf -vf "scale=640:360,setsar=1" -c:v libx264 sq2.mp4
결과: 640x360, SAR 1:1, DAR 16:9

#직접 확인: SAR을 무시하면 이렇게 보입니다

1280×720 원본에 원과 격자를 그린 이미지를 720×480(SAR 32:27)으로 저장한 파일을 만들었습니다. ffprobe로 읽으면 720,480,32:27,16:9(너비, 높이, SAR, DAR)였습니다.

ffmpeg -i sar.mp4 -frames:v 1 raw.png                                  # 디코딩된 화소 그대로 (720x480)
ffmpeg -i sar.mp4 -vf "scale=854:480,setsar=1" -frames:v 1 fixed.png   # DAR 16:9에 맞춰 854x480
같은 파일을 SAR 없이 720x480으로 그리면 원이 세로로 긴 타원이 되고, 854x480 정사각 픽셀로 변환하면 원이 정상으로 보임
왼쪽: SAR을 무시하고 화소 그대로 그린 화면(원이 세로로 길어짐). 오른쪽: DAR 16:9에 맞춰 854×480, SAR 1:1로 변환한 화면.

왼쪽처럼 SAR을 읽지 않는 환경에서는 원이 타원으로, 화면 전체가 좁아 보입니다. 그림의 오른쪽이 바로 위에서 설명한 정규화 결과입니다(16:9를 480높이에서 정확히 계산하면 853.33이라 짝수인 854로 맞췄습니다).

#3) 레터박스와 필러박스

4:3 소재를 16:9 화면에 넣어야 할 때는 비율을 유지하고 남는 부분을 검은색으로 채웁니다.

# 4:3(640x480)을 높이 360으로 줄이고, 640x360 캔버스 중앙에 배치
ffmpeg -i in43.mp4 -vf "scale=-2:360,pad=640:360:(ow-iw)/2:0:black" out.mp4

결과는 640×360이며 좌우에 검은 띠(필러박스)가 생깁니다. 반대로 와이드 소재를 4:3에 넣으면 위아래 띠(레터박스)가 생깁니다. 소재에 이미 검은 띠가 들어 있는 경우는 3장의 cropdetect로 감지해 자를 수 있습니다.

#4) 프레임레이트 변환

29.97fps 소재를 25fps(PAL 계열)로 바꾸는 방법은 두 가지가 있으며 결과가 전혀 다릅니다.

#A. 프레임 드롭 (fps 필터)

ffmpeg -i input.mxf -vf "yadif,fps=25" out_a.mp4
결과: 125프레임, 25fps, 길이 5.000초 (원본 5.005초 → 거의 동일)

시간은 그대로 유지하고 프레임을 솎아 냅니다. 오디오는 그대로 써도 싱크가 맞습니다. 대신 일정하지 않은 간격으로 프레임이 빠져 움직임이 미세하게 끊깁니다(저더, judder).

#B. 속도 변경 (setpts)

ffmpeg -i input.mxf -vf "yadif,setpts=PTS*30000/1001/25,fps=25" out_b.mp4
결과: 150프레임, 25fps, 길이 6.000초 (원본 5.005초 → 약 20% 느려짐)

모든 프레임을 그대로 유지하고 재생 속도를 늦춰 25fps에 맞춥니다. 움직임은 부드럽지만 영상이 느려지고 길이가 늘어납니다. 오디오도 같은 비율로 늘려야 싱크가 맞고(atempo 등), 음높이를 유지할지 여부도 선택해야 합니다.

방식 프레임 수 길이 장점 단점
A. fps (프레임 드롭) 감소 유지 시간·오디오 싱크 유지 움직임이 끊김
B. setpts (속도 변경) 유지 변경 프레임 보존 길이·오디오 변경

방송 현장의 프레임레이트 변환(스탠더드 컨버전)은 전용 장비나 모션 보간(minterpolate 등) 으로 품질을 맞추는 경우가 많고, 비용과 품질 요구에 따라 선택합니다. 어떤 방식이든 타임코드는 새 프레임레이트 기준으로 다시 계산해야 하며, 원본 타임코드와의 대응표를 보관해 두어야 합니다.

#정리

  • 디인터레이스는 mode=0(프레임 유지)과 mode=1(필드 유지, 프레임 수 2배)을 구분하고, 적용 전에 소스가 실제 인터레이스인지 확인합니다.
  • SD 소재는 SAR을 확인하고, 웹용은 DAR 기준 해상도로 직접 스케일하고 setsar=1 로 정규화합니다.
  • 프레임레이트 변환은 프레임 드롭과 속도 변경 중 무엇을 택하느냐에 따라 길이·오디오·움직임이 달라지며, 결과와 타임코드 매핑을 기록해야 합니다.

#참고 자료

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