01 — Adaptive Bitrate (ABR) 이론

이 문서가 답하는 질문: 왜 비트레이트를 바꾸나? 그리고 누가 무엇을 보고 결정하나? 핵심 한 줄: ABR은 대역폭의 변동과 버퍼의 상태라는 두 신호를 보고 매 segment마다 다음 quality를 고르는 닫힌 제어 루프다.

한 줄 답 (Pyramid Top)

ABR은 **“같은 비디오를 N개의 비트레이트로 미리 인코딩해두고, 플레이어가 매 segment마다 다음에 받을 quality를 고르게 하는 시스템”**이다. 결정의 입력은 둘뿐 — 측정된 throughput과 현재 buffer 잔량. 이 둘을 어떻게 조합하느냐로 ABR 알고리즘 가족이 갈린다.

Why — 왜 ABR이 필요한가

ABR이 없는 세상을 상상하면 답이 나온다.

핵심: 네트워크는 측정 시점과 다음 1초 사이에도 바뀐다. 한 번 고른 비트레이트로 영상 끝까지 가는 것은 지난 세기의 progressive download다.

ABR이 푸는 진짜 문제는 rebuffer 회피다. 시청자는 화질이 약간 떨어지는 것보다 영상이 멈추는 것을 압도적으로 싫어한다(다양한 QoE 연구가 일관되게 말한다).

How — 어떻게 동작하나 (3가지 알고리즘 가족)

1) Throughput-based ABR (가장 단순)

“지난 N개 segment의 다운로드 속도를 보고, 그 80~95% 안에 들어가는 가장 높은 quality를 고른다.”

Safety factor(보통 0.85~0.95)는 과소추정 마진이다. 측정치가 5Mbps여도 다음 1초에도 5Mbps라는 보장이 없으니 4.25Mbps만 쓴다.

Harmonic Mean이 산술평균보다 선호되는 이유: 다운로드 속도는 시간역수에 비례하므로, 평균을 낼 때도 역수공간에서 평균을 내야 ground truth와 일치한다. 한 segment가 비정상으로 느렸을 때 산술평균은 그 영향을 과소평가하지만, harmonic mean은 보수적으로 끌어내린다.

결정적 약점

throughput만 보면 버퍼 상태를 무시한다. 버퍼가 30초 차 있어도 throughput이 잠깐 떨어지면 즉시 quality를 낮춘다 — 불필요한 하향. 반대로 버퍼가 거의 비어 있어도 throughput이 충분하면 그대로 진행 → 위험한 stall 직전.

2) Buffer-based ABR — BBA (Buffer-Based Adaptation)

“throughput은 무시하고 buffer 잔량 하나만 본다. 버퍼가 풍부하면 화질을 올리고, 비면 내린다.”

Netflix의 Te-Yuan Huang et al. (SIGCOMM 2014) 논문이 유명하다. 핵심 아이디어:

buffer 잔량에 quality를 사상하는 함수 f(B):
- B < B_low (예: 10s)  → 가장 낮은 quality
- B > B_high (예: 50s) → 가장 높은 quality
- 그 사이 → 선형 보간

왜 이게 throughput-based보다 나은가: throughput을 안 보니 측정 노이즈에 둔감하다. 버퍼는 누적된 결과(integrate)이므로 노이즈를 자체 평균낸다. Netflix는 이걸로 rebuffer를 큰 폭 줄였다고 보고했다.

약점

• 시작 시점에는 버퍼가 비어 있으니 항상 최저 quality부터 시작 → startup delay/quality 낮음.
• 정상 상태(steady state)에서만 잘 동작 → 시작이나 시크 직후엔 throughput-based가 더 빠르다.

→ 그래서 실전 플레이어는 하이브리드를 쓴다 (시작은 throughput, steady는 buffer).

3) BOLA (Buffer Occupancy based Lyapunov Algorithm)

“buffer만 보되, 수학적으로 최적임이 증명된 함수를 쓴다.”

Spiteri, Urgaonkar, Sitaraman (INFOCOM 2016). dash.js의 기본 ABR.

매 segment에서:
  argmax over m:  V * v_m + γ * Q
                  ──────────────────
                       S_m
  s.t. V·v_m + γQ > 0  → 그렇지 않으면 가장 낮은 quality

  v_m = log(quality m의 utility/effective bitrate)
  S_m = quality m의 segment 크기
  Q   = 현재 buffer level (queue length 비유)
  V, γ = 튜닝 상수

직관: utility per byte를 buffer가 풍부할수록 더 높은 가중치로 본다. Buffer가 적으면 작은 segment(낮은 quality)를 우선, buffer가 많으면 utility 높은 (고화질) segment를 우선.

왜 최적성이 증명되나: Lyapunov optimization은 대기열 안정성과 효용 최대화를 동시에 다룬다. 평균 buffer를 안정시키면서 평균 utility를 최대화하는 함수가 위 식이다.

약점

• log utility의 quality 차이에 대한 가정이 실제 시청자 체감과 항상 일치하진 않음.
• 시작 단계는 여전히 보강 필요 — BOLA-O, BOLA-PL 같은 변종이 있음.

4) Hybrid (실전)

대부분의 production player는 단일 알고리즘을 쓰지 않는다.

• 시작 후 buffer가 어느 임계(예: 10초)에 도달하기 전 → throughput-based.
• 도달 후 → BOLA로 전환.
• shaka.dash.js, Shaka Player의 abr config가 이 패턴을 따른다.

What — 실제 플레이어가 노출하는 ABR 파라미터

Shaka Player (abr config 일부)

{
  abr: {
    enabled: true,
    defaultBandwidthEstimate: 1_000_000,  // 첫 segment까지의 가정값 (bps)
    switchInterval: 8,                     // 최소 N초마다만 quality 전환 시도
    bandwidthUpgradeTarget: 0.85,          // 측정치의 85% 안에 들어와야 상향
    bandwidthDowngradeTarget: 0.95,        // 측정치의 95%를 넘으면 하향
    restrictions: {
      minWidth: 0,
      maxWidth: Infinity,
      minHeight: 0,
      maxHeight: Infinity,
      minBandwidth: 0,
      maxBandwidth: Infinity,
    },
  },
}

• bandwidthUpgradeTarget=0.85 < bandwidthDowngradeTarget=0.95 의 히스테리시스: 같은 임계로 두 방향 결정을 하면 진동(oscillation) 발생. 두 임계를 갈라 두 갈래의 게이트를 만든다.

hls.js

{
  abrEwmaFastLive: 3.0,    // 라이브의 fast EWMA half-life (초)
  abrEwmaSlowLive: 9.0,    // 라이브의 slow EWMA half-life
  abrEwmaFastVoD: 3.0,
  abrEwmaSlowVoD: 9.0,
  abrBandWidthFactor: 0.95,
  abrBandWidthUpFactor: 0.7,
  abrMaxWithRealBitrate: false,
  startLevel: -1,          // -1이면 첫 quality 자동
  capLevelToPlayerSize: false,
}

• fast와 slow EWMA를 둘 다 들고 그 최솟값을 추정치로 쓴다 → 보수적.
• abrBandWidthUpFactor=0.7은 상향 시 30% 마진을 더 두라는 뜻 (다운로드 변동 방어).

What — QoE (Quality of Experience) 함수

ABR을 평가할 객관적 지표가 필요하다. 학계의 표준 형태:

QoE = Σ q(R_n)                          # 평균 quality
    - λ · Σ |q(R_n) - q(R_{n-1})|       # quality 변화 (smoothness 페널티)
    - μ · Σ T_rebuf                     # rebuffer 시간 페널티
    - σ · T_startup                      # startup 지연 페널티

→ μ가 가장 크다는 점이 핵심: rebuffer 1초가 quality 한 단계 낮춤보다 4~5배 더 나쁘다. 그래서 buffer-based가 throughput-based보다 일반적으로 QoE가 높다.

Pensieve (MIT, 2017)

강화학습으로 ABR 정책을 학습 — buffer/throughput history를 입력으로 받아 quality를 출력하는 신경망. 시뮬레이션에서 모든 휴리스틱을 능가했지만, production 도입은 신중: 학습 환경 ≠ 실제 네트워크 분포일 때 망가질 수 있다.

What-if — 잘못 쓰면 어떻게 깨지는가

Insight — 흥미로운 이야기

“YouTube와 Netflix는 사실 다른 ABR을 쓴다”

YouTube는 DASH를 쓰고 throughput-based에 가깝다 — short-form이 많아 시작 속도가 더 중요하다. Netflix는 HLS/DASH를 모두 지원하지만 long-form VOD에 최적화되어 buffer-based(BBA 계열)를 선호한다. 콘텐츠 종류가 ABR 정책의 weighting을 바꾼다.

“ABR은 사실 TCP의 사촌이다”

TCP의 congestion control도 같은 패턴 — 측정한 RTT/loss 신호로 cwnd를 조절한다. ABR도 throughput/buffer 신호로 quality를 조절한다. 둘 다 닫힌 제어 루프이고, 둘 다 과소추정 마진과 히스테리시스가 핵심이다. 다른 계층의 같은 문제다.

“4K 시대의 ABR은 더 어렵다”

1080p와 720p의 비트레이트 차이는 약 23배다. 4K와 1080p는 46배다. 즉 한 단계 잘못 고르면 손실이 더 크다. 그래서 4K HDR 시대에는 quality switching이 오히려 보수적으로 변하는 경향. variant ladder가 더 촘촘해지고 (예: 4K-HDR / 4K-SDR / 1440p / 1080p / 720p / 480p / 360p), 각 단계의 코덱도 다를 수 있다 (HEVC for 4K, H.264 for 1080p 이하).

한 단락 요약 + Mermaid

ABR은 throughput과 buffer라는 두 신호로 매 segment의 quality를 고르는 닫힌 제어 루프다. Throughput-based는 단순하고, Buffer-based는 노이즈에 강하고, BOLA는 수학적 최적, Hybrid는 실전. 그리고 그 모두를 평가하는 단일 잣대가 QoE인데 — rebuffer가 가장 무거운 페널티다.

→ 다음 파일 02-hls.md: 그 segment를 어떤 텍스트 매니페스트로 묶는가.