2.5 GOP와 프레임 유형 - I, P, B 프레임
영상 압축의 기본인 I/P/B 프레임, GOP 구조, 롱 GOP와 인트라 코덱의 차이가 편집 정확도와 탐색 속도에 미치는 영향을 설명합니다.
#왜 프레임마다 종류가 다른가
영상은 연속된 사진처럼 보이지만, 인접한 프레임은 대부분 비슷합니다. 뒷배경이 그대로인 장면에서 매 프레임을 통째로 저장하는 것은 낭비입니다. 그래서 대부분의 코덱은 일부 프레임만 통째로 저장하고, 나머지는 "앞뒤 프레임과 달라진 부분"만 저장합니다.
| 프레임 | 이름 | 설명 | 용량 |
|---|---|---|---|
| I | Intra | 다른 프레임 없이 혼자 디코딩 가능한 프레임(키프레임) | 큼 |
| P | Predictive | 이전 프레임을 참조해 차이만 저장 | 중간 |
| B | Bi-directional | 앞과 뒤 프레임을 모두 참조 | 작음 |
#GOP (Group Of Pictures)
I 프레임에서 시작해 다음 I 프레임 직전까지의 묶음을 GOP라고 합니다.
GOP를 설명하는 두 숫자가 있습니다.
- N: GOP 길이(I 프레임 간격). MPEG-2 방송에서 N=12(PAL), N=15(NTSC)가 흔했습니다.
- M: P(또는 I) 프레임 사이의 간격. M=3이면 P 사이에 B가 두 장 들어갑니다.
#Closed GOP와 Open GOP
- Closed GOP: GOP 안의 프레임이 다른 GOP의 프레임을 참조하지 않습니다. 어느 GOP든 독립적으로 잘라 쓸 수 있습니다.
- Open GOP: 앞쪽 B프레임이 이전 GOP의 프레임을 참조할 수 있어 압축 효율은 좋지만, 중간에서 자르면 앞의 몇 프레임이 깨집니다.
편집 시스템이나 MAM이 파일을 재인코딩 없이 자르는(스마트 렌더링, 컷 편집) 경우에는 Closed GOP가 안전합니다.
#직접 확인: 프레임 종류와 크기
H.264로 GOP 길이를 12, B 프레임을 2장까지 허용하도록 인코딩한 합성 영상(320×180, 30fps)에서 각 프레임의 종류를 읽어 화면에 표시했습니다. 아래 그림은 처음 15프레임이며 표시(재생) 순서입니다.
ffmpeg -f lavfi -i testsrc2=size=320x180:rate=30 -frames:v 25 -c:v libx264 -g 12 -bf 2 \
-x264-params scenecut=0:keyint=12:min-keyint=12 -pix_fmt yuv420p gop.mp4
ffmpeg -i gop.mp4 -vf "drawtext=fontfile=arial.ttf:text='#%{n} %{pict_type}':x=8:y=h-46:fontsize=34:fontcolor=white:box=1:[email protected],tile=5x3" -frames:v 1 gop.jpg
같은 파일에서 ffprobe -show_frames로 프레임별 패킷 크기를 읽어 종류별로 색을 입혔습니다.
- 이 샘플에서 I 프레임은 3,800~4,600바이트, P는 719~1,458바이트, B는 612~986바이트였습니다. I 프레임이 B 프레임의 약 4~7배입니다.
- 같은 GOP 안에서도 크기 차이가 크기 때문에, 비트레이트는 일정한 흐름이 아니라 I 프레임 지점마다 솟는 패턴으로 나타납니다. 스트리밍 버퍼나 네트워크 대역폭을 설계할 때 평균값만 보면 안 되는 이유입니다.
- 테스트 패턴은 단순한 영상이라 절대 크기는 실제 방송 소재와 다릅니다. 종류별 상대적인 크기 관계를 보는 용도입니다.
#롱 GOP와 인트라 코덱
| 방식 | 구조 | 예 | 장점 | 단점 |
|---|---|---|---|---|
| 롱 GOP | I/P/B 혼합 | MPEG-2(XDCAM HD), H.264, H.265 | 같은 화질에서 용량이 작음 | 프레임 정확 탐색에 디코딩 부담 |
| 인트라 | 모든 프레임이 I | ProRes, DNxHD/HR, AVC-Intra, MJPEG | 프레임 정확 편집이 쉬움 | 용량이 큼 |
방송 제작 소재에는 편집 정확도를 위해 인트라 코덱이나 짧은 GOP를 많이 쓰고, 송출·배포용은 롱 GOP로 압축합니다.
#GOP가 시스템 설계에 미치는 영향
- 탐색 속도와 정확도: 사용자가 특정 시간을 클릭하면 플레이어는 그 이전의 가장 가까운 I프레임으로 이동한 뒤 목표 프레임까지 디코딩합니다. GOP가 길면 목표 프레임에 도달할 때까지 시간이 오래 걸립니다.
- 프록시 설계: 웹 프록시는 GOP를 짧게(예: 1~2초) 설정해야 탐색이 빠릅니다.
- 구간 추출(Partial Restore, 서브클립): 컷 지점이 I프레임이 아니면 재인코딩이 필요합니다. 아카이브에서 일부 구간만 복원하는 기능은 GOP 경계를 계산해서 필요한 만큼만 읽어야 합니다.
- 전송 오류 복구: 오류가 발생했을 때 다음 I프레임까지 화면이 깨집니다. 방송 송출용 스트림에서 GOP를 일정 길이 이하로 제한하는 이유입니다.
#직접 확인하기
프레임 유형 순서는 ffprobe로 볼 수 있습니다.
# 처음 40 프레임의 유형(I/P/B)을 출력
ffprobe -v error -select_streams v:0 -show_entries frame=pict_type -of default=nw=1:nk=1 -read_intervals "%+#40" input.mp4 | tr '\n' ' '
-g 30으로 만든 H.264 프록시에서 실제로 얻은 출력은 다음과 같습니다(표시 순서 기준).
I P B B P P P B B B P B P B P P P B B P B P P B P B P P B P I B P B P P P B B P
I프레임 사이의 간격(여기서는 30프레임)이 GOP 길이입니다. 위 도표처럼 규칙적인 I B B P 패턴이 아니라 B프레임 수가 장면에 따라 달라지는 것도 볼 수 있는데, x264가 장면에 맞춰 B프레임 개수를 조절하기 때문입니다. 반면 FFmpeg의 기본 MPEG-2 인코더로 만든 파일은 B프레임 없이 12프레임마다 I프레임이 나옵니다.
I P P P P P P P P P P P I P P P P P P P P P P P I P P P P P
I프레임 간격을 세어 GOP 길이를 알 수 있습니다.
#정리
- I는 독립, P는 이전 참조, B는 앞뒤 참조 프레임입니다.
- GOP 길이는 압축 효율과 탐색·편집 정확도 사이의 균형입니다.
- 프록시와 서브클립 기능을 설계할 때 GOP 경계를 반드시 고려해야 합니다.
#참고 자료
링크는 2026-10-28에 열람이 되는 것을 확인했습니다. 규격과 도구 문서는 개정될 수 있으므로 적용하기 전에 최신 판을 확인하세요.