MPEG-DASH 설명, 그리고 HLS와의 비교

Chrome의 DevTools를 Netflix나 YouTube에서 열고 .mpd와 .m4s로 끝나는 파일에 대한 요청을 본 적이 있다면, MPEG-DASH가 동작하는 모습을 본 것입니다. XML 파일은 매니페스트이고, .m4s 파일은 동영상과 오디오의 짧은 fragmented-MP4 세그먼트이며, 브라우저는 일반 HTTP 위에서 이들을 실시간으로 이어 붙이고 있습니다.

DASH는 HLS의 개방형 표준 사촌입니다. Apple이 HLS를 소유하는 것처럼, MPEG/ISO 표준 기구가 DASH를 소유합니다. HLS가 .m3u8 텍스트 플레이리스트를 쓰는 곳에서 DASH는 .mpd XML 매니페스트를 씁니다. HLS가 원래 H.264를 고집한 곳에서 DASH는 코덱 선호도가 없었습니다. 두 프로토콜은 다른 출발점에서 동일한 문제를 해결하며, 2026년의 신중한 스트리밍 서비스는 둘 다 제공합니다. MPEG-DASH — Dynamic Adaptive Streaming over HTTP — 는 XML 매니페스트(.mpd)로 기술된 짧은 fMP4 세그먼트의 사슬로 동영상을 전달하고 일반 HTTP 위에서 가져오는 ISO/IEC 23009-1 표준입니다.

이 가이드는 .mpd가 실제로 무엇을 담고 있는지, DASH의 Period / AdaptationSet / Representation 계층이 어떻게 동작하는지, DRM이 어디에 들어맞는지, DASH 대 HLS의 찬반론, 그리고 이러한 스트림 중 하나를 디스크에 저장하려 할 때 무슨 일이 일어나는지 짚어봅니다.

핵심 요약 {#key-takeaways}

• MPEG-DASH는 적응형 HTTP 스트리밍을 위한 ISO 개방형 표준입니다 — ISO/IEC 23009-1. HLS는 RFC 8216입니다.
• .mpd 매니페스트는 평문이 아니라 XML입니다. Period, AdaptationSet, Representation을 기술합니다 — 시작과 모든 화질 전환에서 플레이어가 순회하는 엄격한 계층입니다.
• DASH는 설계상 코덱 비종속적입니다. H.264, H.265, VP9, AV1, AAC, Opus — 매니페스트가 코덱 문자열을 선언하고 플레이어가 디코딩합니다.
• 미디어 세그먼트는 fragmented MP4(.m4s)이며, 최신 HLS에서 쓰이는 동일한 CMAF 프래그먼트입니다. 하나의 바이트 집합이 두 프로토콜에 제공될 수 있습니다.
• DRM은 MPEG Common Encryption(CENC)을 사용해 단일 암호화 파일이 클라이언트의 복호화 모듈에 따라 Widevine, PlayReady, 또는 FairPlay와 함께 작동합니다.
• Apple 플랫폼은 DASH를 네이티브로 지원하지 않습니다. iPhone, iPad, Safari, Apple TV는 HLS를 요구합니다 — DASH 전용은 시작도 못 합니다.
• Netflix, YouTube, Disney+, Hulu, Max는 모두 DASH와 HLS를 나란히 제공합니다; Apple TV+, iTunes, Twitch는 HLS만 제공합니다.

간단한 설명

잠시 두문자어는 잊어버리십시오. 스트리밍 서비스에는 어느 쪽이든 같은 문제가 있습니다. 긴 동영상을 지저분한 연결 위에서 시청자에게 보내고, 즉시 탐색하게 하고, 재생 중간에 대역폭 변화에 적응하게 하며, 평범한 HTTP 위에서 저렴하게 하는 것입니다. 업계 전체의 해결책은 동영상을 짧은 세그먼트로 자르고, 그것들을 나열하는 매니페스트를 쓰며, 플레이어가 필요한 것을 순서대로 가져오게 하는 것입니다. HLS는 텍스트 플레이리스트로 이를 합니다. DASH는 XML 매니페스트로 이를 합니다. 일은 같고, 서류 작업이 다를 뿐입니다.

플레이어의 자리에서 보면 DASH 접근 방식은 HLS와 거의 동일하게 느껴집니다. 플레이어는 시작 시 작은 매니페스트를 가져와, 어떤 화질과 오디오 트랙이 사용 가능한지 알아내고, 대역폭과 뷰포트를 기반으로 각각 하나씩 선택한 다음, 짧은 세그먼트 스트림을 가져와 디코더에 공급합니다. 화질 전환은 세그먼트 사이에서 일어납니다. 라이브 스트림은 매니페스트가 시간에 따라 자라는 방식으로 작동합니다. 플레이어가 대상 타임스탬프를 포함하는 세그먼트로 점프하므로 탐색은 즉시입니다.

두 프로토콜 사이에서 사용자가 보는 차이는 작지만 실재합니다. HLS 플레이리스트는 평문입니다. DASH 매니페스트는 XML입니다. HLS 세그먼트는 역사적으로 .ts(MPEG-2 Transport Stream)였고 이제 보통 fMP4입니다. DASH 세그먼트는 언제나 fMP4였고 .m4s 확장자를 가졌습니다. 후원 조직도 다릅니다. Apple이 HLS를 발명하고 관리하는 반면, DASH는 MPEG와 DASH Industry Forum에서 단일 벤더가 책임지지 않는 개방형 ISO 표준으로 나왔습니다. 그에 상응하는 입문서는 HLS 상세가 .m3u8 플레이리스트가 어떻게 생겼는지 엔드 투 엔드로 다룹니다.

DASH는 실제로 어떻게 작동하나요

DASH 스트림은 XML 매니페스트와 fragmented-MP4 세그먼트 더미가 일반 HTTP 위에서 제공되는 것입니다. HLS와 같은 모양, 모든 계층에서 다른 형식.

.mpd 매니페스트

DASH 플레이어가 처음 가져오는 것은 Media Presentation Description — .mpd 입니다. HLS의 평문 플레이리스트와 달리 이것은 정의된 스키마를 가진 XML 문서입니다. 가볍게 다듬은 예시는 다음과 같습니다.

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     type="static"
     mediaPresentationDuration="PT1H30M"
     minBufferTime="PT2S"
     profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period id="0" start="PT0S">
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true"
                   startWithSAP="1" maxWidth="1920" maxHeight="1080">
      <Representation id="v1" codecs="avc1.640028"
                      width="1920" height="1080" bandwidth="5000000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v1/init.mp4"
                         media="v1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
      <Representation id="v2" codecs="avc1.4d401f"
                      width="1280" height="720" bandwidth="2800000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v2/init.mp4"
                         media="v2/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
    <AdaptationSet mimeType="audio/mp4" lang="en">
      <Representation id="a1" codecs="mp4a.40.2" bandwidth="128000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="a1/init.mp4"
                         media="a1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

모든 속성이 구체적인 의미를 갖습니다. type="static"은 이것이 VOD임을 표시합니다(라이브 스트림은 type="dynamic"). mediaPresentationDuration="PT1H30M"은 ISO 8601 기간입니다. 각 Representation은 코덱 문자열과 대역폭 예산을 운반합니다. SegmentTemplate이 마법이 일어나는 곳입니다. HLS처럼 모든 세그먼트 URL을 나열하는 대신, DASH는 매니페스트가 URL 패턴을 선언하게 하고 플레이어가 즉석에서 URL을 계산하게 합니다.

Period, AdaptationSet, Representation

매니페스트 안의 엄격한 계층이 DASH의 개념적 핵심입니다.

• Period — 타임라인의 연속된 슬라이스. 대부분의 영화는 하나의 기간입니다. 방송사는 광고나 챕터 경계를 스플라이스하기 위해 여러 기간을 사용합니다.
• AdaptationSet — 런타임에 교체 가능한 동일 콘텐츠의 대체 인코딩 모음. 일반적인 영화는 하나의 동영상 AdaptationSet, 하나 이상의 오디오 AdaptationSet(언어당 하나), 하나 이상의 자막 AdaptationSet을 가집니다.
• Representation — 단일 구체적 인코딩. 5Mbps의 1080p H.264는 Representation입니다. 2.8Mbps의 720p H.264는 다른 Representation입니다. 1.5Mbps의 720p VP9는 또 다른 Representation입니다. 플레이어는 AdaptationSet당 하나의 Representation을 고르고, 동일한 AdaptationSet 내에서 어떤 세그먼트 경계에서도 다른 것으로 교체할 수 있습니다.

이 3계층 모델은 HLS의 평평한 변형-과-세그먼트 접근법보다 더 구조화되어 있으며, 그것이 DASH가 확장성에서 이기는 이유입니다. 다중 오디오 트랙, 트릭 플레이 트랙, 썸네일 트랙, 기간별 광고 삽입이 새 매니페스트 문법을 발명하지 않고 깔끔하게 들어맞습니다.

세그먼트와 초기화

Representation의 바이트는 두 가지 종류로 옵니다. 초기화 세그먼트는 moov 박스를 담은 작은 fMP4 파일입니다 — 코덱 매개변수, 트랙 메타데이터, 디코더 구성. 플레이어는 Representation당 한 번 이를 가져옵니다. 미디어 세그먼트는 실제 오디오와 동영상이며, 각 일반적으로 2~6초 길이이고, 플레이어가 어떤 세그먼트의 시작에서도 디코딩을 시작할 수 있도록 동영상 트랙의 경우 키프레임 경계에서 잘립니다.

매니페스트가 startWithSAP="1"을 설정하면 각 세그먼트는 Stream Access Point에서 시작합니다 — DASH의 HLS EXT-X-INDEPENDENT-SEGMENTS 플래그에 상응하는 것으로, 세그먼트가 독립적으로 디코딩 가능함을 보장합니다. 그 보장 없이는 다운스트림 세그먼트가 이전 세그먼트에 의존할 수 있어 적응형 전환을 안전하지 않게 만듭니다. SegmentTemplate URL이 패턴 기반(v1/seg-$Number$.m4s)이므로 매니페스트는 90분 영화를 몇백 바이트의 XML로 기술할 수 있습니다. SegmentTimeline은 길이가 균일하지 않을 때의 대안입니다.

Common Encryption (CENC)

DASH의 DRM 이야기는 MPEG Common Encryption(CENC), ISO/IEC 23001-7을 통해 흐릅니다. CENC는 콘텐츠 키 아래에서 미디어 세그먼트 자체를 CTR 모드의 AES-128로 암호화한 다음, 어떤 DRM 시스템이 그 키를 발급할 수 있는지 선언합니다. .mpd에서 다음과 같은 ContentProtection 요소를 볼 수 있습니다.

<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc"
                   cenc:default_KID="34e5db32-8625-47cd-ba06-68fca0655a72"/>
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
  <cenc:pssh>AAAAW3Bzc2gAAAAA...</cenc:pssh>
</ContentProtection>
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
  <cenc:pssh>AAACfHBzc2gAAAAA...</cenc:pssh>
</ContentProtection>

첫 번째 블록은 CENC 아래의 기본 키 ID를 선언합니다. 두 번째는 Widevine의 UUID, 세 번째는 PlayReady의 UUID입니다. 브라우저의 Content Decryption Module은 지원하는 DRM과 일치하는 어떤 블록이든 읽고, 임베드된 PSSH(Protection System Specific Header) 데이터와 함께 서비스의 라이선스 서버에 라이선스 요청을 보내, 세그먼트를 복호화하는 데 필요한 콘텐츠 키를 받습니다. 전체 그림은 Widevine과 PlayReady가 프리미엄 스트림을 어떻게 게이팅하는지를 참조하십시오. DASH에서의 FairPlay 지원은 역사적으로 드뭅니다 — FairPlay는 HLS를 위해 설계되었습니다 — 그러나 CMAF + CBCS 암호화가 소수의 플랫폼에서 교차-DRM FairPlay-over-DASH를 기술적으로 가능하게 만들었습니다.

설계상 코덱 비종속

HLS는 원래 H.264를 우대했고(초기 Apple 기기는 다른 것을 디코딩할 수 없었음), 새 코덱을 추가하는 데 수년의 사양 절차가 필요했습니다. DASH는 결코 코덱을 고르지 않았습니다 — 매니페스트는 그저 코덱 문자열(avc1.640028, hev1.1.6.L150.B0, vp09.00.50.08, av01.0.05M.08)을 선언하고 플레이어가 디코더가 그것을 지원하는지 확인합니다. 이것이 YouTube가 Apple의 동등한 HLS 지원이 출시되기 수년 전에 DASH 위에서 AV1을 출시할 수 있었던 이유입니다. DASH 플레이어가 이해해야 하는 유일한 것이 매니페스트 계층이므로, VidMost는 .mpd를 파싱하고, SegmentTemplate URL을 순회하며, 모든 fMP4 프래그먼트를 가져오고, 안에 어떤 코덱이 있는지 신경 쓰지 않고 결과를 리먹스할 수 있습니다.

DASH 대 HLS: 솔직한 비교

DASH와 HLS는 다른 트레이드오프로 동일한 문제를 해결합니다. 어느 것도 보편적으로 더 좋지 않습니다. 다음은 실제로 중요한 축들에 걸친 각각의 논거입니다.

매니페스트 형식

DASH의 .mpd는 정의된 스키마를 가진 XML입니다 — 확장 가능(새 기능은 새 요소를 얻고, 스키마로 검증되며, 구형 플레이어는 이해 못 하는 것을 무시함)하지만 장황합니다. HLS의 .m3u8은 #EXT-X- 태그가 있는 평문으로, 한눈에 읽을 수 있고 grep하기 쉽습니다. 구조와 기계 검증에서는 DASH가 이기고, 사람의 가독성에서는 HLS가 이깁니다.

지연

둘 다 초 단위에서 수십 초의 지연으로 시작했습니다. 둘 다 저지연 확장을 출시했습니다. LL-HLS는 부분 세그먼트, 차단(blocking) 플레이리스트 재로딩, 프리로드 힌트를 사용합니다(Apple은 이전의 HTTP/2 푸시 설계를 EXT-X-PRELOAD-HINT로 대체했습니다). LL-DASH는 chunked-transfer-encoded 세그먼트와 Common Media Application Format Live 프로파일을 사용합니다. 둘 다 프로덕션에서 2~5초 글래스 투 글래스 지연을 목표로 합니다. 1초 미만 지연에는 WebRTC로 떨어집니다.

코덱 지원

DASH는 첫날부터 코덱 비종속적이었습니다. H.264, H.265, VP9, AV1, AAC, Opus, FLAC, AC-4 — 매니페스트가 코덱 문자열을 선언하고 플레이어가 결정합니다. HLS는 원래 iPhone 하드웨어가 그것을 요구했기 때문에 H.264 전용으로 시작했습니다. Apple은 지원을 꾸준히 넓혀 왔습니다. 2017년 이후 fMP4 위 H.265, 2018년 이후 Dolby Vision과 HDR10, iPhone 15 세대 이후 AV1. 현대 HLS는 H.264에 잠겨 있지 않지만, 이 프로토콜의 코덱 역사는 DASH에는 결코 없었던 지연을 갖고 있습니다.

DRM

둘 다 AES 기반 세그먼트 수준 암호화에 의존하지만, 그 위의 DRM 시스템은 다릅니다. DASH는 일반적으로 Widevine과 PlayReady와 함께 CENC를 사용합니다 — 단일 암호화 파일이 둘 다와 작동합니다. 콘텐츠 키가 동일하고, 라이선스 요청 형식만 다르기 때문입니다. HLS는 역사적으로 FairPlay Streaming(Apple 전용)을 사용하며, 점점 더 CMAF + CBCS를 통한 Widevine을 사용합니다. 서비스가 CMAF 위에 있으면 동일한 암호화 세그먼트가 두 매니페스트 유형과 세 가지 주요 DRM 시스템 모두에 제공될 수 있습니다.

Apple/iOS 지원

HLS는 iOS, iPadOS, Safari, Apple TV에서 필수입니다. DASH는 어떤 Apple 플랫폼에서도 네이티브로 지원되지 않습니다. 이것이 DASH 대 HLS 전략에서 가장 큰 단일 결정 요인입니다. Safari에서 DASH 재생은 Media Source Extensions와 shaka-player나 dash.js 같은 JavaScript 심을 통해서만 가능하며, 그것조차 모든 iOS 엣지 케이스(AirPlay, 잠금 화면 컨트롤, 픽처 인 픽처)를 다루지 않습니다. iPhone을 대상으로 하는 어떤 서비스든 HLS를 제공해야 합니다. DASH 전용은 시작도 못 합니다.

CDN 호환성과 CMAF 수렴

두 프로토콜 모두 순수 HTTP입니다. 정적 파일을 제공하는 어떤 CDN도 DASH나 HLS 스트림을 제공할 수 있습니다 — CDN 비용과 구성은 본질적으로 동일합니다. 지난 10년의 가장 중요한 발전은 DASH와 HLS가 이제 세그먼트 바이트를 공유한다는 것입니다. CMAF — Common Media Application Format, ISO/IEC 23000-19 — 는 DASH와 현대 HLS 모두를 만족시키는 fragmented-MP4 프로파일을 정의합니다. 스트리밍 서비스는 CMAF 세그먼트로 한 번 인코딩하고, 정확히 동일한 .m4s 파일을 가리키는 .mpd와 .m3u8을 모두 쓸 수 있습니다. 이것이 2026년 YouTube, Netflix, Apple, 그리고 대부분의 호스팅 동영상 제공자에서 실제로 일어나고 있는 일입니다.

2026년에 누가 무엇을 제공하나요

• Netflix — 웹, Windows, Android, 스마트 TV, 콘솔에서 DASH 주력. Safari와 iOS의 폴백용 HLS.
• YouTube — 웹과 Android에서 VP9 / AV1과 함께 DASH. iOS, Safari, AirPlay, 대부분의 TV 앱용 HLS.
• Apple TV+, iTunes Store — HLS만.
• Twitch — 라이브와 VOD 모두, 2014년 RTMP 재생 폐기 이후 HLS만.
• Disney+, Hulu, Max, Amazon Prime Video — 클라이언트에 따라 DASH 또는 HLS, 종종 두 매니페스트 아래의 동일한 CMAF 세그먼트.

HLS는 Apple 기기를 소유하고 시장의 나머지를 DASH와 공유합니다. 대안이 청중을 테이블에 남겨두는 것이기 때문에 대부분의 주요 서비스가 둘 다 지원합니다.

동영상을 저장하고 싶다면 이것이 의미하는 바

DASH가 어떻게 작동하는지 알면 실용적 다운로드 문제가 구체적이 됩니다. HLS 사용자가 스트림을 저장하려 할 때 부딪치는 모든 문제가 DASH에도 적용되며, 종종 더 나쁩니다.

• 브라우저의 다른 이름으로 저장은 .mpd만 가져옵니다. 그것이 XML 매니페스트입니다. 동영상 바이트는 전혀 담고 있지 않습니다. VLC에서 그것을 여는 것은 네트워크 세션이 여전히 유효하고 세그먼트 URL이 만료되지 않은 동안에만 작동합니다.
• DASH 세그먼트는 .m4s 파일입니다 — Representation당 하나의 init 세그먼트와 수십 또는 수백 개의 미디어 세그먼트. 각각은 단독으로는 쓸모없는 fragmented-MP4 청크입니다. 단일 재생 가능한 파일을 얻으려면 init 세그먼트와 모든 미디어 세그먼트를 순서대로 가져와 리먹스해야 합니다. (.m4s 안에 실제로 무엇이 있는지 모호하다면 컨테이너 대 코덱을 참조하십시오.)
• XML을 파싱하고, SegmentTemplate URL을 순회하며, 리먹스해야 합니다. 그것은 $Number$, $Time$, $RepresentationID$, $Bandwidth$ 자리 표시자를 이해하고, URL을 조립하며, CDN을 때리지 않고 병렬로 가져오고, 바이트를 ffmpeg나 mp4box로 공급하는 코드를 작성한다는 뜻입니다. 주말 스크립트가 아니라 진짜 소프트웨어입니다.
• 변형 선택이 중요합니다. 잘못된 Representation을 고르면 1080p 영화의 480p 사본을 다운로드한 셈입니다. 토큰도 만료됩니다 — 많은 .mpd와 세그먼트 URL은 서명되어 있고 몇 분 안에 만료됩니다.

VidMost는 이 모든 것을 처리합니다. .mpd를 파싱하고, 최고 화질 동영상 및 오디오 Representation을 고르고, 모든 세그먼트를 병렬로 다운로드하며, CMAF 프래그먼트를 단일한 깔끔한 MP4로 리먹스합니다. DRM 보호 DASH 스트림(일반적인 Widevine + PlayReady 설정)의 경우, VidMost의 내장 Widevine L3 지원은 L3 재생이 가능한 곳에서 작동합니다 — 실제 화질 상한은 서비스와 DRM 수준에 의해 설정되며, 프리미엄 플랫폼은 일반적으로 L3 스트림을 480p~720p로 제한합니다. URL을 붙여넣고, MP4를 받습니다.

흔한 함정과 오해

DASH 관련 한 줌의 혼란이 포럼 스레드에서 끊임없이 등장합니다. 정리할 가치가 있습니다.

• “MPEG-DASH는 Google의 것이다.” 그렇지 않습니다. DASH는 Adobe, Microsoft, Netflix, Qualcomm을 포함하는 컨소시엄인 DASH Industry Forum이 주도하는 MPEG / ISO 개방형 표준(ISO/IEC 23009-1)입니다. Google이 개발을 도왔고 YouTube에서 사용하지만, 단일 벤더가 그 사양을 소유하지 않습니다.
• “DASH는 더 새롭고 따라서 더 좋다.” DASH(2012)는 HLS(2009)보다 새롭지만 “더 좋은”은 플랫폼 믹스에 달려 있습니다. 청중이 iPhone에 있으면 HLS가 힘으로 이깁니다. 청중이 최대 코덱 유연성을 가진 Android와 스마트 TV에 있으면 DASH가 이깁니다. 대부분의 서비스는 둘 다 제공합니다.
• “.mpd는 동영상이다.” 아닙니다. 매니페스트입니다. 실제 동영상은 매니페스트가 참조하는 .m4s 세그먼트에 있습니다.
• “사이트가 DASH를 사용하면 내 HLS 플레이어는 재생할 수 없다.” 네이티브 플레이어의 경우 사실입니다. 그러나 shaka-player, dash.js, hls.js, video.js 같은 대부분의 현대 웹 플레이어는 Media Source Extensions를 통해 video 요소에 세그먼트를 공급함으로써 브라우저 안에서 둘 다 처리합니다.
• “DASH는 항상 DRM을 의미한다.” 그렇지 않습니다. 많은 DASH 스트림이 암호화 없이 제공됩니다. 라이브 이벤트 방송, 교육 플랫폼, 그리고 대부분의 무료 YouTube 콘텐츠가 그렇습니다. DRM은 ContentProtection 요소를 통해 선언되는 선택적 계층입니다.

마무리하며

DASH는 HLS의 평행 우주 쌍둥이입니다. 둘 다 동영상을 짧은 세그먼트로 자르고, 매니페스트에서 그것들을 기술하며, 일반 HTTP 위에서 보냅니다. 차이 — XML 대 평문, ISO 표준 대 Apple 사양, 코덱 비종속 대 코덱 역사 의존 — 는 업계 내부에서는 중요하지만 시청자에게는 거의 중요하지 않습니다. 중요한 것은 전 세계 모든 스튜디오에서 콘텐츠를 라이선스하는 스트리밍 서비스들이 이 두 프로토콜에 정착했고, 두 매니페스트 아래의 공유 CMAF 세그먼트로 점점 더 수렴하고 있다는 것입니다. .mpd 요청을 알아보고 Period / AdaptationSet / Representation 계층을 이해할 수 있게 되면, 현대 스트리밍의 이상한 동작은 더 이상 신비롭지 않습니다 — 모두 같은 루프입니다. 매니페스트 페치, 변형 선택, 세그먼트 페치, 디코드, 반복. 프로토콜 계층을 완전히 건너뛰고 그저 동영상을 저장하고 싶다면, VidMost가 HLS, MPEG-DASH, fMP4, CMAF, DRM 보호 스트림을 처리합니다.

관련 글

• 온라인 동영상은 실제로 어떻게 재생되는가 — 카메라에서 화면까지의 큰 그림 스트리밍 파이프라인.
• HLS와 M3U8이란 무엇인가? — 자매 프로토콜을 엔드 투 엔드로 다룹니다.
• 재생 중에 동영상 화질이 바뀌는 이유 — 모든 DASH와 HLS 플레이어 안의 ABR 로직.
• 동영상 컨테이너 대 코덱 — .m4s 세그먼트 안에 실제로 무엇이 들어 있는가.
• DRM 보호 콘텐츠란 무엇인가? — Widevine, PlayReady, FairPlay가 그저 저장할 수 없는 암호화된 변형을 어떻게 게이팅하는가.