M3U8이란 무엇인가? HLS 프로토콜과 .m3u8 플레이리스트 완전 가이드

M3U8은 HLS(HTTP Live Streaming) 프로토콜이 사용하는 UTF-8 텍스트 플레이리스트입니다. 파일 자체에는 영상 프레임이 들어 있지 않으며, 동영상 세그먼트(.ts 또는 .m4s)의 URL, 각 세그먼트의 길이, 사용 가능한 비트레이트 변형 목록을 담은 매니페스트입니다. 플레이어는 .m3u8을 읽어 세그먼트를 순서대로 가져온 뒤 실시간으로 이어 붙여 재생 가능한 동영상 스트림을 만듭니다 — 이것이 YouTube, Netflix, Twitch, Apple TV+ 등 2026년 대부분의 주요 스트리밍 서비스를 떠받치는 핵심 메커니즘입니다.

스트리밍 사이트에서 동영상을 저장하려다가 깔끔한 .mp4 하나가 아니라 수백 개의 작은 .ts 파일이 남게 된 적 있나요? 아니면 브라우저의 Network 탭을 열고 깨끗한 다운로드 URL을 기대했는데 끝없이 흘러들어오는 2초 청크들을 발견한 적이 있나요? 잘못한 게 아닙니다. HLS — 현대 웹의 스트리밍 동영상 대부분을 전달하는 프로토콜 — 를 보고 있었던 것이고, HLS는 동영상을 단일 파일로 보내지 않습니다. 레시피와 부품으로 보냅니다.

레시피는 .m3u8 플레이리스트라 부르는 작은 텍스트 파일입니다. 부품은 짧고 독립적으로 디코딩 가능한 동영상 세그먼트들로, 플레이어가 즉석에서 이어 붙입니다. HLS는 Apple이 2009년 초대 iPhone을 위해 만들고 RFC 8216으로 표준화한 프로토콜로, 오늘날 거의 모든 주요 브라우저, 모바일 기기, TV에서 기본 지원됩니다.

이 가이드는 .m3u8이 실제로 무엇을 담고 있는지, 왜 스트리밍 서비스들이 이 설계를 선택했는지, .ts와 fMP4 세그먼트가 어떻게 함께 작동하는지, 2026년에 어떤 플랫폼이 HLS를 쓰는지, 그리고 이러한 스트림 중 하나를 디스크에 저장하려 할 때 무슨 일이 일어나는지 짚어봅니다.

핵심 요약 {#key-takeaways}

• HLS는 파일 형식이 아니라 스트리밍 프로토콜입니다. 일반 HTTP 위에서 동영상을 플레이리스트(.m3u8)와 짧은 세그먼트(.ts 또는 fragmented MP4)로 전달합니다.
• .m3u8은 동영상이 아니라 인덱스입니다. .m3u8 파일만 저장하면 재료 없는 레시피만 얻게 됩니다.
• Apple은 2009년 iPhone을 위해 HLS를 만들었고 2017년 RFC 8216으로 표준화되었습니다. 이제 iOS/Safari에서 필수이고 다른 곳에서도 거의 보편적으로 지원됩니다.
• 세그먼트는 동영상 2~10초 분량입니다 — 그 사이에서 화질을 전환할 만큼 짧으면서, HTTP 오버헤드를 합리적으로 유지할 만큼 깁니다.
• 마스터 플레이리스트는 변형을 나열하고, 미디어 플레이리스트는 세그먼트를 나열합니다. 플레이어는 마스터를 읽고 변형을 고른 뒤, 그 변형의 미디어 플레이리스트를 로드합니다.
• .ts 세그먼트는 fragmented MP4(CMAF)로 대체되고 있어, 동일한 파일이 하나의 원본에서 HLS와 DASH 플레이어 모두에 제공될 수 있습니다.
• 대부분의 현대 스트리밍은 HLS 또는 DASH 위에 있으며, 종종 둘 다 동시에 — YouTube, Netflix, Disney+, Twitch, Apple TV+, Cloudflare Stream 등이 포함됩니다.

M3U8 vs MP4: 핵심 차이 비교

많은 사람이 .m3u8을 처음 마주치는 순간은 동영상을 다운로드하려다 익숙한 .mp4 대신 작은 텍스트 파일을 손에 쥐었을 때입니다. 두 형식은 같은 워크플로에서 함께 등장하지만 본질적으로 다른 종류입니다 — 하나는 플레이리스트(매니페스트), 다른 하나는 컨테이너입니다. 일상에서 가장 많이 검색되는 차이를 한 표로 정리했습니다.

한 줄 요약: M3U8은 “목차”, MP4는 “완성된 파일”. 온라인 시청 시 브라우저는 M3U8 매니페스트를 받아 필요한 만큼 세그먼트를 끌어옵니다. 오프라인으로 장기 보관하거나 친구에게 공유하려면 결국 세그먼트를 다시 MP4로 합치는 과정을 거치게 됩니다.

간단한 설명

잠시 프로토콜은 잊어버리십시오. 신뢰할 수 없는 인터넷 위에서 완성된 영화를 전 세계 시청자에게 보내야 하는 감독을 상상해보십시오. 하나의 거대한 MP4를 보내는 것은 시작도 못 합니다. 시청자의 연결이 다운로드 중간에 끊기면 처음으로 돌아가야 하고, 재다운로드 없이 화질을 전환할 방법이 없습니다. 그래서 감독은 영화를 수백 개의 6초 클립으로 자르고 “클립 001을 재생한 다음 002, 그다음 003…”이라고 말하는 번호가 매겨진 플레이리스트를 씁니다. 시청자의 플레이어는 플레이리스트를 다운로드하고 처음 몇 개 클립을 가져온 뒤, 나머지가 뒤에서 흘러들어오는 동안 재생을 시작합니다. 연결이 느려지면 플레이어는 한 프레임도 놓치지 않고 다음 클립의 더 낮은 화질 버전으로 전환합니다.

한 문장으로 본 HLS: 짧은 클립으로 잘린 영화 + 플레이어에게 다음 어떤 클립을 재생할지 알려주는 .m3u8 플레이리스트 파일.

시청자의 자리에서 보면 이 설계는 많은 마법을 숨깁니다. 탐색이 즉시 이루어집니다 — 플레이어가 파일 전체를 스트리밍하는 대신 대상 타임스탬프를 포함하는 세그먼트로 바로 점프할 수 있기 때문입니다. 화질 변경이 매끄럽습니다 — 플레이어가 재생을 재시작하지 않고 다음 세그먼트에 대해 다른 변형을 고를 수 있기 때문입니다. 버퍼링이 부드럽습니다 — 플레이어가 거대한 파일 청크를 미리 다운로드할 필요 없이 몇 세그먼트 — 보통 10~30초 — 앞만 유지하면 되기 때문입니다. 그리고 라이브 스트리밍이 작동합니다 — 방송자가 새 세그먼트를 생성할 때마다 플레이리스트에 추가될 수 있고, 플레이어가 몇 초마다 새 항목을 위해 .m3u8을 폴링하기 때문입니다.

Wi-Fi가 흔들릴 때 YouTube나 Netflix 스트림은 매끄럽게 회복되는데, 임의의 웹사이트의 직접 MP4 다운로드는 멈추고 죽는 이유가 궁금했다면, 이 때문입니다. 전체 스택은 인터넷이 지저분하고 연결이 왔다 갔다 한다는 가정을 중심으로 설계되었습니다. 플레이어가 즉석에서 화질을 어떻게 적응시키는지에 대한 긴 논의는 별개의 글에 있습니다. 여기서는 세그먼트와 플레이리스트 설계가 그 적응 자체를 가능하게 만든다는 것만 주목하십시오.

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

HLS 스트림은 두 계층의 플레이리스트와 세그먼트 더미가 일반 HTTP 위에서 제공되는 것입니다. 이국적인 것도 없고, 커스텀 프로토콜도 없습니다 — 브라우저가 이미 모든 부분을 처리할 줄 압니다.

마스터 플레이리스트

플레이어가 처음 가져오는 것은 마스터 플레이리스트입니다. .m3u8 확장자를 가진 작은 텍스트 파일로, 사용 가능한 스트림의 모든 변형 — 보통 다른 화질 수준 — 을 각각의 대역폭 및 해상도와 함께 나열합니다. 실제 사례를 가볍게 다듬은 것은 다음과 같습니다.

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8

#EXTM3U 줄은 파일을 확장 M3U 플레이리스트로 표시합니다. #EXT-X-VERSION:6은 사용 중인 HLS 프로토콜 버전을 선언합니다. 각 #EXT-X-STREAM-INF 블록은 한 변형을 설명합니다. 비트레이트, 해상도, 코덱 문자열, 그 다음에 그 변형의 두 번째 플레이리스트를 가리키는 URL이 옵니다. 플레이어는 이 파일을 읽고, 대역폭을 추정하고, 지탱할 수 있다고 판단하는 변형을 선택합니다.

미디어 플레이리스트

플레이어가 변형을 선택하면 그 변형의 미디어 플레이리스트를 가져옵니다. 여기에 실제 세그먼트 URL이 있습니다.

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment000.ts
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION:6은 어떤 세그먼트도 6초보다 길지 않다고 말합니다. 각 #EXTINF:6.000, 줄은 세그먼트의 정확한 길이를 알리고, 그 뒤에 세그먼트 URL이 옵니다. #EXT-X-ENDLIST는 플레이어에게 이것이 VOD 스트림임을 — 더 이상 세그먼트가 추가되지 않을 것임을 — 알립니다. 라이브 스트림은 #EXT-X-ENDLIST를 생략하고, 플레이어는 이 플레이리스트를 몇 초마다 다시 요청해 새 세그먼트를 발견합니다.

세그먼트: .ts와 fMP4

세그먼트는 짧은 동영상 및 오디오 청크입니다 — 보통 2~10초 — 어떤 세그먼트의 시작에서도 디코딩을 시작할 수 있도록 키프레임 경계에서 잘립니다. 플레이리스트가 #EXT-X-INDEPENDENT-SEGMENTS를 선언하면 모든 세그먼트는 단독으로 재생 가능함이 보장됩니다. 그 플래그가 없으면 다운스트림 세그먼트는 이전 세그먼트가 운반하는 데이터에 의존할 수 있습니다. 역사적으로 세그먼트는 MPEG-2 Transport Stream 파일이며 .ts 확장자를 갖습니다 — 위성 및 케이블 TV를 전송하는 동일한 컨테이너 형식입니다. MPEG-TS는 잡음 많은 방송 채널을 위해 설계되어 부분적 손상에 강건하며, .ts 패킷을 디코딩할 수 있는 어떤 플레이어도 HLS 세그먼트를 재생할 수 있습니다.

일반적인 세그먼트 길이는 2~10초입니다. 짧은 세그먼트는 더 낮은 지연과 더 민첩한 비트레이트 전환을 의미하지만, 더 많은 HTTP 요청과 분당 더 많은 오버헤드를 의미합니다. 긴 세그먼트는 더 나은 압축 효율과 더 적은 요청을 의미하지만, 대역폭 변화에 대한 느린 반응을 의미합니다. Apple의 원래 사양은 10초 세그먼트를 권장했으며, 현대 서비스는 보통 2~6초 범위에 정착합니다.

2016년 이후 업계는 .ts에서 fragmented MP4 세그먼트로 — 구체적으로 Common Media Application Format(CMAF), ISO/IEC 23000-19로 표준화된 — 이주해 왔습니다. CMAF 세그먼트는 MPEG-DASH와 동일한 MP4 fragmentation을 사용하므로, CDN상의 단일 파일 집합이 HLS와 DASH 플레이어 모두에 제공될 수 있습니다. 이는 스트리밍 서비스에 상당한 비용 절감입니다. 하나의 인코드, 하나의 바이트 집합, 두 프로토콜. YouTube, Netflix, Apple의 최신 HLS 스트림은 거의 모두 레거시 MPEG-TS가 아닌 CMAF입니다.

처음부터 끝까지 HTTP

HTTP Live Streaming의 “HTTP”가 핵심입니다. 회선에는 특별한 프로토콜이 없습니다 — HLS의 모든 부분은 브라우저가 HTML과 JPEG에 쓰는 동일한 HTTPS 요청 위에서 이동합니다. CDN은 이미 HTTP에 최적화되어 있었기 때문에 이를 좋아합니다. 방화벽은 비정상적으로 보이는 것이 없어 허용합니다. CDN은 인기 있는 세그먼트를 엣지에서 캐시할 수 있습니다. Range 요청, gzip, HTTP/2, HTTP/3, TLS — 모든 것이 공짜로 작동합니다.

이것이 또한 HLS가 이긴 이유입니다. RTMP, RTSP, MMS 같은 초기 스트리밍 프로토콜은 전용 포트, 상태 있는 서버, 특별한 방화벽 규칙이 필요했습니다. HLS는 많은 작은 파일을 제공하는 웹사이트처럼 보일 뿐입니다.

대부분의 사용자는 이를 수동으로 처리할 필요가 없습니다 — VidMost는 .m3u8 매니페스트를 파싱하고 백그라운드에서 세그먼트를 깔끔한 MP4로 병합합니다.

실제 세계에서 HLS를 어디서 만나나요

HLS는 2026년 거의 모든 주요 스트리밍 서비스에 있으며, 종종 DASH와 나란히 있습니다. Apple은 2009년 원래의 iPhone에 동영상을 전달하기 위해 HLS를 발명했습니다 — 그 기기는 셀룰러 네트워크에서 프로그레시브 다운로드를 잘 처리하지 못했고, Apple은 통신사에 그저 HTTP 트래픽처럼 보이는 스트리밍 형식을 원했습니다. 그 이후 이 프로토콜은 인터넷의 거대한 부분의 기본값이 되었습니다.

• Apple 자체 서비스는 HLS 전용입니다. Apple TV+, iTunes Store, Apple Podcasts의 팟캐스트, 그리고 Safari, iOS, tvOS에서 재생되는 모든 동영상이 HLS 위에 있습니다. Apple 플랫폼은 내장 MPEG-DASH 디코더를 제공하지 않으므로, iPhone에서 재생하려는 어떤 서비스든 HLS 피드를 제공해야 합니다.
• YouTube는 웹과 Android의 주 프로토콜로 MPEG-DASH를 사용하지만, iOS, Safari, AirPlay, 대부분의 TV 앱에는 HLS를 제공합니다. Safari에서 YouTube의 브라우저 개발자 도구를 열면 .m3u8 요청을 볼 수 있습니다. Android Chrome에서는 대신 DASH .mpd 요청을 볼 수 있습니다.
• Netflix, Disney+, Hulu, Max, Amazon Prime Video는 모두 혼합 사용합니다. 스마트 TV와 콘솔 앱은 종종 FairPlay나 PlayReady DRM과 함께 HLS를 사용합니다. 웹 플레이어는 종종 Widevine과 함께 DASH로 전환합니다. 같은 콘텐츠, 클라이언트마다 다른 프로토콜.
• Twitch는 2014년 재생 측에서 레거시 RTMP 스택을 폐기한 이후 HLS 위에서 동작합니다. Twitch의 모든 라이브 스트림과 VOD가 내부적으로 HLS입니다.
• 라이브 캠 및 크리에이터 플랫폼 — Bigo Live, Chaturbate, OnlyFans 라이브, Fansly 스트림 — 은 브라우저 재생을 위해 거의 보편적으로 HLS를 사용합니다. 플러그인 없이 작동하고 흔들리는 연결을 견디기 때문입니다.
• 호스팅 동영상 제공자 Vimeo, Mux, JW Player, Cloudflare Stream은 기본적으로 HLS를 전달합니다. 웹사이트가 Vimeo나 Mux iframe을 임베드하면, 그 아래의 동영상은 거의 확실히 HLS입니다.
• 스포츠와 뉴스 방송사 — ESPN, BBC iPlayer, DAZN, Sling TV — 는 모두 라이브 이벤트 전달을 위해 HLS에 의존하며, 종종 그 위에 DRM 계층을 얹습니다.

HLS는 Apple만이 아니라 모두에게 실제 문제를 해결했기 때문에 iOS 출신을 벗어났습니다. 2012년 DASH가 도착했을 때 HLS는 이미 폭넓은 CDN 지원, 야생에서 동작하는 플레이어, 그리고 모멘텀을 가지고 있었습니다. 오늘날 두 프로토콜은 공존합니다. 신중한 스트리밍 서비스는 둘 다 지원하며, 많은 서비스가 두 매니페스트 형식 아래에서 동일한 CMAF 세그먼트를 제공합니다. DASH가 HLS와 어떻게 비교되는지에 대해서는 자매 글이 엔드 투 엔드로 다룹니다.

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

HLS가 어떻게 작동하는지 알면 한 가지 실용적 문제가 갑자기 명백해집니다. HLS 동영상을 “오른쪽 클릭 → 다른 이름으로 저장”으로 다운로드할 수는 없습니다. 이유 중 몇 가지는 기계적이고, 몇 가지는 미묘하며, 한두 가지는 놀랍습니다.

• 브라우저의 다른 이름으로 저장은 .m3u8만 저장합니다. .m3u8은 페이지가 재생을 시작할 때 실제로 다운로드하는 것 — 작은 텍스트 파일입니다. 그것을 저장하면 음식이 아니라 레시피만 얻습니다. VLC에서 그 파일을 여는 것은 가끔 작동하지만(VLC가 내부의 URL을 따라감), 원래 세션이 여전히 유효하고 URL이 만료되지 않은 동안에만 그렇습니다.
• 각 세그먼트는 별개의 HTTP 요청입니다. 6초 세그먼트의 30분 동영상은 별개의 다운로드 300개입니다. 플레이리스트를 열거하고, 모든 세그먼트를 가져오고, 단일 파일로 재생 가능하기 전에 올바른 순서로 연결해야 합니다.
• 변형 선택은 실제 선택입니다. 마스터 플레이리스트는 여러 화질을 나열합니다. 잘못된 것을 고르면 1080p로 스트리밍되던 영화의 480p 사본을 얻습니다. 올바른 결정은 보통 저장 공간과 인내심이 흡수할 수 있는 가장 높은 대역폭 변형입니다.
• HTTPS는 전송 중 바이트를 보호하지, 디스크상의 바이트를 보호하지 않습니다. 세그먼트 URL은 거의 항상 HTTPS로 제공되므로, 네트워크상의 도청자는 스트리밍하는 것을 읽을 수 없습니다. 그러나 세그먼트가 브라우저에 도착하면 그것은 평문 동영상입니다 — TLS는 이미 응답에 접근한 도구를 막는 데 아무 역할을 하지 않습니다.
• HLS는 콘텐츠 계층으로 AES-128 세그먼트 암호화를 지원합니다. .m3u8이 #EXT-X-KEY 태그를 운반하면 각 세그먼트가 AES-128로 암호화되고, 플레이리스트는 플레이어가 HTTPS로 가져오는 키 URL을 가리킵니다. 키 없이 세그먼트만 저장하면 암호문 폴더를 얻습니다. 이는 콘텐츠 암호화이며 전송 보안과 별개이고, 권한 확인이 내장되어 있지 않습니다 — 키 URL 자체가 문입니다.
• 상용 DRM은 다른 문제입니다. Netflix, Disney+, Apple TV+ 같은 프리미엄 서비스는 HLS 위에 FairPlay(Apple), Widevine(Google), 또는 PlayReady(Microsoft) 계층을 얹습니다. 회선상의 암호화는 여전히 AES 기반이지만, 키는 플레이어가 신뢰할 수 있는 기기에서 권한을 증명한 후에만 라이선스 서버가 발급하며, 복호화는 하드웨어 기반 보안 모듈 안에서 일어나므로 프레임이 애플리케이션 메모리에 닿지 않습니다. 전체 그림은 DRM 보호 콘텐츠란 무엇인가?를 참조하십시오.
• 토큰과 서명된 URL은 만료됩니다. 많은 .m3u8 URL과 세그먼트 URL은 몇 분 안에 만료되는 단명한 토큰으로 서명됩니다. 수동으로 다운로드를 스크립팅할 때쯤이면 링크 절반이 이미 죽어있을 수 있습니다.

여기가 VidMost가 인계받도록 만들어진 곳입니다. VidMost는 사용자가 합법적으로 접근 권한을 가진 HLS 콘텐츠를 규정에 맞게 백업하기 위해 설계되었습니다 — 본인이 진행한 라이브 방송의 아카이브, 결제하고 구매한 유료 강의, 자유 라이선스나 퍼블릭 도메인 영상, 상용 DRM이 걸려 있지 않은 기업 교육 자료, 그리고 서비스 약관이 다운로드를 허용하는 유료 구독 콘텐츠 등입니다. VidMost는 .m3u8 매니페스트를 파싱하고, 사용 가능한 최고 화질 변형을 선택하며, 브라우저가 이미 통신 중이던 동일한 CDN에서 모든 세그먼트를 병렬로 다운로드하고, 일반적인 AES-128 세그먼트 암호화를 자동으로 처리하며, 완료되면 세그먼트를 단일한 깔끔한 MP4 파일로 리먹스합니다. Netflix, Disney+, Apple TV+ 같은 프리미엄 서비스에서 FairPlay, Widevine, PlayReady 등 상용 DRM으로 보호되는 스트림은 VidMost의 설계 범위 밖입니다 — 각 플랫폼의 서비스 약관과 거주 지역의 법률을 반드시 준수하세요. 그 외의 경우 사용자가 보는 경험은 “규정에 부합하는 URL을 붙여넣고, MP4를 받는” 것입니다 — 프로토콜 계층이 사라집니다.

흔한 함정과 오해

HLS에 관한 한 줌의 오해가 포럼 스레드에 반복해서 등장합니다. 정리할 가치가 있습니다.

• “.m3u8은 동영상 파일이 아닙니다.” 인덱스입니다. 실제 동영상은 플레이리스트가 참조하는 세그먼트에 있습니다. 어떤 도구가 “m3u8을 다운로드”하겠다고 제안하면, 세그먼트도 가져와 병합하는지 물어보십시오 — 그렇지 않으면 쓸모없는 텍스트 파일을 얻습니다.
• “.ts 파일은 대부분의 플레이어에서 직접 재생되지 않습니다.” 단일 세그먼트는 VLC에서 몇 초 재생될 수 있지만, 전체 동영상은 폴더 안의 .ts 파일 시퀀스가 아닙니다 — 각각이 순서대로 디코딩되고 함께 이어 붙여져야 하는 시퀀스입니다. HLS를 말하지 못하는 플레이어는 기껏해야 첫 세그먼트를 재생하고 멈춥니다.
• “HLS가 항상 라이브를 의미하지는 않습니다.” “HTTP Live Streaming”은 2026년에 오해의 소지가 있는 이름입니다. HLS는 VOD에도 똑같이 잘 작동합니다. 같은 플레이리스트, 같은 세그먼트, 단지 #EXT-X-ENDLIST가 유한한 스트림을 표시할 뿐입니다. Netflix, Disney+, Apple TV+ 카탈로그 콘텐츠의 대부분은 라이브 HLS가 아니라 VOD HLS입니다.
• “연결이 떨어지면 높은 비트레이트가 항상 더 좋은 화질은 아닙니다.” 10Mbps 변형은 광케이블에서는 멋져 보이지만 3Mbps 모바일 회선에서는 비참하게 끊깁니다. 적응형 설계의 전체 요점은 플레이어가 연결이 지탱할 수 있는 것을 고른다는 것입니다 — 수동으로 재정의하는 것은 종종 경험을 더 좋게 하기보다 나쁘게 만듭니다.
• “브라우저 다운로드 도구는 보통 HLS에서 실패합니다.” 일반 “동영상 다운로더” 확장 프로그램은 MP4 파일을 가리키는 <video src="..."> 태그를 찾습니다. HLS 스트림은 그런 URL을 노출하지 않습니다. 플레이어는 Media Source Extensions를 사용해 세그먼트를 video 요소에 프로그래밍 방식으로 공급합니다. 매니페스트를 파싱하는 전용 도구가 존재하는 이유가 바로 이것입니다.

마무리하며

HLS는 시청하는 대부분의 동영상 아래에 있는 조용한 인프라입니다. 전송에 영리하려는 시도를 포기했기 때문에 작동합니다 — 커스텀 프로토콜도, 특수 서버도 없고, 그저 .m3u8 텍스트 파일과 .ts 또는 fMP4 세그먼트가 브라우저가 이미 말하는 동일한 HTTP 위에서 가져와집니다. Apple은 2009년에 휴대폰 문제를 해결했고 우연히 향후 20년의 지배적인 스트리밍 형식을 만들었습니다.

브라우저의 네트워크 탭에서 .m3u8 요청을 알아보고 플레이리스트를 읽을 수 있게 되면, 엄청난 양의 스트리밍 동작 — 짧은 화질 전환, 즉시 탐색, “버퍼 앞” 표시, 결국 손에 쥐게 된 .ts 파일의 이상한 폴더 — 이 더 이상 신비롭지 않게 됩니다. 모두 같은 루프입니다. 플레이리스트 페치, 변형 선택, 세그먼트 페치, 디코드, 반복.

프로토콜 계층을 완전히 건너뛰고 그저 동영상을 저장하고 싶다면, VidMost가 HLS, DASH, fMP4, DRM 보호 스트림을 처리합니다.

관련 글

• 온라인 동영상은 실제로 어떻게 재생되는가 — 카메라에서 화면까지의 전체 파이프라인.
• MPEG-DASH 대 HLS — 각 프로토콜이 이기는 경우와 대부분의 스트리밍 서비스가 둘 다 제공하는 이유.
• 재생 중에 동영상 화질이 바뀌는 이유 — 모든 HLS와 DASH 플레이어 안의 ABR 로직.
• 동영상 컨테이너 대 코덱 — .mp4, .ts, .m4s 안에 실제로 무엇이 들어 있는가.
• DRM 보호 콘텐츠란 무엇인가? — Widevine, FairPlay, PlayReady가 그저 저장할 수 없는 암호화된 변형을 어떻게 게이팅하는가.