[2026] CMAF(Common Media Application Format) 완전 참조 — ISO 23000-19·fMP4·HLS+DASH·LL-저지연

Common Media Application Format(CMAF)은 MPEG이 정의한 공통 미디어 프로파일로, ISO/IEC 23000-19에 규정되어 있습니다. 핵심은 하나의 fMP4(Fragmented MP4) 바이트 스트림을 HLS(playlist)와 MPEG-DASH(manifest, ISO/IEC 23009-1)가 동시에 소비하도록, 초기화(Initialization)·세그먼트 경계(랜덤 액세스, 샘플 경계)·타임스탬프를 교차 재생(특히 ABR)에 적합하게 정렬하는 것입니다.

전제: 상용 솔루션·CDN은 CMAF ‘명목’뿐 아니라 Apple HLS Interoperability, DASH-IF 가이드, 클라이언트(사파리·크롬·STB)의 실제 지원 범위를 매트릭스로 검증해야 합니다. 본문의 명령·설정은 Illustration이며, 배포 전 반드시 대상 기기로 검증하십시오.

---

1. 프로토콜 스펙 (ISO BMFF, CMAF)

1.1 ISO BMFF(ISO/IEC 14496-12)와 fMP4

ISO/IEC 14496-12 ISO Base Media File Format(ISO BMFF, 이하 BMFF)은 MP4·fMP4의 상위 기하학을 정의합니다. 일반(‘progressive’) MP4는 단일 moov 이후 mdat에 미디어가 연속 배치되는 경우가 많고, fMP4(Fragmented MP4)는 moov에 전체를 담지 않고, moof+mdat를 반복하며 재생/전송에 적합한 조각(Fragment) 트랙을 쌓습니다.

CMAF는 이 BMFF의 흔(Movie) 구조 위에, 세그먼트 경계에서의 스위칭(대역/해상·코덱 변형)과 싱크를 보장하려는 제약(Aligned constraint)을 얹습니다. 따라서 CMAF를 이해하려면 먼저 트랙(Track), 트랙 프래그먼트(Track Fragment), Movie 프래그먼트의 관계를 BMFF 수준에서 파악하는 것이 유리합니다.

• ftyp: 브랜드(‘isom’, ‘mp41’, CMAF 관련 cmfc/cmff/cmfl·cmaf variant 등)와 호환성을 밝힙니다(파서가 거부/허용하는 기초).
• moov: 한 흔에 대한 전역 메타데이터(트랙 설명, trak·stsd 등). CMAF에서 CMAF Header가 담는 핵심 쪽박.
• moof+mdat: 미디어 프래그먼트(Media Fragment). CMAF에서 CMAF Fragment로 분리·주소지정하려는 바이트 구간의 중심이 됩니다.

fMP4는 “파일”일 수도 있고(온디맨드), HTTP로 조각을 연속 취득해 붙이는(라이브) 형태에도 쓰입니다. CMAF는 후자를 염두에 동일 byte-range가 여러 ‘인덱스’에서 참조될 수 있게 설계되었습니다.

1.2 CMAF Track(트랙) 구조

CMAF는 CMAF Track을 논리적 재생 열로 정의합니다(오디오·비디오·자막 등 흔히 Representation이나 Rendition과 1:1에 가깝게 매핑). 구현에서 중요한 것은 각 트랙이 독립적으로 디코딩 가능하도록(코덱·샘플 설명) CMAF Header에 필요한 디코더 설정이 들어가야 하고, CMAF Fragment는 시간이 단조 증가하며, 절대 시각(프로그램 시계)·RAP(랜덤 액세스 포인트) 정책이 ABR/스위칭과 충돌하지 않게 맞아야 합니다.

비디오는 H.264/AVC, H.265/HEVC 등 CMAF가 허용하는 타이밍/샘플·NAL 단위 규칙을, 오디오는 AAC(흔히 ADTS·raw 조합) 등이 DASH·HLS 양 생태계에서 동일 CMAF 조각으로 해석될 수 있어야 합니다(실서비스에서는 DASH-IF·Apple Media Profile·HLS Authoring 문서의 권고 코덱·프로파일을 함께 봅니다).

1.3 CMAF Header vs CMAF Fragment

문헌·구현에 따라 Initialization Segment / index / CMAF Header가 혼용되므로, 역할으로 고정하는 것이 안전합니다.

구성 요소	일반적 내용(개념)	HLS(대응)	DASH(대응)
CMAF Header	트랙·코덱·샘플 엔트리, 초기화에 필요한 moov 흐름	EXT-X-MAP가 가리키는 Initialization 바이트	Initialization sourceURL (Range로 부분)
CMAF Fragment	moof+mdat가 이루는 미디어 구간	EXT-X-** + 세그 URI (또는 같은 URI의 byte range)	SegmentURL / S 범위

핵심: 동일 mediabase의 CMAF Header는 한 번 캐싱·재사용하고, CMAF Fragment는 시계열로 누적됩니다. ABR이 스위칭할 때, Header가 호환(동일 moov 설명, 동일 codecId)이어야 디코더 상태를 안전 전환할 수 있습니다.

1.4 CMAF Switching Set(스위칭 세트)

Switching Set은 ABR이 같은 콘텐츠의 서로 다른 비트레이트·해상도(혹은 코덱 변형) 트랙을 세그먼트 경계에서 바꾸는 데 호환되도록 정렬(alignment)된 CMAF Fragment 시퀀스의 집합을 가리킵니다. “비슷한 길이·동기 가능한 RAP”이 없으면 스위칭이 끊기거나(깜빡임) 버퍼가 요동칩니다. 인코딩 측에서는 GOP·키프레임 정렬·세그먼트 길이(타임슬롯) 통일이 사실상 필수입니다.

Practical check:

• 세그먼트 지속시간이 마스터 인덱스(두 생태)에서 동시에 설명되는지(예: HLS TARGETDURATION·EXTINF, DASH SegmentTemplate@duration 등)
• Timeline이 MPD Period / HLS PROGRAM-DATE-TIME(사용 시)으로 엇갈리지 않는지

1.5 CMAF Selection Set(셀렉션 세트)

Selection Set은 동시에 하나를 고르는 대안을 그룹화합니다(예: 다국어 음성, 자막/캡션의 상호 배타 RENDITION). ABR(비트레이트) 스위칭이 아니라, 콘텐츠 선택(Language, Role, Accessibility)이 주 목적일 때 Switching과 개념적으로 분리됩니다. HLS EXT-X-MEDIA:TYPE이나 MPD AdaptationSet@lang / Role / ContentComponent에 1:1로 매핑되는 경우가 많습니다(단, 구현·작성기마다 그룹핑 표현이 달릴 수 있으므로 Authoring 도구의 출력 검증이 필요합니다).

---

2. HLS + DASH 통합(단일 CMAF 팩)

2.1 “단일 파일(세트)로 양쪽 지원”이란?

하나의 CMAF 미디어 바이트(Init + fMP4 fragments)는 서로 다른 메타만 있으면 됩니다.

• HLS 쪽: 마스터/미디어 m3u8이 EXT-X-MAP + 세그먼트 URL(또는 BYTERANGE)을 나열
• DASH 쪽: MPD가 BaseURL + SegmentTemplate 또는 SegmentList로 동일한 URL·Range를 기술

미디어(바이트)는 한 벌이고, “찾는 방법(인덱스)”만 HLS·DASH로 둘인 셈입니다. 이는 MPEG CMAF의 설계 취지(‘Common’)와도 일치합니다.

2.2 fMP4 세그먼트 공유

공유의 정답은 URL이 동일하다는 뜻으로 좁힐 수 있습니다.

• https://cdn.example.com/cmaf/video/720p/seg_00012.m4s 를 m3u8도, MPD도 그대로 가리킬 수 있습니다(또는 .mp4 단일 내 byte range).
• EXT-X-MAP = Init URL
• MPD Initialization@sourceURL = 동일 Init URL

이때 캐시 키는 최종 URL(+Range)이므로, 오리진·CDN이 동일 캐시를 히트시키는 것이 대역·원부하 측면에서 유리합니다.

2.3 Playlist(m3u8) vs Manifest(MPD) 차이

측면	HLS(Playlist)	DASH(MPD)
형식	텍스트(태그+URI)	XML(요소+속성)
ABR	EXT-X-STREAM-INF + variant m3u8	AdaptationSet + Representation@bandwidth
초기화	EXT-X-MAP	Initialization (Range)
지속	EXT-X-TARGETDURATION, EXTINF	SegmentTemplate@duration 등
고급/확장	Apple 방송/DRM/LL 확장(생태)	MPD @profiles, DASH-IF CMAF Profile

주의: ‘스펙상 더 강’은 DASH(구조·속성), 최다 단말 실전은 HLS(특히 Apple) 쪽 요구(태그)가 중첩됩니다. CMAF는 미디어를 공통으로 두고, 두 인덱스를 각각 만족하도록 검수가 필요합니다.

2.4 저장공간 50% 절약이 성립하는 원리

전제가 중요합니다. 과거 HLS(TS) + DASH(별도 ISM/ISMv 등) 이중 인코딩을 각기 다른 미디어 바이트로 중복 보관하던 운영에서, CMAF는 하나의 fMP4 스트리지로 둘을 커버하므로 미디어 자산(조각) 복제가 사라집니다. 그 결과 총 바이트가 거의 1/2로 가까워질 수 있습니다(반면 마스터/자막/메타는 소량 중복될 수 있어 엄밀히 50.000%는 기대하기 어렵습니다).

또 인코딩도 한 번이면, transmux 비용(컨테이너 별도)도 줄어, 스토리지+작업 모두 절감 효과가 합쳐집니다. 그러나 광고/프로그램/DRM·최소 호환 요구에 따라 여전히 변형(예: TS) 병행이 필요한 서비스도 있습니다(여기엔 50% 모델이 적용되지 않을 수 있음).

---

3. LL-HLS & LL-DASH(저지연 CMAF)

3.1 Low-Latency의 구현 골격 (CMAF 맥락)

CMAF 자체는 “짧은 조각(Short fragment) + 빨리 노출(early availability) + 빨리 읽힘(HTTP 청크) + 빨리 갱신된 인덱스”가 동시에 갖춰질 때 최단 경로를 만듭니다. HLS(Apple LL-HLS)는 Part·Preload·Blocking reload로 플레이리스트를 쪼갠 저지연 모드를, DASH(ISO 23009-1, DASH-IF LL) 는 LL MPD/Chunked 조합(프로필)으로 초저지연을 다룹니다(세부 프로파일 식별자는 버전에 민감).

2~3초는 UHD 대역/버퍼/키프레임/네트워크 지터에 의해 쉽게 무너집니다. CMAF는 포맷 정렬을 맞혀 가능하게 하고, 수치는 엔투엔 튜닝의 결과입니다.

3.2 Chunked Transfer Encoding

HTTP/1.1 Chunked는 본문을 완성 전에 스트리밍하도록 쪼개 보내, 끝바이트가 파일에 써지기 전에도(혹은 쓰는 즉시) 읽는 쪽(Edge·클라이언트·중간 캐시)이 이어받는 흐름을 엽니다. Low-Latency에서는

• 오리진→CDN→클라이언트 전 구간이 지연을 저장(버퍼링)하지 말고 전달(파이프)하도록
• 프록시가 버퍼 잠금(전체 캐싱 잠재)이 없도록
• Range/Chunked 정책이 일치하도록

튜닝하는 것이 사실상 필수입니다. 일부 CDN/구성은 작은 캐시 오브젝트·초기 청크에 최적화가 되어 있지 않은 경우가 있어, P95 지연 측정이 필요합니다.

3.3 Partial Segments(파트)와 “조기 가용”

CMAF Fragment는 비교적 짧은 시간 슬롯으로 쪼개질 수 있고, HLS 쪽은 그보다 더 잘게 쪼갠 Part(부분)를 EXT-X-PART로 누적 공개하며(개념/태그/규칙 — RFC/Apple 문서에 따름) 최신 파트만으로도 재생을 시도시키는 것이 핵심입니다(플레이어·서버·CDN이 같이 지원해야 체감). DASH·CMAF 측에도 “chunk / CMAF chunk / MPEG chunk / DASH-IF 용어”가 문맥마다 달리 쓰이므로, 구입한 솔루션/팩커의 문서를 1차 기준으로 하십시오.

주의(오해 방지): Partial Segment·Chunk·CMAF Chunk·MPEG Chunk는 문헌/제품마다 정의가 겹쳐 보이는 팀이 흔합니다. 운영에서는 (a) 컨테이너를 의미하는지 (b) HTTP 청크 전송을 의미하는지 (c) m3u8/MPD의 “조기 공개” 단위를 의미하는지 명시하십시오.

3.4 HTTP/2(및 “Push”)와의 관계

HTTP/2 Server Push는 초기 다운로드에서 객체 의존을 힌트로 묶어 보내는 데쓰일 수 있으나, 저지연 라이브의 핵심은 (i) 짧은 CMAF 프래그먼트/파트, (ii) 빨리 갱신되는 인덱스/HOLD, (iii) 오리진·엣지의 지연 억제입니다. Push는 환경(프록시/브라우저/권한)·캐싱과 상성이 까다롭고, 팀·제품에 따라 꺼두는 편이 안전한 경우가 많습니다. H3/QUIC·0-RTT·BDP·HPACK·H3 QPACK 등 전송 최적화는 별 이슈로, CMAF 인코딩/패키징과 섞이지 않도록 지표(재생/버퍼/드랍/스톨)로 분리 측정하십시오.

현실적 목표: 2~3초는 GOP(키프레임), 초기 버퍼, 끝단 지연 합이 동시에 수 초대이어야 가능합니다(특히 ABR/암호화/광고).

---

4. 실전 구현(FFmpeg, Shaka, Nginx, 브라우저)

아래 명령/설정은 형태 이해용입니다. 코덱/키프레임/캡은 요구·규정에 맞게 조정·검수하십시오(특히 광·저작권).

4.1 FFmpeg로 CMAF(유사) fMP4 래더 생성

VOD/테스트 ABR을 빠르게 만들 때, DASH fMP4 출력은 FFmpeg가 잘 지원합니다(실제 CMAF 정합·CMAF 매니페스트 동시는 팩저·2-pass authoring 권고).

예시(개념): 단일 MP4·입력을 여러 비트로 인코딩하고, DASH fMP4로 출력(세그 길이·movflags+frag 등)

# 예시(개념/환경·코덱에 맞게 수정): 1080p/720p/480p 3Rend, DASH fMP4
ffmpeg -y -i input.mp4 -filter_complex \
"[0:v]split=3[v1][v2][v3]; \
 [v1]scale=1920:1080[v1out]; [v2]scale=1280:720[v2out]; [v3]scale=854:480[v3out]" \
-map "[v1out]" -c:v:0 libx264 -b:v:0 5000k -maxrate:v:0 5500k -bufsize:v:0 11000k -g 48 -keyint_min 48 -sc_threshold 0 \
-map "[v2out]" -c:v:1 libx264 -b:v:1 3000k -maxrate:v:1 3300k -bufsize:v:1 6600k -g 48 -keyint_min 48 -sc_threshold 0 \
-map "[v3out]" -c:v:2 libx264 -b:v:2 1000k -maxrate:v:2 1100k -bufsize:v:2 2000k -g 48 -keyint_min 48 -sc_threshold 0 \
-map 0:a? -c:a aac -b:a 128k -ac 2 \
-f dash -use_timeline 1 -use_template 1 -init_seg_name "init_$RepresentationID$.m4s" -media_seg_name "seg_$Number$.$RepresentationID$.m4s" \
-seg_duration 4 -adaptation_sets "id=0,streams=v id=1,streams=a" out/manifest.mpd

설명(요지): -g·keyint_min·sc_threshold로 GOP/키프레임을 고정해 CMAF 스위칭에 가까운 경계를 만듭니다. seg_duration이 CMAF Fragment 길이에 직결됩니다(저지연이면 짧게). 다만 HLS m3u8·CMAF 정렬(교차) 검수는 FFmpeg만으로 끝내지 말고 Shaka/Bento4·엔드투엔 검사를 병행하는 편이 안전합니다.

4.2 Shaka Packager — CMAF

Shaka Packager는 CMAF·DASH·HLS 동시 패키징에 자주 쓰입니다. 입력은 packager 스트림 디스크립터로, MPD/HLS 동시 출력, CMAF 관련 프로필/태그를 제어하는 것이 일반적입니다(정확한 플래그는 출력과 릴리스에 따라 변경 — docs 확인).

형태(템플릿):

# 예시(개념): --hls / --mpd, CMAF, DRM 옵션은 릴리스·라이선스에 맞게
packager \
  in=input.mp4,stream=video,init_segment=init_video.mp4,segment_template=video_$Number$.m4s,drm_label=SD \
  in=input.mp4,stream=audio,init_segment=init_audio.mp4,segment_template=audio_$Number$.m4s,drm_label=SD \
  --hls master_playlist_output=hls.m3u8 --mpd_output manifest.mpd \
  --generate_static_live_mpd

• CMAF 정렬(Aligned)·CMAF 트랙·DRM(Widevine/PlayReady/FairPlay) 은 CLI·버전에 민감합니다(반드시 릴스 노트와 CMAF Profile·DASH-IF/Apple 체크).

4.3 Nginx로 CMAF 정적/준동적 서빙

핵심은 (1) 올바른 MIME (video/mp4, application/dash+xml, HLS m3u8), (2) Range/Chunked/캐시 헤더, (3) CORS(웹), (4) LL이면 버퍼링 억제입니다.

최소 구성(개념, http / server / location):

# mime.types에 mpd/m3u8/m4s 등 매핑을 명확히
location /cmaf/ {
    alias /var/www/cmaf/;
    add_header Access-Control-Allow-Origin *;
    add_header Cache-Control "public, max-age=31536000, immutable" always;

    # 인덱스(playlist/mpd)는 짧은 TTL(라이브)
    location ~* \.(m3u8|mpd)$ {
        add_header Cache-Control "public, max-age=1, s-maxage=1" always;
    }

    # 작은 CMAF 파트(저지연) 캐시 — CDN과 정책을 맞출 것
    types {
        application/dash+xml mpd;
        application/vnd.apple.mpegurl m3u8;
        video/mp4 m4s mp4;
    }
}

• LL-HLS/LL-DASH는 Cache-Control: no-store / 짧은 s-maxage / stale-while-revalidate / Vary: Accept 등 혼합이 흔합니다(특히 m3u8/MPD). .m4s(셈) 쪽은 길이·세그에 롱캐시 + 콘텐츠 해시 키 조합이 전형적입니다.

4.4 브라우저: hls.js + dash.js

• HLS( fMP4 / CMAF ): hls.js·video.js contrib-hls 등. Low-Latency 모드·fMP4·CMAF·#EXT 지원 매트릭스 확인.
• DASH( CMAF ): dash.js Protection (DRM)·ABR·CMAF 프로파일 (버전) 확인.

Video Element + MSE 공통 패턴(개념):

<video id="v" controls playsinline></video>
<script type="module">
  const video = document.getElementById("v");
  // HLS: new Hls(); hls.loadSource("master.m3u8"); hls.attachMedia(video);
  // DASH: dashjs.MediaPlayer().create().initialize(video, "manifest.mpd", true);
</script>

운영: Safari는 네이티브 HLS, Chromium은 MSE+JS·CORS·CSP·HEVC(플랫폼)·EME(DRM) 교차 이슈가 많습니다(특히 CMAF+DRM). hls.js·dash.js 릴스 노트의 CMAF/LL/CMCD·CORS·Abr·Switches·MSE 제약을 우선 확인하십시오.

---

5. 최적화(프래그먼트·청크·CDN·대역)

5.1 Fragment 크기 튜닝

• 짧을수록 지연↓, HTTP 오버헤드/인덱스 갱신 부하↑ (HLS/MPD 횟수↑).
• GOP(키프레임) = RAP — Fragment 경계와 정렬 불가시 ABR/스위칭 품질 저하.
• 4~6초: 전통 ABR, 1~2초: 저지연 시도(환경·코덱·B-프레임·참조 구조 주의).
• Audio lead/lap (비디오·오디오 싱크) — CMAF·DASH-IF/Apple 가이드·ffprobe/비재생 로그로 검수.

5.2 Chunked Encoding(전송) 설정

• 오리진에서 Nginx/Node/Go/Envoy·끄는지 / 꺼야 하는지(프록시)
• TLS 세션·0-RTT(보안/정책)·Brotli vs gzip(텍스트 인덱스)
• H2/H3 멀티플렉싱 — m3u8+세그 동시성 이득/손 측정
• 엣지( CDN ) Early-Hints 103, Mid-Stream Cache — LL·CMAF 조합은 지역·상품에 편차 큼

5.3 CDN 캐싱 전략

• Init(moov): 긴 TTL, 바이트 불변 가정(키 로테이션/DRM·KID 바뀌면 재개산)
• 세그(.m4s): 콘텐츠 해시 URL 또는 버전 경로 — 캐시 키 충돌 방지
• m3u8/MPD: 짧은 TTL, Etag/Last-Modified 일관 — LL은 stale-while-revalidate·SWR 혼합 흔함
• Range: Vary, Accept-Encoding·캐시 동작(원사)·끼어들기(광·CMS) 주의
• 지역( PoP ) 편차 — P95, MOS(주관), 스톨(오브젝티브) 동시를 KPI로

5.4 대역폭 절약(압축/적응·CMCD)

• ABR 래더/Codec(AVC/HEVC/AV1)·초해상(SSR)·Per-title 인코딩 — CMAF는 같은 컨테이너로 Rendition 확장이 쉬움
• 퍼널(오디오 전용, 비디오 끄기), 자막 WebVTT·CMAF 텍스트 트랙 — 오디오 대역 절감과 UI 효율 균형
• CDNi / Open Caching — 캐시 핵심 — CMAF URL 안정이 히트율에 직행
• CMCD(Client–CDN Measurement) (측정/디버그 메타) — 세그·Rendition 식별·A/B·이상 구간 분석에 유효
• QUIC(UDP) / BDP / AFR(오토) AB — CMAF 미디어 동일 상태에서 전송만 최적화하는 축 분리

---

6. 트러블슈팅(현장 견해)

• A/V 싱크 드리프트: edit lists / 타임스탬프 / 초기화 재사용(잘못된 MAP) — ffprobe·DASH-IF 검사기·작성기 로그를 병행.
• ABR 떨림(과도한 전환): ABR 알고리즘(Throughput/Buffer) hls.js·dash.js API setABRCustomRule / BOLA 등 — CMAF 문제가 아닐 수 있음(단, 정렬 나쁨이면 원인).
• CORS/EME/HTTPS: Eme MediaKeys / Widevine(Chrome) / PlayReady(Edge) / FairPlay(Safari) 분기 — CMAF 초기화+세그 모두 인증·CORS 통과해야 함.
• 캐시 오염: 동일 URL 다른 바이트 (배포 버그) — 해시/버전 필수.
• LL 효과 없음: GOP/세그/파트/플레이리스트 주기/Edge 버퍼 동시 점검 — 한 축만 짧게 해도 끊김 만 늘 수 있음.

---

7. 정리 (참고 표준·문서)

• CMAF: ISO/IEC 23000-19
• ISO BMFF: ISO/IEC 14496-12
• DASH(매니페스트): ISO/IEC 23009-1
• HLS(인덱스): RFC 8216 — fMP4·EXT-X-MAP·LL 확장(생태) 병기
• 엔지니어 실무(비표준) 가이드: DASH-IF, Apple HLS Authoring, Shaka/FFmpeg 문서, CDN 벤더 베스트 프랙티스 — 최신 개정 확인을 권장합니다

CMAF는 훌륭한 ‘미디어 공통 층’이나, 성공은 인덱스(HLS·DASH)·전송(HTTP)·DRM·광/메타가 하나의 시스템으로 맞춰질 때 완성됩니다. 대규모 전에는 Rendition·Region·OS·브라우저 행렬 테스트로 E2E 지연·캐시 히트·스톨을 수치로 닫으십시오.

---

부록: 용어 소거(팀 합의용)

• CMAF Media Object / Segment / Address / Chunks(문헌) — 제품/문서 정의를 우선하십시오(번역/약어 혼동 방지).
• CMAF Switching vs DASH Period switch — 이름은 비슷해도 레이어(컨테이너 vs 매니페스트) 다릅니다.