Что такое M3U8? Полное руководство по протоколу HLS и плейлисту .m3u8

M3U8 — это UTF-8 текстовый плейлист, который использует протокол HLS (HTTP Live Streaming). Сам файл не содержит видеокадров — это манифест со списком URL видеосегментов (.ts или .m4s), их длительностей и доступных вариантов битрейта. Плеер читает .m3u8, по очереди загружает сегменты и сшивает их в реальном времени в воспроизводимый видеопоток — именно этот механизм лежит в основе YouTube, Netflix, Twitch, Apple TV+ и большинства крупных стриминговых сервисов в 2026 году.

Вы когда-нибудь пытались сохранить видео со стриминг-сайта и в итоге получали сотни крошечных файлов .ts вместо одного аккуратного .mp4? Или открывали вкладку Network в браузере, ожидая чистый URL загрузки, а вместо этого находили нескончаемый поток двухсекундных фрагментов? Вы не делали ничего неправильно. Вы смотрели HLS — протокол, доставляющий большую часть стримингового видео в современном вебе, — а HLS не отправляет видео как один файл. Он отправляет его как рецепт плюс части.

Рецепт — это маленький текстовый файл-плейлист .m3u8. Части — короткие независимо декодируемые видеосегменты, которые плеер сшивает на лету. HLS был создан Apple в 2009 году для первого iPhone и стандартизирован как RFC 8216; сегодня его нативно поддерживают почти все крупные браузеры, мобильные устройства и телевизоры.

Это руководство пройдёт по тому, что на самом деле содержит .m3u8, почему стриминговые сервисы выбрали этот дизайн, как соотносятся .ts и fMP4-сегменты, какие платформы используют HLS в 2026 году и что происходит, когда вы пытаетесь сохранить один из этих потоков на диск.

Главное {#key-takeaways}

• HLS — это стриминговый протокол, а не формат файла. Он доставляет видео как плейлист (.m3u8) плюс короткие сегменты (.ts или fragmented MP4) по обычному HTTP.
• .m3u8 — это индекс, а не видео. Сохранение одного только файла .m3u8 даёт вам рецепт без ингредиентов.
• Apple создала HLS в 2009 году для iPhone и стандартизировала его как RFC 8216 в 2017 году. Сейчас он обязателен на 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 на новые записи каждые несколько секунд.

Если вы когда-нибудь задумывались, почему поток YouTube или Netflix плавно подхватывается, когда ваш Wi-Fi дрогнул, в то время как прямая загрузка 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 говорит плееру, что это поток видео по запросу — больше сегментов никогда добавлено не будет. Прямые трансляции опускают #EXT-X-ENDLIST, а плеер перезапрашивает этот плейлист каждые несколько секунд, чтобы обнаружить новые сегменты.

Сегменты: .ts и fMP4

Сегменты — это короткие фрагменты видео и аудио — обычно 2–10 секунд — нарезанные по границам ключевых кадров, чтобы плеер мог начать декодирование с начала любого сегмента. Когда плейлист объявляет #EXT-X-INDEPENDENT-SEGMENTS, каждый сегмент гарантированно воспроизводится сам по себе; без этого флага последующие сегменты могут зависеть от данных, переносимых предыдущими. Исторически сегменты — это файлы MPEG-2 Transport Stream с расширением .ts — тот же формат контейнера, что доставляет спутниковое и кабельное ТВ. 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-сегменты используют ту же фрагментацию MP4, что и MPEG-DASH, а это означает, что один набор файлов на CDN может обслуживать и HLS-, и DASH-плееры. Это значительная выгода по стоимости для стриминговых сервисов: одна кодировка, один набор байтов, два протокола. Современные HLS-потоки от YouTube, Netflix и Apple — это почти полностью CMAF, а не устаревший MPEG-TS.

HTTP до самого низа

«HTTP» в HTTP Live Streaming — это панчлайн. В кабеле нет никакого специального протокола — каждая часть HLS идёт по тем же HTTPS-запросам, что ваш браузер использует для HTML и JPEG. CDN это обожают, потому что они уже были оптимизированы под HTTP. Файрволы пропускают это, потому что ничего необычного. CDN могут кэшировать популярные сегменты на границе. Range-запросы, gzip, HTTP/2, HTTP/3, TLS — всё это работает «бесплатно».

Именно поэтому HLS победил. Более ранние стриминговые протоколы — RTMP, RTSP, MMS — требовали выделенных портов, серверов с состоянием и специальных правил файрвола. HLS просто выглядит как сайт, отдающий много маленьких файлов.

Большинству пользователей не нужно вручную с этим разбираться — VidMost разбирает манифест .m3u8 и объединяет сегменты в чистый MP4 в фоне.

Где вы встречаете HLS в реальном мире

HLS присутствует практически на каждом крупном стриминговом сервисе в 2026 году, часто рядом с DASH. Apple изобрела HLS в 2009 году специально для доставки видео на оригинальный iPhone — устройство плохо справлялось с прогрессивной загрузкой по сотовым сетям, и Apple хотела формат стриминга, который для операторов просто выглядел как HTTP-трафик. С тех пор протокол стал стандартом по умолчанию для огромного куска интернета.

• Собственные сервисы Apple — только HLS. Apple TV+, iTunes Store, подкасты в Apple Podcasts и любое видео, воспроизводящееся в Safari, на iOS или tvOS, опирается на HLS. Платформы Apple не поставляют встроенный декодер MPEG-DASH, поэтому любой сервис, который хочет воспроизводиться на iPhone, должен предлагать HLS-фид.
• YouTube использует MPEG-DASH как основной протокол в вебе и на Android, но поставляет HLS для iOS, Safari, AirPlay и большинства ТВ-приложений. Откройте инструменты разработчика браузера на YouTube в Safari, и вы увидите запросы .m3u8; в Chrome на Android вместо этого увидите DASH-запросы .mpd.
• Netflix, Disney+, Hulu, Max и Amazon Prime Video — все используют смесь. Их приложения для смарт-ТВ и консолей часто используют HLS с FairPlay или PlayReady DRM; их веб-плееры часто переключаются на DASH с Widevine. Один и тот же контент, разный протокол для разных клиентов.
• Twitch работает на HLS с 2014 года, когда он отказался от устаревшего RTMP-стека на стороне воспроизведения. Каждая прямая трансляция и каждый VOD на Twitch — это HLS под капотом.
• Платформы прямых трансляций и для авторов — Bigo Live, Chaturbate, OnlyFans live, трансляции Fansly — почти повсеместно используют HLS для воспроизведения в браузере, потому что он работает без плагинов и терпит ненадёжные соединения.
• Хостинговые видеопровайдеры вроде Vimeo, Mux, JW Player и Cloudflare Stream доставляют HLS по умолчанию. Если сайт встраивает iframe Vimeo или Mux, видео под ним почти наверняка HLS.
• Спортивные и новостные вещатели — ESPN, BBC iPlayer, DAZN, Sling TV — все полагаются на HLS для доставки прямых событий, часто с наложенным сверху DRM.

HLS вырвался за пределы своих iOS-корней, потому что решал реальные проблемы для всех, а не только для Apple. К моменту прибытия DASH в 2012 году у HLS уже была широкая поддержка CDN, работающие плееры в продакшене и инерция. Сегодня два протокола сосуществуют; продуманный стриминговый сервис поддерживает оба, и многие поставляют одни и те же CMAF-сегменты под обоими форматами манифеста. Подробнее о том, как DASH сравнивается с HLS, родственная статья освещает это от начала до конца.

Что это значит, если вы хотите сохранить видео

Знание того, как работает HLS, делает одну практическую проблему внезапно очевидной: вы не можете просто «правый клик → Сохранить как» проложить путь к скачанному HLS-видео. Несколько причин механические, несколько тонкие, и одна или две вас удивят.

• Сохранить как в браузере сохраняет только .m3u8. .m3u8 — это то, что страница на самом деле скачивает, когда начинает воспроизведение, — небольшой текстовый файл. Сохранение его даёт вам рецепт, а не еду. Открытие этого файла в VLC иногда работает (VLC последует по URL внутри), но только пока оригинальная сессия ещё действительна и URL не истекли.
• Каждый сегмент — это отдельный HTTP-запрос. 30-минутное видео с 6-секундными сегментами — это 300 отдельных загрузок. Вам нужно перечислить плейлист, получить каждый сегмент и конкатенировать их в правильном порядке, прежде чем они станут воспроизводимыми как один файл.
• Выбор варианта — реальный выбор. Мастер-плейлисты перечисляют несколько качеств. Неверный выбор даст вам копию 480p фильма, который стримился в 1080p. Правильное решение обычно — самый высокобитрейтный вариант, который выдержат ваше хранилище и терпение.
• HTTPS защищает байты в пути, а не байты на диске. URL сегментов почти всегда обслуживаются по HTTPS, так что подслушивающий в сети не может прочитать, что вы стримите. Но как только сегмент пришёл в ваш браузер, это незашифрованное видео — TLS ничего не делает, чтобы остановить инструмент, у которого уже есть доступ к ответу.
• HLS поддерживает шифрование сегментов AES-128 как уровень содержимого. Когда .m3u8 несёт тег #EXT-X-KEY, каждый сегмент зашифрован AES-128, а плейлист указывает на URL ключа, который плеер получает по HTTPS. Сохраните сегменты без ключа — и у вас папка шифротекста. Это шифрование контента, отдельное от транспортной безопасности, и в него не встроена проверка прав доступа — воротами является сам URL ключа.
• Коммерческий DRM — другая проблема. Премиум-сервисы вроде Netflix, Disney+ и Apple TV+ наслаивают на HLS FairPlay (Apple), Widevine (Google) или PlayReady (Microsoft). Шифрование в кабеле всё ещё на основе AES, но ключи выдаются лицензионным сервером только после того, как плеер подтвердит права на доверенном устройстве, а расшифровка происходит внутри аппаратно поддерживаемого защищённого модуля, так что кадры никогда не касаются памяти приложения. См. Что такое DRM-защищённый контент? для полной картины.
• Токены и подписанные URL истекают. Многие URL .m3u8 и URL сегментов подписаны короткоживущими токенами, которые становятся неактуальными за минуты. К тому моменту, как вы вручную напишете скрипт загрузки, половина ваших ссылок уже может быть мертва.

Здесь VidMost и берёт дело в свои руки. VidMost создан для законного резервного копирования HLS-контента, к которому у вас есть правомерный доступ: архивов ваших собственных прямых трансляций, оплаченных вами курсов, видео со свободными лицензиями или из общественного достояния, корпоративных обучающих материалов без коммерческого DRM, а также контента платных подписок, если условия сервиса прямо разрешают скачивание. VidMost разбирает манифест .m3u8, выбирает доступный вариант наивысшего качества, скачивает каждый сегмент параллельно с того же CDN, с которым уже общался ваш браузер, автоматически обрабатывает обычное шифрование сегментов AES-128 и ремультиплексирует сегменты в один чистый файл MP4 по завершении. Потоки, защищённые коммерческим DRM, — FairPlay, Widevine или PlayReady на премиум-сервисах вроде Netflix, Disney+ или Apple TV+, — находятся вне области применения VidMost; следуйте условиям обслуживания каждой платформы и законам вашей юрисдикции. Для всего остального видимый пользователю опыт — «вставил подходящий URL — получил MP4», а уровень протокола исчезает.

Распространённые заблуждения и подводные камни

Несколько заблуждений о HLS снова и снова всплывают в ветках форумов. Стоит их прояснить.

• «.m3u8 — это не видеофайл». Это индекс. Само видео находится в сегментах, на которые ссылается плейлист. Если инструмент предлагает «скачать m3u8», спросите, получает ли он также сегменты и сливает ли их — иначе у вас бесполезный текстовый файл.
• «Файлы .ts не воспроизводятся напрямую в большинстве плееров». Один сегмент может воспроизвести несколько секунд в VLC, но всё видео — это не последовательность файлов .ts в папке, а последовательность, где каждый должен быть декодирован по порядку и сшит вместе. Плееры, не понимающие HLS, в лучшем случае воспроизведут первый сегмент и остановятся.
• «HLS не всегда означает live». «HTTP Live Streaming» — обманчивое название в 2026 году. HLS одинаково хорошо работает для видео по запросу: те же плейлисты, те же сегменты, просто с #EXT-X-ENDLIST, маркирующим конечный поток. Подавляющее большинство каталога Netflix, Disney+ и Apple TV+ — это VOD HLS, а не live.
• «Более высокий битрейт — не всегда лучшее качество, если соединение проседает». Вариант 10 Мбит/с отлично выглядит на оптоволокне и жалко заикается на мобильном канале 3 Мбит/с. Весь смысл адаптивного дизайна в том, что плеер выбирает то, что ваше соединение может поддержать — переопределение его вручную часто делает опыт хуже, а не лучше.
• «Браузерные инструменты загрузки обычно не справляются с HLS». Универсальные расширения «скачивания видео» ищут теги <video src="...">, указывающие на MP4-файлы. HLS-потоки не выставляют такой URL; плеер использует Media Source Extensions, чтобы программно подавать сегменты в видеоэлемент. Именно поэтому существуют специализированные инструменты, разбирающие манифест.

Заключение

HLS — это безмолвная инфраструктура под большей частью видео, которое вы смотрите. Он работает, потому что отказался от попыток быть умным по поводу транспорта — никакого нестандартного протокола, никакого специального сервера, просто текстовые файлы .m3u8 и сегменты .ts или fMP4, получаемые по тому же HTTP, на котором уже говорит ваш браузер. Apple решила проблему телефона в 2009 году и случайно построила доминирующий стриминговый формат двух следующих десятилетий.

Как только вы научитесь распознавать запрос .m3u8 в сетевой вкладке вашего браузера и читать плейлист, огромное количество стримингового поведения — короткие переключения качества, мгновенная перемотка, индикатор «буферизация впереди», странная папка .ts-файлов, в которой вы оказались — перестаёт быть загадочным. Это всё тот же цикл: получить плейлист, выбрать вариант, получить сегменты, декодировать, повторить.

Если вы предпочитаете полностью пропустить уровень протокола и просто сохранить видео, VidMost обрабатывает HLS, DASH, fMP4 и DRM-защищённые потоки.

Связанные материалы

• Как на самом деле воспроизводится онлайн-видео — полный конвейер от камеры до вашего экрана.
• MPEG-DASH против HLS — когда каждый протокол выигрывает и почему большинство стриминговых сервисов поставляют оба.
• Почему качество видео меняется в процессе воспроизведения — логика ABR внутри каждого HLS- и DASH-плеера.
• Контейнеры видео против кодеков — что на самом деле находится внутри .mp4, .ts или .m4s.
• Что такое DRM-защищённый контент? — как Widevine, FairPlay и PlayReady контролируют зашифрованные варианты, которые нельзя просто сохранить.