H.264 Profile, Encoder, Bitrate — WebRTC 운영 기준

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

녹화 경로 (서버):
  Sender → 서버 도달 → [모드 선택]
                      │
                      ├─ ① Individual recording
                      │    (받은 스트림 그대로 파일로 저장)
                      │    → I + P 그대로
                      │
                      └─ ② Composite / Transcoded recording
                           (서버가 다시 인코딩해서 저장)
                           → encoder 설정과 output profile이 허용하면 B-picture 사용 가능

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

녹화 (Composite):
  Profile: High
  GOP: 10초
  B-frame: 2~3개
  → 파일 크기 차이는 source·quality target·encoder로 실측

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

Profile ↑ (Baseline → High):
  압축률        ↑  (같은 화질에 파일 작아짐)
  디코더 연산량  ↑  (저사양 기기 재생 어려움)
  지연          profile 자체보다 실제로 선택한 B-picture·lookahead·buffer 설정에 좌우
  호환성        ↓  (지원 기기 줄어듦)

Profile 선택 매트릭스:

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

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

→ 단순한 tool subset이어서 같은 quality target에서 bitrate가 늘 수 있으나 비율은 고정되지 않음

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

bframes=0 강제:
  ✅ B-picture reorder delay 제거
  
결과: 고급 profile의 일부 coding tool을 유지하면서 B-picture reorder delay를 제거. lookahead·VBV·threading·capture buffer까지 0이 되는 것은 아님

# 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 H.264 MTI 예 = Constrained Baseline (`profile-level-id`의 level byte는 endpoint capability에 따라 달라짐)

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

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

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

offer/answer가 합의한 profile·level·packetization mode와 실제 bitstream이 일치해야 함
합의 가능한 codec이 없으면 media negotiation이 실패할 수 있음

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

MTI 있음:
표준 준수 WebRTC endpoint는
  "최소한 VP8 + H.264 CBL + Opus/PCMA/PCMU 구현"
  → codec 협상의 공통 기반 제공

threads=1:    단일 스레드 (느림, 결정론적 출력)
threads=6:    6개 코어 병렬
threads=0 또는 option 생략: x264가 자동 결정

스레드 많음:
  처리량은 늘 수 있지만 frame-threading은 frame delay를 늘릴 수 있음
  sliced threading을 쓰면 frame delay를 줄이는 대신 compression efficiency가 달라질 수 있음

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

# 실시간 (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 ...

방법 ① — Chrome GPU 정보 페이지
주소창에 입력: chrome://gpu
→ "Video Encode" capability 확인. 현재 통화가 그 encoder를 사용한다는 직접 증거는 아님

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

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

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

YUV 4:2:0 무압축: 약 331 Mbps
  → 이 값은 memory bandwidth 기준
  → 필요한 compressed bitrate는 해상도만이 아니라 content·frame rate·quality target·encoder 설정으로 시험

같은 해상도·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 — codec 변화:
  codec 이름만으로 절감률을 고정하지 않음
  동일 source·quality metric·latency/preset 조건에서 비교

비트레이트 축 (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

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

양방향:
  내 송출 (720p@30fps): 2 Mbps
  상대 수신:           2 Mbps
  
오디오 (Opus 양방향):
  내 송출: 32 Kbps
  수신:   32 Kbps
  
RTP/UDP/IP·SRTP·extension overhead는 평균 payload 크기로 계산
FEC/RTX overhead는 loss와 복구 정책에 따라 측정

각 방향의 send/receive target에 여유율을 더해 access link를 따로 산정

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

업로드와 다운로드를 합산하지 않고 각각 산정
simulcast/SVC layer와 실제 subscription 수를 반영

송출측: 단일 스트림 (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 요청 폭주