블로그 목록
Media18분 읽기

HLS와 DASH 비교 — 매니페스트, 세그먼트, DRM, 저지연

HLS와 DASH를 매니페스트 문법, 세그먼트 형식, ABR, DRM, 저지연 확장 기준으로 비교합니다. 두 프로토콜이 fMP4를 사용할 때 CMAF 미디어 세그먼트를 공유할 수 있는 조건과 Apple 플랫폼의 HLS 요구사항도 함께 설명합니다. LL-HLS는 HTTP/2 Push가 아니라 blocking playlist reload와 preload hint를 사용한다는 점을 현재 사양에 맞춰 정리했습니다.

HLSDASHCMAFfMP4MPEG-TSm3u8MPDLL-HLSLL-DASHDRMFairPlayWidevine
목차(20개 항목)
  1. 0. 핵심 명제 — 프로토콜보다 호환 조건을 먼저 본다
  2. 1. 한눈 비교 매트릭스
  3. 2. 매니페스트 — .m3u8(텍스트) vs .mpd(XML)
    1. HLS — 마스터 + 미디어 2단 구조
    2. DASH — MPD 한 파일에 전체 구조
  4. 3. 세그먼트 — MPEG-TS(.ts) vs fMP4/CMAF(.m4s)
    1. 전통 HLS: MPEG-TS
    2. fMP4 / CMAF (.m4s)
  5. 4. ABR 동작 — 화질/오디오 전환 방식의 차이
  6. 5. DRM — FairPlay vs Widevine/PlayReady, 그리고 CENC
  7. 6. 저지연 — LL-HLS vs LL-DASH (HTTP/2 Push 정정 포함)
    1. LL-HLS
    2. LL-DASH
  8. 7. CMAF — 하나의 fMP4로 HLS·DASH 둘 다
  9. 8. 플랫폼 지원 — 제품별 지원표가 기준이다
  10. 9. 실무 선택 가이드
  11. 10. 한 장 요약
  12. 11. 한 줄 결론
  13. 관련 글
  14. 참고 자료

"iOS 앱이랑 웹, 스마트TV까지 다 지원해야 하는데 HLS로 갈까요, DASH로 갈까요?" 라이브든 VOD든 스트리밍 아키텍처를 잡을 때 자주 나오는 질문입니다. 답은 기기·플레이어·코덱·DRM 지원표에 따라 달라집니다. 조건이 맞으면 CMAF 미디어를 공유하고 HLS와 DASH 매니페스트를 함께 제공할 수 있지만, 모든 서비스가 한 벌로 통합되는 것은 아닙니다.

이 글은 HLS와 DASH를 매니페스트·세그먼트·ABR·DRM·저지연 다섯 축으로 비교하고, 둘을 하나로 합친 CMAF, 그리고 실무 선택 기준까지 정리합니다. (라이브 송출 파이프라인 자체는 #49에서 다뤘으니, 여기선 "패키징 산출물" 관점에 집중합니다.)

0. 핵심 명제 — 프로토콜보다 호환 조건을 먼저 본다

HLS와 DASH는 모두 HTTP 기반 적응형 스트리밍에 쓰이지만 매니페스트 문법과 클라이언트 생태계가 다릅니다. 둘 다 호환되는 CMAF 미디어를 참조하도록 구성할 수 있습니다. 다만 코덱 프로필, 트랙 구성, 세그먼트 경계, 암호화 방식과 각 클라이언트의 지원 범위가 맞아야 같은 미디어 파일을 공유할 수 있습니다.

먼저 흔한 오해와 정정:

흔한 오해정확한 이해
HLS는 .ts, DASH는 .m4s로 포맷이 다르다HLS도 fMP4를 지원합니다. 호환 조건을 맞추면 CMAF 미디어를 공유할 수 있습니다.
DASH가 더 최신이라 더 좋다우열보다 대상 기기, 플레이어와 DRM 조합이 중요합니다. Apple의 기본 재생 경로는 HLS입니다.
HLS는 A/V를 항상 묶어 보낸다MPEG-TS로 묶을 수도 있고, 대체 오디오·자막을 별도 Rendition으로 제공할 수도 있습니다.
LL-HLS는 HTTP/2 Push로 저지연을 낸다현재 사양은 Partial Segment, Blocking Playlist Reload, Preload Hint 등을 사용합니다.
CMAF만 쓰면 DRM도 한 번에 통일된다CMAF는 미디어 형식을 정합니다. 공통 암호화 스킴과 DRM별 신호, 키 시스템 호환성은 별도로 맞춰야 합니다.

1. 한눈 비교 매트릭스

항목HLSDASH
개발/표준Apple이 개발, IETF RFC 8216로 공개MPEG / ISO·IEC 23009-1
매니페스트.m3u8 (텍스트).mpd (XML)
전통 세그먼트MPEG-TS .tsfMP4 .m4s
현대 세그먼트fMP4/CMAF .m4s(v7+)fMP4/CMAF .m4s
A/V 구성전통은 muxed, fMP4는 분리 가능AdaptationSet으로 비디오/오디오/자막 분리
Apple 기기✅ AVFoundation·Safari의 기본 경로플레이어·OS 버전·DRM에 따라 별도 구현 필요
DRMFairPlay Streaming 등CENC 기반 DRM 구성 등에 사용
코덱사양과 클라이언트 지원 범위 안에서 선택사양과 클라이언트 지원 범위 안에서 선택
선택 기준Apple 재생 경로, CDN·플레이어 지원웹·TV 플레이어, DRM·기기 지원

핵심 패턴: 본질(조각+HTTP 배달)은 같고, 문법·포맷·DRM 생태계가 다르다. 그 차이를 하나씩 봅니다.

2. 매니페스트 — .m3u8(텍스트) vs .mpd(XML)

가장 눈에 띄는 차이입니다. HLS는 한 줄씩 읽는 텍스트, DASH는 트리 구조의 XML입니다.

HLS — 마스터 + 미디어 2단 구조

# master.m3u8 (마스터 플레이리스트)
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="Korean",URI="audio/ko.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",AUDIO="aud"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2",AUDIO="aud"
720p/index.m3u8

마스터는 "어떤 화질이 있는지"의 목록(EXT-X-STREAM-INF에 BANDWIDTH/RESOLUTION/CODECS)입니다. 각 화질의 실제 세그먼트 목록은 별도 미디어 플레이리스트에 있습니다. 플레이어는 선택한 Variant Stream의 미디어 플레이리스트를 읽고 필요할 때 다른 Variant로 전환합니다.

DASH — MPD 한 파일에 전체 구조

<MPD type="dynamic" minimumUpdatePeriod="PT2S">
  <Period>
    <AdaptationSet mimeType="video/mp4" codecs="avc1.640028">
      <Representation id="1080p" bandwidth="6000000" width="1920" height="1080">
        <SegmentTemplate initialization="1080p/init.mp4"
          media="1080p/seg_$Number$.m4s" startNumber="1" duration="2" timescale="1"/>
      </Representation>
      <Representation id="720p" bandwidth="3000000" width="1280" height="720">...</Representation>
    </AdaptationSet>
    <!-- 오디오는 비디오와 완전히 분리된 AdaptationSet -->
    <AdaptationSet mimeType="audio/mp4" codecs="mp4a.40.2" lang="ko">
      <Representation id="aud" bandwidth="128000">...</Representation>
    </AdaptationSet>
  </Period>
</MPD>

DASH는 AdaptationSet과 Representation으로 선택 가능한 미디어 구성을 표현합니다. HLS도 EXT-X-MEDIA와 Variant Stream으로 대체 오디오·자막 조합을 표현할 수 있습니다. 실제 구성 난이도는 플레이어와 패키저가 해당 기능을 얼마나 잘 지원하는지에 좌우됩니다.

3. 세그먼트 — MPEG-TS(.ts) vs fMP4/CMAF(.m4s)

전통 HLS: MPEG-TS

seg_001.ts = 188바이트 고정 패킷의 연속
   PAT(PID 0x0) → PMT → Video PES(예: PID 0x100) + Audio PES(0x101)
   → 비디오·오디오가 한 파일에 섞여(muxed) 들어감
   → 4바이트 헤더 × 수많은 188B 패킷 = 오버헤드가 상대적으로 큼

fMP4 / CMAF (.m4s)

ISO BMFF(MP4) 기반의 "조각난 MP4"입니다. 초기화 세그먼트와 미디어 조각이 분리됩니다.

init.mp4 (최초 1회)          seg_001.m4s (반복)
┌──────────────┐            ┌──────────────────┐
│ ftyp         │            │ (styp)           │
│ moov         │            │ moof             │  ← 조각 메타
│  = 코덱/트랙  │            │  ├ mfhd(시퀀스)   │
│   전역 정보   │            │  └ traf          │
└──────────────┘            │     ├ tfhd(기본)  │
   재생 전 1번 로드           │     ├ tfdt(DTS)   │
                            │     └ trun(샘플)   │
                            │ mdat             │  ← 실제 NAL 데이터
                            └──────────────────┘
  • moov(init): 코덱·해상도 등 전역 정보. 재생 시작 전 한 번만 받습니다.
  • moof + mdat(각 조각): moof는 이 조각의 타임스탬프/샘플 정보, mdat는 실제 H.264/H.265 NAL.
  • 비디오·오디오를 별도 트랙/별도 파일로 두기 좋아, 분리·다국어에 유리하고 오버헤드도 작습니다.

RFC 8216은 HLS 미디어 세그먼트 형식으로 Fragmented MPEG-4를 정의합니다. 이 공통 기반 덕분에 HLS와 DASH가 호환되는 CMAF 미디어를 참조하도록 설계할 수 있습니다.

4. ABR 동작 — 화질/오디오 전환 방식의 차이

ABR(적응형 비트레이트)의 "여러 화질을 미리 만들어 두고 플레이어가 고른다"는 원리는 같지만(자세한 건 #49), 전환 절차가 다릅니다.

HLS:
  master.m3u8 → 화질별 '미디어 플레이리스트' 따로 존재
  720p→1080p 전환 = 1080p의 미디어 플레이리스트를 새로 받아야 함
  (오디오는 보통 비디오에 묶이거나 EXT-X-MEDIA 그룹으로)

DASH:
  MPD 한 방에 모든 Representation이 들어 있음
  720p→1080p 전환 = 같은 AdaptationSet 안에서 Representation만 바꿈
  비디오만 바꾸고 오디오는 그대로 유지 가능 (독립 선택)

두 방식 모두 비디오 품질과 대체 오디오를 나눠 구성할 수 있습니다. 전환 품질은 매니페스트 문법만이 아니라 키프레임 정렬, 타임라인, 플레이어 ABR 로직에 달려 있습니다.

5. DRM — FairPlay vs Widevine/PlayReady, 그리고 CENC

콘텐츠 보호가 둘을 가르는 가장 현실적인 벽입니다.

항목HLSDASH
대표 구성FairPlay Streaming 등CENC 기반 Widevine·PlayReady 등
암호화·신호EXT-X-KEY와 선택한 보호 방식CENC 보호 스킴과 ContentProtection 등
키 전달키 포맷과 DRM 시스템에 따라 다름DRM 시스템과 플레이어에 따라 다름
브라우저 APIEME를 사용하는 플레이어 구현 가능EME를 사용하는 플레이어 구현 가능
<!-- DASH CENC: 한 콘텐츠에 여러 DRM 시스템을 동시에 선언 -->
<ContentProtection schemeIdUri="urn:uuid:EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED" value="Widevine">
  <cenc:pssh>AAAA...</cenc:pssh>
</ContentProtection>
<ContentProtection schemeIdUri="urn:uuid:9A04F079-9840-4286-AB92-E65BE0885F95" value="PlayReady">...</ContentProtection>

CMAF 미디어를 공유하려면 각 대상 클라이언트와 DRM 시스템이 같은 암호화 스킴, 코덱 프로필과 트랙 구성을 지원해야 합니다. EME는 브라우저와 Content Decryption Module 사이의 API를 정의할 뿐, 특정 DRM이나 모든 조합의 상호운용성을 보장하지 않습니다. 지원표를 확인하지 않고 cbcs 하나로 통일하면 된다고 단정하면 안 됩니다.

6. 저지연 — LL-HLS vs LL-DASH (HTTP/2 Push 정정 포함)

둘 다 "세그먼트를 더 잘게 쪼개 빨리 흘린다"는 방향은 같습니다.

LL-HLS

  • Partial Segment(EXT-X-PART): 전체 세그먼트가 닫히기 전에 더 짧은 파트를 공개합니다. 파트 길이는 지연 목표와 인코더·CDN·플레이어 제약에 맞춰 정합니다.
  • Blocking Playlist Reload: 플레이어가 ?_HLS_msn=&_HLS_part=로 "다음 파트 나오면 응답해"라고 요청하면, 서버가 응답을 붙들었다가(hold) 새 파트 생기는 즉시 돌려줌 → 폴링 대기 제거.
  • Preload Hint(EXT-X-PRELOAD-HINT): 곧 나올 파트 URL을 미리 알려 선요청.
  • Rendition Report(EXT-X-RENDITION-REPORT): 다른 화질의 최신 위치를 매니페스트에 같이 실어, 화질 전환 시 추가 왕복 제거.

현재 LL-HLS 사양을 설명할 때 HTTP/2 Push를 핵심 메커니즘으로 소개하면 안 됩니다. Apple 문서와 HLS 2nd Edition 초안은 Partial Segment, Blocking Playlist Reload, Preload Hint 등을 정의합니다.

LL-DASH

<SegmentTemplate duration="2000" timescale="1000"
  availabilityTimeOffset="1.8"          <!-- 세그먼트 완성 전에 가용 표시 -->
  availabilityTimeComplete="false"/>

저지연 DASH 구성은 CMAF Chunk를 세그먼트 완료 전부터 전달하고, MPD의 가용성 정보로 플레이어가 요청 시점을 계산하게 할 수 있습니다. 위 availabilityTimeOffset 값은 예시이며 실제 값은 패키저·오리진·플레이어 설정과 일치해야 합니다.

두 방식 모두 일반 세그먼트 기반 재생보다 지연을 줄일 수 있지만, 결과를 고정된 초 단위로 보장하지는 않습니다. 인코더 버퍼, GOP, 패키저, 오리진·CDN 전달, 플레이어 버퍼를 함께 측정해야 합니다. 프로토콜 선택의 큰 그림은 #40에서 다룹니다.

7. CMAF — 하나의 fMP4로 HLS·DASH 둘 다

별도 패키징: HLS용 미디어 ─┐
                           ├─ 클라이언트 요구에 따라 산출물 분리
             DASH용 미디어 ─┘

CMAF(ISO·IEC 23000-19, 1판 2018 — 작업 2017~):
      HLS  ─┐
            ├─▶ 동일한 CMAF fMP4(.m4s) 세그먼트 한 벌 공유
      DASH ─┘   매니페스트만 .m3u8 / .mpd 둘로

CMAF는 ISO Base Media File Format에 기반한 미디어 프로필과 Fragment 구조를 정의합니다. HLS나 DASH 매니페스트 자체를 정의하지는 않습니다. 양쪽 규격과 대상 클라이언트의 공통 조건을 만족하면 두 매니페스트가 같은 CMAF 미디어를 참조할 수 있습니다.

  • 공유 가능성: 호환되는 인코딩 결과를 HLS와 DASH가 함께 참조할 수 있습니다.
  • 저장·캐시 단순화: 실제로 파일을 공유하면 중복 산출물을 줄일 수 있습니다.
  • 전제 조건: 코덱·프로필, 타임스케일, 세그먼트 경계, 트랙 구성, 암호화 스킴과 클라이언트 지원이 맞아야 합니다. 하나라도 다르면 산출물을 나눌 수 있습니다.

따라서 CMAF 미디어 + HLS·DASH 매니페스트 동시 제공은 유용한 선택지이지, 모든 범용 OTT의 고정 정답은 아닙니다.

8. 플랫폼 지원 — 제품별 지원표가 기준이다

플랫폼HLSDASH
iOS / macOS Safari✅ 기본 재생 경로OS·브라우저·플레이어·DRM 조합별 support matrix와 재생 시험으로 결정
Android 앱플레이어 구현에 따라 지원플레이어 구현에 따라 지원
데스크톱 Chrome/FirefoxMSE 기반 플레이어로 지원 가능MSE 기반 플레이어로 지원 가능
스마트TV·셋톱모델·연식·플레이어별 확인모델·연식·플레이어별 확인

Apple의 AVFoundation과 Safari 기본 재생 경로를 사용하려면 HLS가 우선 선택입니다. 반면 웹·Android·TV는 운영체제 이름만으로 지원을 판단할 수 없습니다. 실제 브라우저 버전, MSE/EME, 코덱, DRM, 플레이어 SDK와 기기 인증 범위를 표로 관리해야 합니다.

9. 실무 선택 가이드

┌─────────────────────────────────────────────────────────┐
│ Q1. 대상 기기·브라우저·TV 모델과 DRM을 정리했는가?        │
│   NO  → 지원표와 테스트 기기 목록부터 작성                │
│   YES → Q2                                               │
├─────────────────────────────────────────────────────────┤
│ Q2. Apple 기본 재생 경로가 필요한가?                      │
│   YES → HLS 산출물 포함                                   │
│   NO  → 플레이어 지원 범위에 따라 HLS/DASH 선택           │
├─────────────────────────────────────────────────────────┤
│ Q3. 양쪽 클라이언트의 공통 CMAF 조건이 확인됐는가?        │
│   YES → 공통 미디어 + HLS·DASH 매니페스트 검토            │
│   NO  → 필요한 프로필·암호화별로 산출물 분리              │
├─────────────────────────────────────────────────────────┤
│ Q4. 저지연이 필요한가?                                    │
│   YES → 전체 지연 예산을 세우고 LL-HLS/LL-DASH/WebRTC 검토│
│   NO  → 안정성·비용·호환성을 우선해 버퍼 설정             │
└─────────────────────────────────────────────────────────┘
상황권장
Apple 기본 재생 경로 필요HLS 포함
MSE/EME 기반 웹 플레이어지원 코덱·DRM을 확인해 HLS/DASH 선택
다국어·다중 자막매니페스트보다 플레이어·패키저의 실제 지원 검증
공통 CMAF 조건 충족공통 미디어 + HLS·DASH 매니페스트 검토
저지연 라이브지연 예산과 CDN·플레이어 지원에 따라 LL-HLS/LL-DASH/WebRTC 비교

10. 한 장 요약

개념한 줄
HLSApple이 개발하고 RFC 8216로 공개한 .m3u8 기반 스트리밍 프로토콜
DASHISO/IEC 23009-1의 .mpd 기반 스트리밍 표준
세그먼트전통 TS(.ts) vs fMP4(.m4s) — HLS도 fMP4 지원
ABRHLS=미디어 플레이리스트 교체 / DASH=Representation 교체(A/V 독립)
DRM매니페스트와 미디어 암호화, DRM 신호, 클라이언트 키 시스템을 함께 확인
저지연LL-HLS(EXT-X-PART+Blocking+Preload, Push는 제거됨) / LL-DASH(CMAF chunked)
CMAF호환 조건이 맞을 때 HLS·DASH가 공통 미디어를 참조할 수 있게 하는 형식
결론대상 기기·플레이어·코덱·DRM 지원표로 결정

11. 한 줄 결론

HLS와 DASH 중 하나를 이름만 보고 고르지 말고 대상 기기, 플레이어, 코덱과 DRM 조합을 먼저 검증해야 합니다. 그 공통 조건이 맞을 때 CMAF 미디어를 공유하고 HLS·DASH 매니페스트를 함께 제공하면 중복을 줄일 수 있습니다.

관련 글

참고 자료

© 2026 Frank Kim. All rights reserved.