B-frame 이해하기 — 참조 구조, 재정렬, 지연

"B-frame이 미래를 어떻게 알지?", "왜 전송 순서가 표시 순서랑 다르지?", "그럼 재배열하면 되니까 WebRTC에서도 써도 되는 거 아냐?". 이 세 질문은 영상 코덱을 처음 깊이 파고드는 사람이 반드시 부딪히는 지점입니다. 이 글은 B-frame을 5 STEP 비유 + 시각화로 끝까지 풀어보는 심화 가이드입니다.

앞선 글 두 편이 개념 기초(프레임의 모든 것)와 실무 코덱 선택(H.264 Profile·비트레이트)을 다뤘다면, 이 글은 B-frame 하나만 파고듭니다. 모든 설명은 비유 → 그림 → 메커니즘 순서입니다.

먼저 — 왜 B-frame이 존재하는가? (목적: 압축률)

같은 화질로 파일 크기를 줄이는 것이 목표입니다.

I-picture: 외부 reference 없이 intra prediction           → 큰 경우가 많음
P-picture: list 0 reference 기반 prediction + residual     → content에 따라 다름
B-picture: list 0/list 1 prediction + residual             → 작은 경우가 많음

B-slice는 list 0, list 1 또는 양쪽 reference list에서 block prediction을 만들 수 있어 선택지가 늘어납니다. 단순한 시간 중간값을 저장하는 구조는 아닙니다.

세 가지 프레임 타입 — 상대 용량 비교

기분을 문자로 보내는 비유

친구한테 매일 기분을 숫자로 문자 보낸다고 생각해봅시다. 글자 수가 요금이라 최대한 짧게 보내고 싶습니다.

월요일 기분: 😊 100점
화요일 기분: 😐 150점
수요일 기분: 😄 200점

I-frame 방식 (매번 다 보냄):

월: "오늘 기분 100점"
화: "오늘 기분 150점"   ← 매번 처음부터 다 설명
수: "오늘 기분 200점"

→ 글자 수 많음.

P-frame 방식 (과거만 참조):

월: "오늘 기분 100점"               ← 기준점
화: "어제보다 50점 올랐어"          ← 어제만 참조
수: "어제보다 50점 올랐어"          ← 어제만 참조

→ 달라진 것만 보내니 짧아짐.

B-frame 방식 (과거+미래 참조):

월: "오늘 기분 100점"               ← 기준점
수: "월요일보다 100점 올랐어"       ← 수요일 먼저!
화: "월·수요일을 참고해 차이를 설명" ← 두 reference를 쓰는 비유

이 비유의 핵심은 표시 순서상 뒤의 reference도 encoder가 사용할 수 있다는 점입니다. 실제 codec은 pixel의 산술 중간값이 아니라 block별 motion compensation과 residual을 부호화합니다.

STEP 1 — 카메라가 찍어서 버퍼에 쌓는다

가장 헷갈리는 질문: B-frame은 "미래"를 어떻게 알지?

답: encoder는 표시 순서상 뒤의 reference picture가 capture될 때까지 입력을 buffer할 수 있습니다.

STEP 2 — 인코더가 B-frame 만들 때의 사고 과정

STEP 3 — 인코더 처리 순서 (촬영 순서 ≠ 인코딩 순서)

카메라는 t=0 → t=1 → t=2 → t=3 순서로 찍지만, 인코더는 다른 순서로 처리합니다.

STEP 4 — 인코딩 지연의 정체

영상통화는 실시간입니다. 카메라가 t=1을 찍는 순간 바로 보내야 자연스럽습니다. 그런데 B-frame을 쓰면:

STEP 5 — 디코더를 위한 decoding order 재배열

encoder는 reference picture가 먼저 decode되도록 bitstream을 decoding order로 출력합니다. RTP packet은 이 순서로 보내지만 network reordering은 별도로 발생할 수 있어 sequence number로 복원합니다.

디코더 입장에서 한 번 더

❌ 잘못된 순서로 보내면:
받은 순서: I(0) → B(1) → B(2) → P(3)
디코더:    I(0) 디코딩 OK
           B(1) 디코딩 시도... "t=3이 없는데??" 💥 오류!

✅ 올바른 순서로 보내면:
받은 순서: I(0) → P(3) → B(1) → B(2)
디코더:    I(0) 디코딩 OK
           P(3) 디코딩 OK  ← B(1)보다 먼저 준비 완료
           B(1) 디코딩 OK  ← t=0, t=3 둘 다 있으니 계산 가능!
           B(2) 디코딩 OK

결론: 디코더가 미래를 계산하는 게 아니라, 인코더가 미래를 미리 봐서 계산해놓고 순서를 재배열한 것.

이것이 저장 컨테이너에서 DTS(Decoding Timestamp)와 PTS(Presentation Timestamp)가 다른 이유이기도 합니다.

쉬운 비유로 다시 정리

실제 영상에서의 배치 — GOP 구조

B-picture를 쓰는 encoder는 GOP 안에 I/P/B picture pattern을 구성할 수 있습니다. pattern은 고정적일 수도 adaptive할 수도 있고, open GOP에서는 reference가 GOP 경계를 넘을 수 있습니다.

언제 쓰는가 — 상황별 매핑

오해 풀기 — "재배열하면 디코더는 문제없는 거 아냐?"

재배열은 "순서 문제"를 해결하는 것이고, 끊김은 "패킷 손실·지연 문제"라서 완전히 별개입니다.

1. 패킷 손실 → B-frame 참조 불가 (연쇄 손상)

전송: I → P → B₁ → B₂

근데 P가 네트워크에서 유실됨 💥

디코더: B₁ 받았는데... P가 없네?
        B₁은 P를 참조해야 복원 가능한데
        → B₁ 복원 불가 → B₂도 복원 불가
        → 화면 멈춤 / 깨짐

P-picture가 손실되면 그 picture를 실제로 reference한 B/P picture가 영향을 받을 수 있습니다. 범위는 reference graph와 concealment·recovery에 달려 있습니다.

2. 패킷 지연 (Jitter)

정상:  I 도착 → P 도착 → B₁ 도착 (순서대로 빠르게)
현실:  I 도착 → P가 늦게 도착 (네트워크 혼잡)

디코더: B₁은 이미 받았는데 P가 아직 안 왔어
        재생 시간은 됐는데 복원 못 함
        → 화면 멈춤

3. WebRTC가 B-frame을 안 쓰는 "진짜" 이유 — 2가지

4. 그럼 B-frame이 없어도 끊기는 이유는?

I ← 이게 손실되면 최악
↓ 참조
P → 손실 시 이후 P들도 연쇄 손상
↓ 참조
P ...

decoder refresh picture의 일부가 손실되면 이를 reference하는 후속 picture까지 영향이 전파될 수 있습니다. PLI는 picture loss를 알리고 sender가 새 refresh picture를 만들 수 있게 하지만 즉시 I-picture 전송을 보장하는 재전송 명령은 아닙니다. (#27에서 자세히)

압축 효율 — 얼마나 차이나나

B-picture의 압축 이득에는 보편적인 고정 비율이 없습니다. source clip, encoder/preset, GOP, reference 구조를 고정하고 같은 objective/subjective quality에서 bframes=0과 B-picture 구성을 비교해야 합니다. VOD에서는 추가 reorder latency를 감수할 수 있어 이 tradeoff를 선택하기 쉽지만, live 서비스는 latency와 downstream compatibility를 함께 평가합니다.

최종 요약 — 4가지 역할

한 줄 결론

B-picture는 VOD에서는 압축 효율을 높일 수 있고, 저지연 파이프라인에서는 reorder latency와 상호운용 비용을 늘릴 수 있습니다.

두 세계를 이어붙이는 RTMP → WebRTC 같은 파이프라인을 다루신다면 #26에서 실제 PTS rollback 디버그 기록을 보시면 이 글의 모든 개념이 현장에서 어떻게 드러나는지 확인할 수 있습니다.

Bonus — B-frame은 오디오와 관계가 있나?

결론: 없음

I/P/B slice type은 비디오 codec의 개념이며 AAC·MP3·Opus는 같은 분류를 쓰지 않습니다. 다만 오디오 frame이 항상 독립적이라는 뜻은 아닙니다.

왜 오디오엔 B-frame이 없나 — 근본적 차이

데이터 성격이 완전히 달라서입니다.

비디오의 특성

• 한 프레임 = 수백만 픽셀의 2D 이미지
• 연속된 프레임끼리 거의 똑같은 경우 많음 (배경 안 바뀌고 얼굴만 조금 움직임)
• "이전 프레임 기준으로 변화량만" 표현하면 수백 배 압축 가능 → I/P/B 참조 구조가 효율적

오디오의 특성

• 1 블록 = 20ms짜리 파형 (수백~수천 개 샘플)
• 시간·주파수 영역의 중복과 masking을 이용해 압축
• codec에 따라 prediction, overlap, bit reservoir 등 frame 간 상태를 사용

오디오의 압축 방식은 따로

오디오 코덱(AAC, Opus, MP3)은 다른 기법으로 압축합니다:

• 주파수 분석 (FFT/MDCT): 파형을 주파수별로 분해
• 심리음향 모델: 사람 귀가 못 듣는 주파수 버림
• 비트 할당: 중요한 주파수에 더 많은 비트

프레임 간 참조와는 완전히 다른 차원의 기술입니다.

헷갈리는 지점: "오디오 프레임"이라는 말

오디오에서도 "프레임"이라는 단어를 씁니다:

이건 한 번에 압축/디코딩하는 단위라는 뜻이지, I/P/B 같은 참조 관계 타입이 아닙니다. 단어만 같고 의미가 다릅니다.

오디오도 약간의 "의존성"은 있음

오디오 codec에도 frame 간 상태와 의존성이 존재할 수 있습니다:

• AAC LTP (Long Term Prediction): 이전 주기성 참조
• Opus SILK 모드: 제한적 예측 코딩
• MP3 bit reservoir: 이전 frame이 남긴 main-data 공간을 뒤 frame이 사용할 수 있음

이 구조들은 H.264 B-slice와 같은 picture reference type이 아닙니다. codec latency는 frame duration뿐 아니라 algorithmic lookahead, packetization, resampling과 playout buffer를 함께 봅니다.

간접 연결점 — 립싱크(A/V Sync)

비디오와 오디오는 독립 인코딩되지만, 같이 재생돼야 하므로 연결점이 있습니다.

비디오에 B-frame이 있으면:

1. 비디오 디코딩이 미래 프레임 기다려서 지연
2. 오디오는 먼저 도착
3. 재생 플레이어가 립싱크 맞추려고 오디오를 인위적으로 지연
4. 결과적으로 전체 지연 증가

이것은 가능한 A/V sync 영향 중 하나입니다. player는 각 track timestamp와 clock mapping을 기준으로 sync하므로 실제 추가 audio buffering은 구현 정책으로 측정합니다.

한 줄 요약

관련 글: 오디오 파이프라인 해부 · B-frame 이해하기 · RTMP B-frame PTS rollback 트러블슈팅

관련 글

• #27 프레임의 모든 것 — Interlaced/I·P·B/GOP/PLI·FIR — 이 글의 직전 편. I/P/B 프레임과 GOP·PLI의 개념 기초를 다룬다.
• #28 H.264 Profile·인코더·비트레이트 — B-frame 사용 여부를 결정하는 Profile(Baseline에는 B-frame 없음)과 인코더 옵션의 실무 선택.
• #26 RTMP B-frame PTS rollback — WebRTC 변환 — B-frame의 DTS/PTS 재배열이 실제 RTMP→WebRTC 파이프라인에서 일으킨 버그 디버그 기록.
• #30 x264 실전 옵션 — ref/tune/keyint — bframes, b-pyramid 등 B-frame을 직접 제어하는 x264 인코더 옵션.
• #42 영상 압축의 본질 — I/P/B-frame/GOP/HLS — 같은 압축 개념을 HLS 세그먼트·키프레임 관점에서 다시 정리.

참고 자료

• RFC 3550 — RTP — audio/video RTP timestamp와 RTCP sender report 동기화.
• RFC 6184 — RTP Payload Format for H.264 Video — H.264 NAL 단위, packetization mode와 decoding order.
• ITU-T H.264 — Advanced video coding — I/P/B 슬라이스, 참조 픽처, POC(Picture Order Count) 등 B-frame 동작의 1차 규격.
• FFmpeg Codec Options — -bf, -tune, libx264 wrapper option.
• RFC 6716 — Opus — Opus frame duration, packet duration, prediction과 lookahead.
• ISO/IEC 11172-3 — MPEG-1 Audio — MPEG-1 Layer III frame과 bit reservoir의 규격 근거.
• ISO/IEC 14496-3 — MPEG-4 Audio (AAC) — AAC 프레임(1024 샘플)과 LTP 등 오디오 코덱 구조의 1차 규격.