블로그 목록
Media22분 읽기

ABR Ladder의 Layer B 정렬 — 화질 전환 시 키프레임 동기화

ABR 전환을 위해 rendition 간 segment boundary와 random access point를 맞추는 이유를 설명합니다. FFmpeg의 GOP·force_key_frames·scene-cut 설정은 입력 timestamp와 encoder 동작까지 함께 확인해야 하며, 최종 정렬 여부는 ffprobe와 Apple media tooling 등으로 산출물을 검증합니다.

ABRHLS키프레임 정렬Layer Bforce_key_framesFFmpegladdermediastreamvalidatorAgora Media Push
목차(37개 항목)
  1. 0. 핵심 명제 — 두 개의 정렬
  2. 1. SA 의사결정 흐름 — 한 장 요약
    1. 시나리오 인터뷰 — 고객사와 만났을 때 7가지 질문
  3. 2. ABR이 필요한 이유
    1. 시청자마다 다른 환경
    2. ABR — 같은 영상, 여러 화질
    3. Master Playlist (m3u8)
  4. 3. 화질 전환의 본질 — 시간축에서 스트림을 갈아탐
    1. 왜 P-frame으로 시작하면 안 되나
  5. 4. Layer B 정렬 위반 시나리오
    1. 시나리오 A: 정렬됨 (정상)
    2. 시나리오 B: Layer B 위반 (각 ladder가 독립적으로 인코딩됨)
    3. 시나리오 C: GOP 길이는 같은데 시작점이 다름
  6. 5. Layer B를 보장하는 4가지 방법
    1. 방법 1: 단일 인코더에서 ABR ladder 동시 출력
    2. 방법 2: `-force_key_frames`로 입력 timestamp 기준 요청
    3. 방법 3: 클라우드 트랜스코더 사용
    4. 방법 4: 프록시 인코더 + 멀티 RTMP push (커스텀 파이프라인)
  7. 6. ABR Ladder 설계 — 일반 권장값
    1. 권장 ladder (16:9 비디오)
    2. 60fps 송출 (게임/스포츠)
    3. 비트레이트 간격 — 충분히 구분 가능한 단계로
  8. 7. 검증 — 실제로 정렬됐는지 확인
    1. 각 ladder의 키프레임 timestamp 추출
    2. 한 줄 헬스체크 스크립트
    3. Apple `mediastreamvalidator`
  9. 8. 흔한 실수 패턴
    1. 실수 1: 각 화질을 독립 ffmpeg 프로세스로
    2. 실수 2: scene-cut 비활성화 누락
    3. 실수 3: VFR(가변 프레임레이트)
    4. 실수 4: GOP는 같은데 force_key_frames 누락
    5. 실수 5: 코덱/프로파일이 화질별로 다름
  10. 9. SA 체크리스트 — ABR Ladder 검증
  11. 10. 한 줄 결론
    1. 두 Layer 한눈에
  12. 관련 글
  13. 참고 자료

"720p에서 1080p로 전환할 때 화면이 깨져요." "화질을 바꾸면 잠깐 멈춰요." 이런 증상에서는 variant 간 세그먼트 경계와 랜덤 액세스 지점이 같은 미디어 시각에 정렬됐는지 먼저 확인합니다.

#37에서 키프레임과 세그먼트 경계를 다뤘다면, 이 글은 ABR ladder의 variant가 같은 콘텐츠 시각과 경계를 공유해야 하는 이유와 구현 방법을 정리합니다.

0. 핵심 명제 — 두 개의 정렬

ABR 전환을 위해 각 variant의 세그먼트 경계와 랜덤 액세스 지점을 같은 미디어 시각에 맞춘다. 고정 GOP의 정수 비율은 한 구현 방법이지 HLS의 보편 규칙은 아니다.

Layer정렬위반 시 증상
A (variant 내부)세그먼트 시작 ↔ IDR 경계목표보다 긴 세그먼트·탐색 지연 (#37)
B (variant 간)경계·timestamp·discontinuity sequence 정렬전환 지연, 디코더 재초기화, 재생 실패 가능

1. SA 의사결정 흐름 — 한 장 요약

라이브 송출 설계는 비즈니스 요구사항에서 시작해 검증으로 끝나는 단방향 결정 트리입니다.

[비즈니스 요구사항]
       │
       ▼
[허용 지연]                  ← 시청자가 몇 초까지 견딜 수 있나
       │
       ▼
[프로토콜]                   ← HLS / LL-HLS / WebRTC / RTMP
       │
       ▼
[키프레임/세그먼트 정책]      ← 플랫폼 요구 또는 자체 패키저 설정
       │
       ▼
[주기 IDR과 공통 경계 설정]
       │
       ▼
[모든 ABR 화질에 동일 GOP + 동일 시간점 키프레임]  ← Layer B
       │
       ▼
[공통 timestamp, IDR, discontinuity 정책]
       │
       ▼
[송출 체인 전체에서 일관성 유지]
       │
       ▼
[검증: ffprobe + 플랫폼 헬스 + 시청자 테스트]

시나리오 인터뷰 — 고객사와 만났을 때 7가지 질문

1. "무엇을 송출하시려는 거예요?"           → 콘텐츠 종류 (강의/스포츠/게임)
2. "시청자 지연은 얼마까지 허용 가능해요?" → 프로토콜 선택
3. "송출 대상은 어디예요?"                 → ingest·키프레임 요구
4. "몇 fps로 캡처하실 거예요?"             → keyframe interval 계산
5. "몇 가지 화질로 보내실 거예요?"         → ABR Ladder 설계
6. "인코더는 어디서 돌아가나요?"           → Agora Media Push? 자체? 클라우드 트랜스코더?
7. (설정 작성 후) "같이 ffprobe로 검증해보시죠"

이 7가지를 순서대로 묻고 답변을 채우면 자연스럽게 ladder 설정이 나옵니다.

2. ABR이 필요한 이유

시청자마다 다른 환경

5G에서 보는 사람, 지하철 와이파이, 해외 셀룰러 — 같은 라이브 방송이라도 받을 수 있는 비트레이트가 천차만별.

시청자 A (5G):       다운로드 속도 50 Mbps → 1080p 4.5 Mbps 여유
시청자 B (LTE):      8 Mbps → 720p 2.5 Mbps 가능, 1080p는 버벅
시청자 C (지하철):   1.2 Mbps → 360p 0.5 Mbps만 안정적

단일 화질로 송출하면:

  • 1080p만: 시청자 C는 끊김
  • 360p만: 시청자 A는 화질 불만

ABR — 같은 영상, 여러 화질

같은 라이브 방송을 여러 화질로 동시 인코딩해서 발행합니다. 플레이어가 네트워크 처리량·버퍼·기기 성능을 바탕으로 적절한 variant를 선택합니다.

같은 라이브 방송, 4가지 화질로 동시 인코딩:

1080p (4500 kbps):  seg1_1080.ts  seg2_1080.ts  seg3_1080.ts  ...
720p  (2500 kbps):  seg1_720.ts   seg2_720.ts   seg3_720.ts   ...
480p  (1000 kbps):  seg1_480.ts   seg2_480.ts   seg3_480.ts   ...
360p  (500 kbps):   seg1_360.ts   seg2_360.ts   seg3_360.ts   ...

시청자 디바이스의 ABR 알고리즘:

"지금 다운로드 속도 빠름 → 다음 세그먼트는 1080p로 받자"
"지금 느려짐 → 720p로 다운그레이드"
"끊겼다 회복 → 360p부터 시작해서 단계적 업그레이드"

전환 시점과 알고리즘은 플레이어마다 다르지만, HLS에서는 정렬된 세그먼트 경계가 안전한 전환점을 제공합니다.

Master Playlist (m3u8)

ABR ladder는 master playlist 한 장에 표현됩니다.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=4500000,RESOLUTION=1920x1080
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=854x480
480p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=500000,RESOLUTION=640x360
360p/index.m3u8

플레이어는 master를 먼저 받고 초기 variant를 고른 뒤, 재생 상태에 따라 다른 Media Playlist로 전환할 수 있습니다.

3. 화질 전환의 본질 — 시간축에서 스트림을 갈아탐

ABR에서 "화질을 바꾼다"는 건 시청자 디바이스가 다음 세그먼트를 다른 ladder에서 받는다는 뜻입니다.

시청자가 720p로 보는 중:
  seg1_720 → seg2_720 → seg3_720 → seg4_720
                                        ↓
시점 t=8s에서 1080p로 전환 결정:
  seg1_720 → seg2_720 → seg3_720 → seg4_720 → seg5_1080 → seg6_1080
                                                  ↑
                                          여기가 I-frame이어야
                                          디코딩 가능

전환 조건: 플레이어가 새 rendition으로 전환하는 경계에는 호환되는 독립 랜덤 액세스 지점이 필요합니다. 이 조건이 맞지 않으면 화면 깨짐이나 재생 중단이 발생할 수 있으므로 실제 대상 플레이어에서 확인합니다.

왜 P-frame으로 시작하면 안 되나

#37 Layer 4에서 다룬 것과 같은 이유. P-frame은 이전 P 또는 I를 메모리에 갖고 있어야 디코딩 가능. 시청자는 720p의 P를 갖고 있는데, 1080p의 P는 720p의 P를 참조 못 함. 해상도도 다르고 인코딩 컨텍스트도 다름.

→ 새 variant의 전환 경계에는 독립적으로 디코딩 가능한 랜덤 액세스 지점이 필요합니다.

이 지점은 variant 전반에서 같은 콘텐츠 시각에 정렬돼야 합니다.

4. Layer B 정렬 위반 시나리오

시나리오 A: 정렬됨 (정상)

시간축:  0s    2s    4s    6s    8s    10s

1080p:   I-----I-----I-----I-----I-----I
720p:    I-----I-----I-----I-----I-----I
480p:    I-----I-----I-----I-----I-----I
360p:    I-----I-----I-----I-----I-----I

→ 어느 시점이든 모든 ladder의 세그먼트 경계 = I-frame
→ ABR 전환 자유

시나리오 B: Layer B 위반 (각 ladder가 독립적으로 인코딩됨)

시간축:  0s    1s    2s    3s    4s    5s    6s

1080p:   I-----------I-----------I-----------I
720p:    I-----I-----------I-----------I
480p:    I-----------I-----I-----------I
360p:    I-----I-----------I-----I

시청자가 t=3s 시점에서 720p → 1080p 전환 시도:
  1080p의 t=3s 위치는? I-frame이 아님 (P-frame 한가운데)
  → 다음 1080p 세그먼트는 t=2 또는 t=4의 I-frame부터 시작
  → 시청자는 t=3을 못 받고 t=4까지 1초 멈춤 (또는 깨짐)

이런 패턴은 보통 각 화질을 독립된 인코더로 따로 인코딩할 때 발생합니다. 인코더마다 scene-cut 감지가 다르게 작동하거나, GOP 시작점이 어긋나거나.

시나리오 C: GOP 길이는 같은데 시작점이 다름

시간축:  0s    2s    4s    6s    8s    10s

1080p:   I-----I-----I-----I-----I-----I    (t=0부터 시작)
720p:     I-----I-----I-----I-----I-----I   (t=0.5부터 시작)

t=2 시점에서 1080p → 720p 전환:
  720p의 t=2 위치는 I-frame이 아님 (0.5초 시프트되어 있음)
  → 디코딩 실패

각 화질의 GOP 간격이 같아도 위상(phase)이 다르면 전환 경계가 어긋납니다. rendition들이 같은 미디어 timestamp에 랜덤 액세스 지점을 가져야 합니다.

5. Layer B를 보장하는 4가지 방법

방법 1: 단일 인코더에서 ABR ladder 동시 출력

단일 입력 timestamp를 공유하는 여러 출력을 구성하면 rendition 간 키프레임을 맞추기 쉽습니다. 다만 encoder와 packager가 실제로 같은 경계를 만들었는지는 산출물로 검증합니다.

# FFmpeg 단일 명령으로 4개 화질 동시 출력
ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=4[v1][v2][v3][v4]; \
                   [v1]scale=1920:1080[1080p]; \
                   [v2]scale=1280:720[720p]; \
                   [v3]scale=854:480[480p]; \
                   [v4]scale=640:360[360p]" \
  -map "[1080p]" -c:v:0 libx264 -b:v:0 4500k -g 60 -keyint_min 60 -sc_threshold 0 \
  -map "[720p]"  -c:v:1 libx264 -b:v:1 2500k -g 60 -keyint_min 60 -sc_threshold 0 \
  -map "[480p]"  -c:v:2 libx264 -b:v:2 1000k -g 60 -keyint_min 60 -sc_threshold 0 \
  -map a:0 -c:a aac -b:a 128k \
  -f hls -hls_time 2 -hls_playlist_type event \
  -master_pl_name master.m3u8 \
  -hls_segment_filename "stream_%v/seg%d.ts" \
  -var_stream_map "v:0,a:0,name:1080p v:1,a:0,name:720p v:2,a:0,name:480p v:3,a:0,name:360p" \
  master.m3u8

핵심 옵션:

  • -g 60 -keyint_min 60 모든 출력에 동일하게 → 60프레임마다 강제 I-frame
  • -sc_threshold 0 scene-cut OFF → 가변 GOP 방지
  • 단일 입력 timestamp가 모든 출력에 동기 전파됨

방법 2: -force_key_frames로 입력 timestamp 기준 요청

ffmpeg -i input.mp4 \
  -force_key_frames "expr:gte(t,n_forced*2)" \
  ... 각 ladder ...

expr:gte(t,n_forced*2)는 입력 timestamp 기준 약 2초 배수에 키프레임을 요청합니다. 프레임 시각으로 반올림되므로 각 출력의 실제 packet timestamp를 확인해야 하며, 입력 timestamp가 다시 시작되면 다른 스트림과의 공통 timeline 정렬을 별도로 처리합니다.

방법 3: 클라우드 트랜스코더 사용

관리형 트랜스코더를 사용하면 단일 입력에서 여러 rendition을 생성하고 공통 세그먼트 경계를 설정할 수 있습니다. 지원 여부와 설정 이름은 제품 문서에서 확인합니다.

Agora Media Push 한정: 한 push 작업의 출력은 지정한 destination URL로 전송됩니다. 대상 플랫폼이 ABR ladder를 생성한다면 variant 정렬은 그 플랫폼의 트랜스코딩·패키징 단계에서 처리됩니다.

방법 4: 프록시 인코더 + 멀티 RTMP push (커스텀 파이프라인)

자체 CDN이나 멀티 플랫폼 동시 송출 시 — 클라이언트 인코더에서 ladder를 만들고 각각 RTMP push.

이 경우 공통 입력 timestamp와 경계 IDR 정책을 모든 출력에 적용하고, 패키징 결과의 segment start time을 비교해야 합니다.

6. ABR Ladder 설계 — 일반 권장값

아래 값은 설계 예시입니다. 실제 값은 코덱, 프레임레이트, 콘텐츠 복잡도, 대상 기기, 플랫폼 ingest 제한과 화질 측정으로 결정합니다.

권장 ladder (16:9 비디오)

화질해상도비트레이트 (H.264)fps용도
1080p1920×10804500~6000 kbps30데스크톱/대화면
720p1280×7202500~4000 kbps30모바일 와이파이
480p854×4801000~1500 kbps30모바일 LTE
360p640×360500~750 kbps30저속 셀룰러
240p426×240250~400 kbps30비상용

비트레이트를 고정 비율로 보정하지 말고 스포츠·게임·강의 등 대표 콘텐츠로 VMAF/SSIM과 재버퍼링을 측정합니다.

60fps 송출 (게임/스포츠)

화질해상도비트레이트fps
1080p601920×10806000~9000 kbps60
720p601280×7204500~6000 kbps60
720p301280×7202500 kbps30 (저속용 폴백)

60fps에서 2초 키프레임 간격을 선택하면 120프레임입니다. 30fps rendition과 함께 쓸 때는 프레임 수가 아니라 같은 미디어 시각에 IDR이 놓이는지 확인합니다.

비트레이트 간격 — 충분히 구분 가능한 단계로

인접 rendition의 비트레이트가 지나치게 가깝다면 전환 이점이 작아집니다. 보편적인 고정 배수 규칙은 없으므로 Apple authoring spec과 실제 플레이어의 ABR 동작으로 검증합니다.

좋은 ladder:  500 → 1000 → 2500 → 4500   (각 단계 1.8~2.5배)
나쁜 ladder: 500 → 700 →  900 → 1100    (간격 너무 좁음)

mediastreamvalidator로 각 variant의 선언 peak/average bandwidth, 해상도, 세그먼트 정렬 문제를 확인하고 네트워크 shaping 테스트를 병행합니다.

7. 검증 — 실제로 정렬됐는지 확인

ladder를 인코딩한 뒤 정렬 여부는 ffprobe로 확인합니다.

각 ladder의 키프레임 timestamp 추출

# 1080p stream의 키프레임 시점만 추출
ffprobe -select_streams v:0 -show_packets \
  -show_entries packet=pts_time,flags \
  -of csv=p=0 \
  1080p/index.m3u8 \
  | grep "K" | cut -d',' -f1 > 1080p_keyframes.txt

ffprobe ... 720p/index.m3u8 ... > 720p_keyframes.txt
ffprobe ... 480p/index.m3u8 ... > 480p_keyframes.txt
ffprobe ... 360p/index.m3u8 ... > 360p_keyframes.txt

# 같은 미디어 시각에 정렬됐는지 비교
diff 1080p_keyframes.txt 720p_keyframes.txt
diff 720p_keyframes.txt 480p_keyframes.txt

한 줄 헬스체크 스크립트

#!/bin/bash
# abr-align-check.sh
LADDERS=("1080p" "720p" "480p" "360p")
REF_FILE=""

for ladder in "${LADDERS[@]}"; do
  TMP="/tmp/${ladder}_kf.txt"
  ffprobe -v error -select_streams v:0 \
    -show_packets -show_entries packet=pts_time,flags \
    -of csv=p=0 "${ladder}/index.m3u8" 2>/dev/null \
    | grep "K" | cut -d',' -f1 > "$TMP"
  
  if [ -z "$REF_FILE" ]; then
    REF_FILE="$TMP"
  else
    if ! diff -q "$REF_FILE" "$TMP" > /dev/null; then
      echo "MISALIGNED: $ladder differs from reference"
      exit 1
    fi
  fi
done
echo "OK: all ladders aligned"

Apple mediastreamvalidator

Apple 공식 도구로 HLS 스트림의 authoring 문제를 검증:

mediastreamvalidator -v https://example.com/master.m3u8

도구의 실제 진단 결과를 읽고, variant 전환은 지원 플레이어에서 별도로 재현합니다.

8. 흔한 실수 패턴

실수 1: 각 화질을 독립 ffmpeg 프로세스로

# 위험: 독립 프로세스는 timestamp·키프레임 정책이 어긋날 수 있음
ffmpeg -i input.mp4 -c:v libx264 -b:v 4500k 1080p.m3u8 &
ffmpeg -i input.mp4 -c:v libx264 -b:v 2500k 720p.m3u8 &
ffmpeg -i input.mp4 -c:v libx264 -b:v 1000k 480p.m3u8 &

각 프로세스가 자기 timestamp로 독립 인코딩 → scene-cut 위치, 첫 키프레임 시점이 어긋남.

해결: 단일 ffmpeg에서 -filter_complex split + 다중 출력.

실수 2: scene-cut 비활성화 누락

# scene-cut 정책을 출력별로 검증하지 않은 예
-c:v libx264 -g 60   # 일부 화질에선 t=1.5에 강제 I, 다른 화질에선 안 박힘

해결: 모든 ladder에 -sc_threshold 0 또는 -x264-params scenecut=0:no-scenecut.

실수 3: VFR(가변 프레임레이트)

입력이 가변 fps면 출력 timestamp도 흔들림 → ladder 간 불일치.

해결: -vsync cfr 또는 -r 30 명시로 CFR 강제.

실수 4: GOP는 같은데 force_key_frames 누락

-g 60만으로는 인코더 내부 상태(rate control 등)에 따라 약간 어긋날 수 있음.

검토 방법: -force_key_frames "expr:gte(t,n_forced*2)"로 입력 timestamp 기준 키프레임을 요청하고, 각 rendition의 실제 packet timestamp와 segment boundary를 비교합니다.

실수 5: 코덱/프로파일이 화질별로 다름

1080p: H.264 High profile
720p:  H.264 Main profile
480p:  H.264 Baseline profile

코덱·프로파일이 달라지면 플레이어가 디코더를 재구성해야 할 수 있습니다. Master Playlist의 CODECS와 대상 기기 지원 범위를 정확히 선언하고 전환을 테스트합니다.

9. SA 체크리스트 — ABR Ladder 검증

□ 1. ladder 화질 수 결정 (보통 3~5개)
□ 2. 각 화질의 해상도/peak·average bitrate 측정
□ 3. 모든 ladder 동일 framerate (다르면 60fps→30fps 폴백 명시)
□ 4. 모든 ladder의 경계 IDR이 같은 미디어 시각에 있는지 확인
□ 5. Closed GOP/CFR/scene-cut 정책을 인코더별로 명시
□ 6. 단일 인코더 / 클라우드 트랜스코더로 동시 출력
□ 7. -force_key_frames "expr:gte(t,n_forced*2)" 적용
□ 8. ffprobe로 키프레임 timestamp 일치 확인
□ 9. Apple mediastreamvalidator 통과
□ 10. 실제 시청자 시뮬레이션 — 화질 전환 시 멈춤/깨짐 없음

10. 한 줄 결론

각 variant 안에서는 세그먼트 경계를 IDR에 맞추고, variant 사이에서는 같은 콘텐츠 시각·discontinuity sequence에 경계를 맞춘다. 설정값이 아니라 생성된 HLS를 검증해야 한다.

두 Layer 한눈에

┌────────────────────────────────────────────────────────┐
│                Layer A — variant 내부 정렬              │
│   세그먼트 시작 ↔ IDR                                   │
│   "각 세그먼트가 독립적으로 디코딩 가능한가"             │
│   → #37에서 다룸                                        │
├────────────────────────────────────────────────────────┤
│                Layer B — 스트림 간 정렬                  │
│   1080p I-frame ↔ 720p I-frame ↔ 480p I-frame          │
│   "모든 ladder가 t=0,2,4,6초에 동시에 키프레임"          │
│   → 이 글의 주제                                        │
└────────────────────────────────────────────────────────┘

둘 다 만족 = 시청자는 어느 시점, 어느 화질로도 깨끗히 진입 / 전환 가능

관련 글

참고 자료

© 2026 Frank Kim. All rights reserved.