02 · 비월주사(Interlaced) vs 순차주사(Progressive)
이 문서가 답하는 질문: 1080i와 1080p는 무엇이 다른가? 왜 빗살 무늬가 보이는가? 선행:
01-pixel-resolution-aspect.md
한 줄 답
순차주사는 한 프레임을 통째로 그리고, 비월주사는 한 프레임을 홀수줄(odd field)·짝수줄(even field) 두 번에 나눠 그린다. 이 차이가 1930년대 흑백 TV의 깜빡임 문제를 풀었지만, 90년 뒤 디지털 시대에 빗살(combing) 아티팩트라는 빚을 남겼다.
Why — 왜 이런 게 만들어졌나
1930년대 NTSC TV 표준을 만들 때 두 제약이 있었다.
- 전력망 주파수와 동기화 — 미국 60Hz, 유럽 50Hz. CRT 빔 깜빡임을 전력망에 맞추지 않으면 흔들렸다.
- 대역폭 제한 — 6 MHz 채널에 30 fps × 525 줄 통째로 보내기엔 무리. 절반씩 보내자.
해법:
- 한 프레임을 홀수 줄(field 1) 과 짝수 줄(field 2) 로 쪼갠다.
- 60Hz 전력망에서 초당 60 field = 30 frame, 깜빡임은 60Hz로 줄어든 것처럼 눈에 보임.
- 대역폭은 절반.
→ “두 번에 걸쳐 그리지만 깜빡임은 두 배 빠르게 느껴진다”는 인지 트릭. CRT의 잔광·뇌의 합성 능력에 기댄 설계.
How — 어떻게 동작하는가
비월주사의 공간-시간 구조
프레임 1: ─── line 1 (top field, t=0)
(line 2 비어있음)
─── line 3 (top field, t=0)
(line 4 비어있음)
...
프레임 2: (line 1 비어있음)
─── line 2 (bottom field, t=1/60s)
(line 3 비어있음)
─── line 4 (bottom field, t=1/60s)
...→ field 1과 field 2는 시간이 다르다 (1/60초 차이). 이것이 모든 디인터레이싱 문제의 원인.
| 표기 | 풀이 |
|---|---|
| 1080i60 | 1080줄, 비월, 60 field/s = 30 frame/s |
| 1080i50 | 1080줄, 비월, 50 field/s = 25 frame/s (PAL/유럽) |
| 1080p30 | 1080줄, 순차, 30 frame/s |
| 1080p60 | 1080줄, 순차, 60 frame/s — i60과 같은 대역폭 |
Field Order (TFF / BFF)
- TFF (Top Field First): 홀수 줄을 먼저 표시. HDV·대부분 HD 방송.
- BFF (Bottom Field First): 짝수 줄을 먼저. NTSC DV·일부 SD.
field order를 잘못 알고 디인터레이스하면 모션이 거꾸로 흐른다.
# 자동 감지 (idet 필터)
ffmpeg -i in.mov -vf idet -f null - 2>&1 | grep "Single frame detection"
# → "TFF: 25 BFF: 0 Progressive: 0 Undetermined: 0" 같은 출력What — 비월주사 자산 식별과 처리
진단
# 컨테이너 메타
ffprobe -select_streams v:0 -show_entries stream=field_order in.mov
# field_order=tt → top field first interlaced
# field_order=bb → bottom field first interlaced
# field_order=progressive → 순차
# 실제 프레임 분석 (메타가 거짓일 수 있음)
ffmpeg -i in.mov -vf idet -f null - 2>&1 | tail -3빗살(combing) 아티팩트 — 왜 보이는가
비월주사 영상을 순차 디스플레이(LCD/OLED)에 그대로 표시하면, 모션이 있는 장면에서 수평 빗살이 나온다 — field 1과 field 2의 시간차(1/60초)가 그대로 노출되기 때문.
정지: 두 field가 같은 위치 → 깨끗
움직임: field 1과 field 2의 피사체 위치가 다름 → 빗살무늬디인터레이싱 알고리즘
| 방법 | 원리 | 품질 | 비용 |
|---|---|---|---|
| Bob (Linedouble) | 한 field를 2배로 늘려 한 프레임 (60 frame/s) | 낮음 (수직 해상도 절반) | 매우 낮음 |
| Weave | 두 field를 합쳐 한 프레임 (30 frame/s) | 정지 장면만 OK / 모션 빗살 | 매우 낮음 |
| Blend | 두 field 평균 | 잔상(ghosting) | 낮음 |
| Yadif | edge-directed 보간 + 모션 적응 | 좋음 | 중간 |
| Yadif + bobbing | Yadif를 60p로 출력 | 매우 좋음 | 중간 |
| bwdif | yadif + 모션 보상 | 더 좋음 | 중간 |
| nnedi3 / QTGMC | 신경망/모션벡터 보간 (Avisynth) | 최고 | 매우 높음 |
# 표준 디인터레이스 (yadif)
ffmpeg -i interlaced.mov -vf yadif=1 -c:v libx264 progressive.mp4
# ↑ mode=1 → 60p (bob), mode=0 → 30p (frame)
# 더 좋은 품질 (bwdif)
ffmpeg -i in.mov -vf bwdif=mode=1:parity=0:deint=1 out.mp4
# ↑ tff텔레시네 (Telecine, 3:2 pulldown) — 영화→NTSC 변환의 산물
영화는 24 fps, NTSC 비디오는 29.97 fps. 24를 30으로 늘릴 때 3:2 pulldown 을 쓴다 — 4 영화 프레임을 5 비디오 프레임(=10 field)로 펼치는 패턴:
Film: A B C D
Field: A1 A2 | B1 B2 B3 | C2 C3 | D1 D2 D3
↑ 2 field ↑ 3 field ↑ 2 ↑ 3→ NTSC 방송에서 영화를 보면 비월주사 + 3:2 pulldown이 섞여 있어 단순 디인터레이스로는 빗살이 남는다. 역텔레시네(IVTC, inverse telecine) 가 필요:
# IVTC: 29.97i → 24p 복원
ffmpeg -i ntsc_film.mov -vf "fieldmatch,decimate" -r 24000/1001 -c:v libx264 film24p.mp4
# ↑ field 매칭 ↑ 5중복 1프레임 제거모던 자산 정규화 권장 (방송→웹)
# 1080i59.94 (NTSC 방송) → 1080p59.94 (웹 표준)
ffmpeg -i tape.mxf \
-vf "bwdif=mode=1:parity=auto" \
-c:v libx264 -preset slow -crf 18 \
-c:a aac -b:a 192k \
output_progressive.mp4
# 1080i50 (PAL 방송) → 1080p50 또는 1080p25
ffmpeg -i euro_tape.mxf -vf "bwdif=mode=1" -r 50 -c:v libx264 out50p.mp4
ffmpeg -i euro_tape.mxf -vf "bwdif=mode=0" -r 25 -c:v libx264 out25p.mp4What-if — 잘못 다루면 어떻게 깨지는가
❌ 함정 1 — interlaced 자산을 그대로 H.264 인코딩
H.264에는 picture coding type 으로 MBAFF/PAFF (Macroblock/Picture Adaptive Frame-Field) 가 있어 비월주사를 압축할 수 있다. 그러나:
- 모바일/Web 디코더 상당수가 MBAFF를 잘 못 그린다.
- 결과: 데스크톱에서는 멀쩡한데 모바일 Safari에서 빗살.
- 권장: 전송 전 디인터레이스해서 progressive로 변환.
❌ 함정 2 — Yadif mode=0 (30p)을 60p 자산에 적용
비월 60i를 yadif mode=0으로 디인터레이스하면 30 fps progressive가 나온다 — 모션 정보의 절반을 버린다. 스포츠·게임에서는 부자연스럽다. mode=1로 60p로 빼는 게 정석.
❌ 함정 3 — Field order 잘못 잡기
TFF 자산을 BFF로 디인터레이스하면 모션이 거꾸로 흐르는 듯한 떨림(judder).
ffmpeg는 parity=0 (TFF), parity=1 (BFF), parity=-1 (auto)로 명시 가능.
❌ 함정 4 — 텔레시네를 단순 디인터레이스만
3:2 pulldown된 24p 영화는 디인터레이스만 하면 24p의 절반은 잔상이다.
IVTC(fieldmatch + decimate)가 정답이지만, 콘텐츠 검출을 잘못하면 (예: 진짜 30p와 텔레시네가 섞인 자산) 가끔 떨림.
❌ 함정 5 — i와 p를 같은 라인레이트라고 착각
| 표기 | 실제 frame rate |
|---|---|
| 1080i60 | 30 fps (60 field) |
| 1080p60 | 60 fps |
→ 1080p60이 1080i60보다 2배 많은 데이터. 비트레이트 결정 시 주의.
Insight — 흥미로운 이야기
“비월주사는 60Hz 전력망의 그림자다”
60Hz 미국·30fps NTSC, 50Hz 유럽·25fps PAL. 이 분단은 1953년 컬러TV 호환성 결정에서 시작됐고, 1990년대 HDTV로 넘어올 때도 SMPTE는 방송국 인프라가 못 따라온다는 이유로 1080i를 표준에 넣었다. 그래서 BBC·ABC·NHK는 2000년대까지 1080i로 송출했고, 같은 시기 영화는 24p, 게임 콘솔은 720p/1080p로 가버렸다. → 2010년대 OLED 시대의 빗살 문제는 1930년대 CRT 설계의 청구서.
“QTGMC라는 전설”
Avisynth용 디인터레이서 QTGMC(Quick Temporal Gaussian Motion Compensated)는 모션벡터를 추정해 두 field 사이의 진짜 객체 위치를 복원한다. ffmpeg yadif/bwdif보다 훨씬 깨끗하지만 CPU 비용이 100배 — 영화 복원·아카이브용으로만 쓴다. 넷플릭스의 1980년대 시트콤 4K 리마스터(Cheers·Seinfeld) 뒤에는 QTGMC가 있다.
“왜 NHK는 8K를 비월로 안 만들었나”
8K NHK Super Hi-Vision(BT.2100, 2018)은 처음부터 120p progressive. 1080i 시대의 빚을 더는 안 지겠다는 명시적 결정. → 비월주사는 8K 시대에서 끊겼다.
요약 + Mermaid
비월주사는 1930년대 60Hz 전력망과 6MHz 대역폭 제약을 푸는 트릭이었고, 디지털 디스플레이엔 빗살을 남겼다. 모던 워크플로는 모든 자산을 progressive로 정규화 — yadif/bwdif로 디인터레이스, 영화는 IVTC로 24p 복원. 1080i와 1080p는 같은 해상도가 아니다. 시간 정보의 절반이 비월주사에서 다르다.