Media2026-04-2122분 읽기

H.264 Profile·인코더 옵션·비트레이트의 현실 — WebRTC 운영자를 위한 코덱 현장 지침

Constrained Baseline vs Main vs High, Main/High + bframes=0이 실용 답인 이유, MTI(Mandatory To Implement) 개념, x264 threads 옵션, 하드웨어 vs 소프트웨어 인코더 (chrome://webrtc-internals 확인법), 720p@30fps = 663 Mbps 무압축을 ~300배 압축한 결과인 1.5~2.5 Mbps의 수학적 근거, 해상도/FPS별 비트레이트 표까지.

H.264ProfileBaselineMainHighMTIx264NVENCVideoToolboxMediaCodecBitrateYUVWebRTC

목차(47개 항목)

1. 클라우드 녹화 + B-frame — 실시간 전송과 저장의 이중 구조
1. 클라우드 녹화 + B-frame — 실시간 전송과 저장의 이중 구조
2. H.264 Profile 4총사
2. H.264 Profile 4총사
3. Main/High + `bframes=0` — 실용 답
3. Main/High + `bframes=0` — 실용 답
4. MTI — Mandatory To Implement
4. MTI — Mandatory To Implement
5. x264의 `threads` 옵션
5. x264의 `threads` 옵션
6. 하드웨어 vs 소프트웨어 인코더
6. 하드웨어 vs 소프트웨어 인코더
7. 720p@30fps에 왜 1.5~2.5 Mbps가 필요한가
7. 720p@30fps에 왜 1.5~2.5 Mbps가 필요한가
8. 네트워크 예산과 연결 짓기
8. 네트워크 예산과 연결 짓기
정리

앞선 글(프레임의 모든 것)에서 "WebRTC는 왜 이렇게 생겼는가"의 개념적 기초를 다뤘다면, 이 글은 실무에서 어떤 옵션을 골라야 하는가의 현장 지침입니다. 다루는 주제:

클라우드 녹화에서 B-frame이 다시 등장하는 이유
H.264 Profile 4총사 — Baseline, Constrained Baseline, Main, High
Main/High + bframes=0 — 이 조합이 왜 실용 답인가
MTI (Mandatory To Implement)란 무엇인가
x264의 threads 옵션
하드웨어 vs 소프트웨어 인코더
720p@30fps에 왜 1.5~2.5 Mbps가 필요한가 — 수학적 근거
해상도/FPS별 권장 비트레이트 표

1. 클라우드 녹화 + B-frame — 실시간 전송과 저장의 이중 구조

WebRTC 실시간 전송은 I + P만 씁니다. 그런데 같은 스트림을 녹화하고 나중에 VOD로 재생한다면 얘기가 달라집니다.

Agora/WebRTC 녹화의 두 모드

전송 경로 (실시간):
  Sender → RTP/SRTP → Receiver
          (I + P만, B 없음)

녹화 경로 (서버):
  Sender → 서버 도달 → [모드 선택]
                      │
                      ├─ ① Individual recording
                      │    (받은 스트림 그대로 파일로 저장)
                      │    → I + P 그대로
                      │
                      └─ ② Composite / Transcoded recording
                           (서버가 다시 인코딩해서 저장)
                           → 이 단계에서 B-frame 추가 가능

왜 녹화는 B-frame을 써도 되는가

녹화는 실시간 재생이 아님 — VOD로 나중에 봄
look-ahead 지연은 재생 시점에 흡수되므로 체감 영향 없음
파일 크기가 작을수록 스토리지 비용 절감
High Profile, B-frame, 긴 GOP 모두 활용 가능

실무 시사점

실시간 스트림:
  Profile: Constrained Baseline (또는 Main + bframes=0)
  GOP: 2초
  B-frame: 없음

녹화 (Composite):
  Profile: High
  GOP: 10초
  B-frame: 2~3개
  → 같은 화질에 파일 크기 30~50% 절감

즉 "전송은 저지연 제약, 저장은 압축 효율" 이라는 두 단계 구조입니다. 서버단 트랜스코딩이 두 세계를 연결합니다.

2. H.264 Profile 4총사

Profile은 "디코더가 어떤 압축 도구를 지원해야 하는가"의 계약입니다. 쉽게 말해 "이 비트스트림을 재생하려면 필요한 최소 능력치".

왜 Profile이 여러 개 있는가

디코더 성능 세대 차이 때문입니다.

2005년 피처폰:       Baseline만 가능
2010년 초기 스마트폰: Main까지 가능
2015년 중급 스마트폰: High까지 가능
2020년 이후:          대부분 High 무리 없음
Blu-ray 플레이어:     High 전제

송출측이 High로 인코딩하면 구형 디바이스는 재생 불가. 그래서 "타겟 디바이스 수준에 맞춰" Profile을 선택합니다.

Profile 스펙트럼

Profile	식별자	B-frame	CABAC	8x8 변환	주 용도
Baseline	0x42	❌ 금지	❌	❌	초기 모바일
Constrained Baseline	0x42 + constraint_set1	❌ 금지	❌	❌	WebRTC 표준
Main	0x4D	✅ 허용	✅	❌	SD 방송, 초기 YouTube
High	0x64	✅ 허용	✅	✅	Blu-ray, HD/4K VOD

CABAC: 엔트로피 코딩 고급 버전 (CAVLC 대비 10~15% 압축 향상)
8x8 변환: 더 세밀한 공간 변환 블록

고급 프로파일의 트레이드오프

Profile ↑ (Baseline → High):
  압축률        ↑  (같은 화질에 파일 작아짐)
  디코더 연산량  ↑  (저사양 기기 재생 어려움)
  지연          ↑  (B-frame 등)
  호환성        ↓  (지원 기기 줄어듦)

핵심: Profile 선택은 "지연 vs 압축률 vs 호환성" 3각 트레이드오프에서 어디에 점을 찍을 것인가의 문제입니다.

시각화

Profile 선택 매트릭스:

저지연 ◀────────────────────────────────▶ 고압축
  Constrained Baseline
  (WebRTC)
       ┃
       │    Main + bframes=0
       │    (WebRTC 고급)
       │           ┃
       │           │      Main
       │           │      (SD 방송)
       │           │            ┃
       │           │            │     High
       │           │            │     (VOD/Blu-ray)
       └───────────┴────────────┴──────▶

3. Main/High + `bframes=0` — 실용 답

"Constrained Baseline이 실시간에 안전하다"고 했는데, 실무에서는 종종 Main 또는 High + bframes=0 조합을 씁니다. 이유:

Constrained Baseline의 한계

Baseline / Constrained Baseline은:
  ❌ B-frame 금지 (이건 OK)
  ❌ CABAC 금지 (압축률 손해)
  ❌ 8x8 변환 금지 (디테일 손해)

→ "실시간 안전" 대신 "압축률 10~15% 희생"

Main/High + `bframes=0`의 이점

Main 또는 High 선택:
  ✅ CABAC 활성화 가능 (압축률 ↑)
  ✅ 8x8 변환 가능 (High only, 디테일 ↑)
  ✅ B-frame 사용 "가능"하지만 필수는 아님

bframes=0 강제:
  ✅ B-frame 생성 안 함 → 지연 제로
  
결과: 고급 프로파일의 압축 이점 취하면서 B-frame 지연만 제거

x264 설정 예시

# Main + bframes=0
ffmpeg -i input.mp4 \
  -c:v libx264 \
  -profile:v main \
  -x264-params "bframes=0:b-pyramid=none:scenecut=0" \
  -preset veryfast \
  -tune zerolatency \
  ...

# High + bframes=0 (더 높은 압축률)
ffmpeg -i input.mp4 \
  -c:v libx264 \
  -profile:v high \
  -x264-params "bframes=0:b-pyramid=none:scenecut=0" \
  ...

"그럼 WebRTC에서도 Main/High + bframes=0 쓰면 되는 거 아닌가?"

이론상 그렇습니다. 실무에서 걸리는 두 가지가 있습니다.

제약 1: 상호운용성 (interop)

WebRTC 표준 MTI = Constrained Baseline (profile-level-id=42e01f)

Chrome ↔ Safari ↔ Firefox 사이에서:
  → Constrained Baseline은 반드시 지원
  → Main/High는 구현체마다 지원 여부 다름

SDP 협상 시:
  Offer: "Main 써도 될까?"
  Answer: "난 High까진 안 되는데..."
  → Fallback to Constrained Baseline 또는 실패

제약 2: SDP profile-level-id 협상 복잡도

profile-level-id=42e01f  → Constrained Baseline, Level 3.1
profile-level-id=4d001f  → Main, Level 3.1
profile-level-id=64001f  → High, Level 3.1

양쪽 모두 같은 ID를 지원해야 협상 성공
불일치 시 통화 자체가 깨질 수 있음

결론

환경	권장 Profile
브라우저 WebRTC (Chrome ↔ Safari)	Constrained Baseline (안전)
SDK 기반 (Agora, Zoom 등, 서버-클라이언트 양쪽 통제)	Main 또는 High + `bframes=0` (압축률 이점 활용)
VOD 녹화/방송 배포	High + B-frame (최대 효율)

4. MTI — Mandatory To Implement

MTI = Mandatory To Implement ("반드시 구현해야 하는 것"). IETF/RFC 표준 용어입니다.

의미

어떤 프로토콜/표준을 "지원한다"고 주장하려면 반드시 구현해야 하는 기능 집합. MTI가 있어야 "Chrome WebRTC와 Safari WebRTC가 당연히 통신 가능"이 보장됩니다.

WebRTC의 MTI

영역	MTI 코덱
비디오	VP8, H.264 Constrained Baseline
오디오	Opus, G.711 (PCMU/PCMA)

MTI가 없다면?

Chrome: "난 VP9만 써"
Safari: "난 H.265만 써"
Firefox: "난 AV1만 써"
  ↓
서로 호환 안 됨 → 통화 불가

MTI 있음:
Chrome ↔ Safari ↔ Firefox 모두
  "최소한 VP8 + H.264 CBL + Opus는 보장"
  → 통화 성공 보장

MTI는 생태계 최소 공통분모입니다. 그래서 WebRTC에서 H.264 Constrained Baseline이 계속 기준선 역할을 합니다.

5. x264의 `threads` 옵션

x264는 오픈소스 H.264 인코더. threads 옵션은 병렬 처리에 쓸 CPU 스레드 수입니다.

옵션 값

threads=1:    단일 스레드 (느림, 결정론적 출력)
threads=6:    6개 코어 병렬
threads=auto: 시스템 코어 수 기반 자동 결정

트레이드오프

스레드 많음:
  ✅ 인코딩 속도 ↑
  ✅ 지연 ↓
  ❌ 압축 효율 살짝 ↓
     (프레임을 슬라이스로 쪼개서 병렬 처리 → 전체 최적화 손해 ~1%)

스레드 적음:
  ✅ 압축 효율 ↑ (전체 프레임 글로벌 최적화)
  ❌ 인코딩 속도 ↓
  ❌ 지연 ↑

언제 뭘 쓰나

시나리오	권장
실시간 인코딩 (WebRTC, 라이브)	`threads=auto` 또는 코어 수 - 1
저지연 스트리밍	`threads=auto`
VOD 배치 인코딩 (최대 압축)	`threads=1` 또는 `threads=2`
모바일/배터리 제약	`threads=2~4` (과열/소모 제한)

예시

# 실시간 (6코어 시스템)
ffmpeg -i input -c:v libx264 \
  -x264-params "threads=6:sliced-threads=1" \
  -preset ultrafast -tune zerolatency ...

# VOD 최대 압축
ffmpeg -i input -c:v libx264 \
  -x264-params "threads=1" \
  -preset veryslow -crf 18 ...

6. 하드웨어 vs 소프트웨어 인코더

소프트웨어 인코더

대표: x264(H.264), libvpx(VP8/VP9), libaom(AV1)
CPU로 계산
품질·설정 자유도 높음
CPU 점유율 큼 (노트북 팬, 배터리 소모)
지연 상대적으로 큼

하드웨어 인코더

전용 칩/회로로 인코딩 (GPU 내장 or 별도 유닛)
CPU 거의 안 씀
속도 매우 빠름, 지연 작음
배터리 효율 좋음
품질은 소프트웨어 대비 살짝 낮음 (같은 비트레이트 기준)
설정 자유도 제한적

플랫폼별 하드웨어 인코더

플랫폼	인코더 이름
NVIDIA GPU	NVENC
Intel CPU (내장 GPU)	Quick Sync Video (QSV)
AMD GPU	VCE / VCN
Apple (macOS/iOS)	VideoToolbox
Android	MediaCodec

브라우저 WebRTC에서 확인하는 법

방법 ① — Chrome GPU 정보 페이지
주소창에 입력: chrome://gpu
→ "Video Encode" 항목 확인
  "Hardware accelerated"이면 하드웨어 사용

방법 ② — WebRTC 통계 (실시간)
주소창에 입력: chrome://webrtc-internals
→ 통화 중 열어서 "outbound-rtp" 섹션 확인
  encoderImplementation 필드:
    - "ExternalEncoder", "NVENC", "MediaCodec" → 하드웨어
    - "libvpx", "OpenH264", "x264" → 소프트웨어

하드웨어 vs 소프트웨어 인코더 흐름도

같은 720p@30fps 실측 비교:

항목	소프트웨어 (x264)	하드웨어 (NVENC/VideoToolbox)
CPU 사용률	15~30%	<2%
인코딩 지연	~35ms	~8ms
배터리 소모	큼	작음
화질 (같은 bitrate)	조금 더 좋음	조금 낮음
설정 자유도	매우 높음	제한적

실무 포인트

Agora SDK, Zoom, Teams 같은 상용 SDK는 내부적으로 플랫폼 하드웨어 인코더를 자동 선택
iOS/Android에서는 거의 항상 하드웨어 사용 (배터리 때문)
데스크톱 브라우저는 GPU 드라이버 상태에 따라 다름
품질 이슈가 있을 때는 "하드웨어 vs 소프트웨어 인코더 차이"도 체크 대상

7. 720p@30fps에 왜 1.5~2.5 Mbps가 필요한가

🌱 처음부터 — 4단계로 유도하기

1️⃣ 해상도 → 픽셀 수

1280 × 720 = 921,600 픽셀

2️⃣ 프레임당 바이트 수 (RGB 기준)

RGB 각 채널이 1바이트(8비트)이므로 픽셀당 3바이트:

921,600 픽셀 × 3 바이트 = 2,764,800 바이트

⚠️ MB 단위 주의

1 MB = 1,000,000 바이트 (SI 단위, 마케팅/네트워크) → 2,764,800 ÷ 1,000,000 ≈ 2.76 MB

1 MB = 1,048,576 바이트 (2진법, OS 파일 시스템) → 2,764,800 ÷ 1,048,576 ≈ 2.64 MB

네트워크 비트레이트 계산은 관례상 **SI 단위 (1M = 10⁶)**를 씁니다. 아래 계산도 SI 기준.

3️⃣ 초당 데이터량

2.76 MB × 30 fps = 82.8 MB/s

4️⃣ Mbps (비트) 변환

1 바이트 = 8 비트이므로 × 8:

82.8 MB/s × 8 = 662.4 Mbps ≈ 663 Mbps

📌 핵심 공식 요약

단계	계산
픽셀 수	가로 × 세로
프레임 크기	픽셀수 × 3 (RGB)
초당 데이터	프레임크기 × fps
비트레이트	초당데이터 × 8

무압축 대역폭 계산 — RGB 기준

720p = 1280 × 720 = 921,600 픽셀
픽셀당 RGB 3바이트 = 3 byte
프레임당: 921,600 × 3 = 2,764,800 byte ≈ 2.76 MB

30fps:
  2.76 MB × 30 = 82.8 MB/s
  = 82.8 × 8 Mbps
  = 662.4 Mbps ≈ 663 Mbps

무압축 전송은 663 Mbps가 필요합니다. 일반 가정 인터넷으로는 불가능.

실제 인코더 입력은 YUV 4:2:0

위 계산은 RGB 3바이트/픽셀 기준입니다. 실제 H.264 인코더 입력은 YUV 4:2:0 색 공간을 씁니다 (사람 눈이 밝기에는 민감하고 색상에는 덜 민감하다는 점을 이용한 서브샘플링).

YUV 4:2:0 기준:
  픽셀당 평균 1.5 바이트 (Y full + UV 2×2 블록마다 각 1 샘플)
  
720p: 921,600 × 1.5 = 1,382,400 byte ≈ 1.38 MB
30fps: 1.38 × 30 = 41.4 MB/s × 8 = 331 Mbps

그래서 "무압축"의 정확한 수치는 약 331 Mbps (YUV 4:2:0) 또는 663 Mbps (RGB). H.264 인코더는 이 중 YUV 입력을 받아 압축합니다.

H.264 압축 효율

H.264는 프레임 간 중복(I→P→P 차분), 공간 중복(DCT 변환), 엔트로피 코딩(CABAC/CAVLC) 등으로 100~250배 압축이 가능합니다 (YUV 기준).

YUV 4:2:0 무압축: 331 Mbps
  ÷ 150 (일반 실시간 수준) ≈ 2.2 Mbps
  ÷ 200 (고효율 H.264 High): ≈ 1.65 Mbps

→ 움직임 적은 영상: 1.5 Mbps
→ 움직임 많은 영상: 2.5 Mbps

이것이 "720p@30fps에 1.5~2.5 Mbps"의 수학적 근거입니다.

요약: 원본 픽셀 데이터 대비 ~150배 압축. 같은 화질을 덜 먹는 H.265/AV1은 추가로 30~50% 절감.

해상도/FPS별 권장 비트레이트

해상도	FPS	권장 비트레이트	비고
360p	30	500 ~ 800 Kbps	모바일 저화질
480p	30	800 ~ 1,200 Kbps	SD
720p	30	1.5 ~ 2.5 Mbps	HD 표준
720p	60	2.5 ~ 4 Mbps	게임/스포츠
1080p	30	3 ~ 5 Mbps	Full HD
1080p	60	4.5 ~ 7.5 Mbps	Full HD 고프레임
1440p	30	6 ~ 10 Mbps	QHD
2160p (4K)	30	15 ~ 25 Mbps	UHD
2160p (4K)	60	25 ~ 40 Mbps	UHD 고프레임

한눈에 보는 해상도별 비트레이트

왜 범위인가

같은 해상도·FPS라도 콘텐츠에 따라:

움직임 적은 영상 (범위 하단):
  ─ 토킹헤드 (뉴스, 영상통화, 강의)
  ─ 정적 배경 + 얼굴만 움직임
  ─ P-frame 압축 매우 효율적 → 낮은 비트레이트 OK

움직임 많은 영상 (범위 상단):
  ─ 스포츠, 게임, 드론 촬영
  ─ 배경 전체가 계속 바뀜
  ─ P-frame 효율 낮음 → 높은 비트레이트 필요

비트레이트 부족의 증상

권장 하단 미달 (예: 720p@30fps에 500 Kbps):

인코더가 무리하게 압축하면:
  ─ 블록 노이즈 (매크로블록 경계가 각지게 보임)
  ─ 모스키토 노이즈 (에지 주변 노이즈)
  ─ 뭉개짐 / 색 번짐
  ─ 움직임 영역에서 deinition 급락

사용자 인식:
  "720p라는데 왜 이렇게 화질이 구리지?"

실무 감잡기 — 간편 계산

규칙 A — 해상도 변화:
  720p → 1080p: 픽셀 수 약 2.25배 → 비트레이트도 약 2배

규칙 B — FPS 변화:
  30fps → 60fps: 프레임 수 2배
  하지만 비트레이트는 1.5~1.8배 증가
  (완전 2배 아닌 이유: 프레임 간 유사도 덕분에 P-frame이 더 작아짐)

규칙 C — 코덱 변화:
  H.264 → H.265 (HEVC): 같은 화질에 비트레이트 ~50% 절감
  H.265 → AV1: 추가 ~30% 절감

시각화 — 비트레이트 스펙트럼

비트레이트 축 (Mbps):

0.5   1.0   1.5   2.0   3.0   5.0   10   25  (Mbps)
 │     │     │     │     │     │     │     │
 ▼     ▼     ▼     ▼     ▼     ▼     ▼     ▼
360p  480p  720p  720p  1080p 1080p 1440p 4K
30fps 30fps 30fps 60fps 30fps 60fps 30fps 30fps

        ◀─── 모바일 ──▶ ◀─── 데스크 ──▶

8. 네트워크 예산과 연결 짓기

실제 통화/스트리밍을 기획할 때 비트레이트 → 네트워크 요구치로 환산합니다.

단일 송출 (1:1 화상통화)

양방향:
  내 송출 (720p@30fps): 2 Mbps
  상대 수신:           2 Mbps
  
오디오 (Opus 양방향):
  내 송출: 32 Kbps
  수신:   32 Kbps
  
RTP/UDP/IP 헤더 오버헤드: ~10%
FEC, RTX: 추가 10~20%

총 필요 대역폭: 2 × 2 Mbps × 1.25 ≈ 5 Mbps

그룹 통화 (4명, SFU)

내 송출: 1 스트림 (2 Mbps)
내 수신: 3 스트림 (6 Mbps)

업로드: ~2.5 Mbps
다운로드: ~7.5 Mbps

라이브 방송 (1 송출 → N 수신)

송출측: 단일 스트림 (4 Mbps 정도)
CDN/SFU가 복제 → 각 시청자에게 전달

시청자 다운로드: 4 Mbps
송출측 업로드: 4 Mbps (CDN이 팬아웃)

품질 저하의 첫 증상

대역폭 부족 시 먼저 보이는 것:

① 비디오 해상도 Downscale (동적)
   720p → 540p → 360p → 240p → 오디오만

② 비트레이트 Down
   2 Mbps → 1.5 Mbps → 1 Mbps ... (같은 해상도라도 화질 저하)

③ FPS Down
   30fps → 15fps → 10fps (모션 뚝뚝 끊김)

④ 패킷 유실 증가
   모자이크, 프리즈, PLI 요청 폭주

이것이 WebRTC의 congestion control + simulcast/SVC 메커니즘이 하는 일입니다.

정리

녹화는 B-frame을 써도 됨 — 저장은 저지연 제약에서 자유로움 (VOD 재생)
H.264 Profile 4종: 호환성↔압축률 스펙트럼. WebRTC MTI는 Constrained Baseline
Main/High + bframes=0 — 고급 프로파일 이점(CABAC, 8x8 변환) 유지 + B-frame 지연 제거
MTI (Mandatory To Implement) — "반드시 구현해야" → 상호운용성 보장의 기반
x264 threads — 실시간은 병렬, VOD 최대 압축은 단일 스레드
하드웨어 인코더 — CPU 부담 적고 배터리 효율 높음. chrome://webrtc-internals에서 확인 가능
720p@30fps ≈ 1.5~2.5 Mbps — 663 Mbps 무압축을 ~300배 압축한 결과. 움직임 양에 따라 범위
비트레이트 규칙: 해상도 2배 → 비트 2배, FPS 2배 → 비트 1.5~~1.8배, 차세대 코덱 → 비트 30~~50% 절감

Profile과 비트레이트는 "타겟 디바이스 × 네트워크 × 콘텐츠 성격"의 3축 공간에서 점을 고르는 일입니다. 무조건 높은 Profile과 낮은 비트레이트가 좋은 게 아니라, 시스템 전체가 공급할 수 있는 것과 수용자가 처리할 수 있는 것의 교집합을 찾는 작업입니다.

다음에 품질 이슈 리포트를 받았다면, 이 글의 표들을 체크리스트로 써보세요. 대부분의 "화질이 이상하다" 리포트는 비트레이트 부족 + 프로파일 미스매치 + 하드웨어 인코더 실패 셋 중 하나로 귀결됩니다.