Как на самом деле воспроизводится онлайн-видео: от клика до кадра

Вы нажимаете воспроизведение на видео YouTube — и через секунду на вашем экране уже что-то есть. Что произошло за эту секунду? Поистине поразительное количество событий, учитывая, что видео не находится на вашем устройстве, файл, который вы смотрите, нигде не существует как единый файл, а байты, которые сейчас светятся на вашем дисплее, пришли даже не с серверов YouTube. Они пришли из кэша где-то в той же агломерации, где и ваш дом, — копии, сделанной на случай, если вы или тысяча других зрителей попросят именно этот фрагмент именно этого фильма.

Вот последовательность. Ваш браузер связывается с сервером, который передаёт ему крошечный текстовый файл с описанием видео. Плеер читает этот файл, выбирает один из нескольких вариантов качества и начинает запрашивать у CDN короткие фрагменты аудио и видео — обычно по две-шесть секунд каждый. Фрагменты приходят по тем же HTTPS-соединениям, что обслуживают обычные веб-страницы. Плеер декодирует их на железе, которое у вашего телефона или ноутбука уже есть, и выводит кадры на экран. Пока вы смотрите первый фрагмент, плеер уже получает следующие три. Если ваш Wi-Fi дрогнет, он тихо перейдёт на версию следующего фрагмента более низкого качества, чтобы воспроизведение не остановилось. Весь этот цикл — получить манифест, получить сегменты, декодировать, отрисовать, измерить, адаптироваться — невидимо крутится за каждым видео Netflix, YouTube, Twitch, Disney+ и TikTok в сети.

Это опорная статья нашей серии о стриминге. Мы пройдём весь конвейер от камеры на одном конце до кадра на вашем экране на другом — понятным языком. Мы рассмотрим технические уровни достаточно глубоко, чтобы быть точными, но без жаргонного болота, посмотрим, какие сервисы используют какие комбинации этих уровней, и закончим практическим вопросом, ради которого многие читатели сюда пришли: можно ли, посмотрев видео, оставить себе копию?

Видеостриминг — это доставка видео на ваше устройство в виде непрерывной серии коротких, последовательно пронумерованных файловых сегментов, получаемых по HTTPS, направляемых небольшим файлом манифеста, декодируемых на лету и удаляемых, как только следующий сегмент уже в пути.

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

• Стриминг — это не специальный протокол, а ловкий приём поверх обычного HTTP. Манифесты и сегменты — это просто файлы на CDN.
• Видео, которое вы «смотрите», не существует как единый файл. Оно собирается в вашем плеере из манифеста плюс нескольких сотен небольших сегментов.
• Кодирование производит несколько вариантов битрейта одного и того же контента. Плеер выбирает между ними на основе измерений полосы пропускания в реальном времени.
• Большинство сегментов приходит с граничного узла CDN рядом с вами, а не с сервера-источника. Граничные кэши — это причина того, что стриминг ощущается мгновенным.
• Адаптивный битрейт — это то, почему качество незаметно меняется в процессе воспроизведения: плеер переключает варианты между сегментами, чтобы поддерживать здоровый буфер.
• Три уровня шифрования могут складываться независимо: HTTPS для транспорта, AES-128 для содержимого сегментов и DRM для коммерческих потоков с проверкой лицензии.
• HLS и DASH доминируют. HLS — это спецификация Apple (RFC 8216, .m3u8); DASH — стандарт ISO/IEC (23009-1, XML .mpd). Большинство крупных сервисов поставляют оба.
• Сохранение потока означает разбор манифеста, получение каждого сегмента, обработку шифрования и ремультиплексирование — а не правый клик и «Сохранить как».

Простое объяснение

Представьте, что вы должны доставить полнометражный фильм сотне миллионов зрителей по всему миру. Фильм огромен — один двухчасовой фильм 1080p H.264 весит примерно 4–8 гигабайт — а ваши зрители подключены с самых разных каналов: от гигабитного оптоволокна до нестабильного 4G в движущемся поезде. Вы не можете отправить один и тот же гигантский файл всем. Вы даже не можете отправить нужный файл: зрителю в поезде нужна копия с низким битрейтом, зрителю на оптоволокне — с высоким, а если зритель в поезде переключится на Wi-Fi посреди фильма, вам нужно повысить ему качество без перезапуска.

Шаблон, на котором остановилась индустрия, настолько прост, что звучит почти разочаровывающе. Разрежьте фильм на сотни коротких клипов, закодируйте каждый клип в нескольких уровнях качества, храните все клипы на серверах по всему миру и позвольте плееру зрителя самому решать, какой клип воспроизводить следующим. Вот и всё. То, что называется «стримингом», по сути — это файлы в папках, получаемые по сети в определённом порядке.

Вот жизненный цикл от одного конца до другого:

1. Камера или рендер-движок захватывает необработанные кадры. Для live-трансляции это настоящая камера. Для видео по запросу — это готовый мастер-файл, который передаёт студия.
2. Энкодер сжимает необработанные кадры в кодек — H.264, H.265 или AV1 для видео; AAC или Opus для аудио. Энкодер обычно создаёт несколько выходных файлов с разными битрейтами из одного входного.
3. Упаковщик нарезает закодированные потоки на короткие сегменты и пишет манифест. Каждый вариант становится отдельной папкой с сегментами плюс манифест для этого варианта; варианты перечислены в мастер-манифесте верхнего уровня.
4. Сегменты и манифесты загружаются на origin и реплицируются на CDN. Cloudflare, Akamai, Fastly, AWS CloudFront — какой бы CDN ни использовал сервис — кэширует файлы на граничных узлах по всему миру.
5. Вы нажимаете воспроизведение. Ваш плеер загружает манифест, выбирает вариант, получает первые сегменты с ближайшего граничного узла CDN и начинает декодирование.
6. Плеер декодирует каждый сегмент и выводит кадры на ваш экран, поддерживая буфер длиной в несколько секунд впереди того, что вы смотрите.
7. Плеер измеряет пропускную способность по мере поступления сегментов и подгоняет вариант между сегментами, чтобы качество соответствовало вашему соединению в реальном времени.

Это весь конвейер. Больше ничего не происходит — никакого специального сервера, никакого проприетарного протокола в кабеле, никакой магии. На каждом шаге используются инструменты и форматы, под которые вы при достаточном терпении могли бы написать скрипт. Хитрость в дизайне: каждый сегмент достаточно короткий, чтобы переключать варианты между ними, манифест крошечный, поэтому цикл туда-обратно быстрый, сегменты кэшируются как любой другой статический файл, а плеер работает на том же железе, которое уже декодирует Blu-ray и звонки FaceTime. Весь стриминговый веб построен из HTTPS, файлов и тайминга. Протоколы и кодеки, которые мы рассмотрим дальше, — это просто соглашения, позволяющие этим частям взаимодействовать в масштабе.

Как на самом деле работает стриминговое видео

Это техническое ядро опорной статьи. Мы пройдём весь конвейер от начала до конца. К моменту, когда мы закончим, вы должны уметь посмотреть на вкладку Network на любом стриминговом сайте и определить, к какому этапу относится каждый запрос.

Камера → Энкодер → Упаковщик → Origin → Граница CDN → Плеер → Декодер → Экран

Эта схема — весь путь. Каждая концепция ниже — лестницы битрейтов, манифесты, сегменты, ABR, шифрование — встаёт куда-то на эту стрелку.

Origin и кодирование

Всё начинается с необработанного видео. Для прямой трансляции это камера (или захват экрана в случае стриминга игр), производящая несжатые кадры, скажем, в 1920×1080 при 60 кадрах в секунду. В несжатом виде это примерно 3 гигабита в секунду. Никто не передаёт необработанное видео по публичному интернету. Первая задача — сжатие.

Видеоэнкодер превращает необработанные кадры в сжатый битовый поток, эксплуатируя временную избыточность (большинство пикселей похожи на пиксели предыдущего кадра) и пространственную избыточность (большинство областей изображения похожи на соседние). Доминирующие кодеки в 2026 году:

• H.264 (AVC) — стандартизирован в 2003 году. Старый, но всё ещё самый широко поддерживаемый кодек в интернете. Любое устройство, выпущенное за последние 15 лет, может декодировать его аппаратно.
• H.265 (HEVC) — примерно на 50 % эффективнее H.264 при том же качестве. Обременён лицензионными отчислениями, что замедлило его принятие в вебе, но повсеместно распространён на телефонах, смарт-ТВ и платформах Apple.
• AV1 — без отчислений, открытый, немного эффективнее HEVC. YouTube, Netflix и Vimeo — крупнейшие издатели AV1. Аппаратная поддержка декодирования наконец стала повсеместной по состоянию на 2025–2026 годы.
• AAC и Opus — аудиокодеки. AAC обязателен в HLS; Opus доминирует в WebRTC и всё чаще встречается в DASH.

Один и тот же контент практически всегда кодируется в несколько вариантов битрейта. Типичная кодировочная лестница может выглядеть так:

Каждая строка в этой таблице — отдельная кодировка одного и того же источника. Они выровнены по времени, чтобы плеер мог переключаться между ними в одно и то же время по часам без перезапуска декодера. Подробнее о том, что на самом деле находится внутри каждого варианта — кодек или контейнер — см. контейнеры вроде MP4 против кодеков вроде H.264.

Упаковка — сегменты и манифесты

После кодирования идёт упаковка: нарезка битового потока каждого варианта на короткие фрагменты, называемые сегментами, и запись манифеста, который их перечисляет.

Сегменты обычно содержат от 2 до 10 секунд видео и аудио каждый. Они нарезаются по границам ключевых кадров (I-кадр в битовом потоке), чтобы плеер мог начать декодирование с начала любого сегмента. Когда манифест объявляет EXT-X-INDEPENDENT-SEGMENTS (HLS) или эквивалент в DASH, каждый сегмент гарантированно воспроизводится сам по себе; без этого объявления некоторые сегменты зависят от данных, переносимых предыдущими.

Формат контейнера сегмента варьируется:

• MPEG-TS (.ts) — устаревший HLS. Изначально формат спутникового/кабельного вещания из 1990-х, устойчивый к битовым ошибкам. Всё ещё используется, но постепенно выводится из эксплуатации.
• Fragmented MP4 (.m4s, иногда .mp4) — современный HLS и весь DASH. Тот же контейнер MP4, что у обычного файла, но нарезанный на фрагменты с собственными заголовками, чтобы каждый воспроизводился независимо.
• CMAF — Common Media Application Format (ISO/IEC 23000-19) — это профиль фрагментированного MP4 и ограничение упаковки, а не слияние .ts и fMP4. Он точно определяет, как должны быть структурированы fMP4-сегменты, чтобы один и тот же набор файлов fMP4 мог использоваться и HLS .m3u8, и DASH .mpd. Современные сервисы поставляют CMAF, а не дублируют байты под каждый протокол; устаревшие сегменты .ts всё ещё существуют рядом для старых HLS-клиентов, не способных принимать fMP4.

Сам манифест бывает двух видов:

• HLS-манифесты — это текстовые файлы .m3u8. Мастер-плейлист перечисляет варианты и их пропускную способность; у каждого варианта есть медиа-плейлист со списком URL сегментов и их длительностей. См. что на самом деле содержится в m3u8-файле для полного разбора.
• DASH-манифесты — это XML-файлы .mpd. Один файл описывает всю презентацию — наборы адаптации, представления, таймлайны сегментов, BaseURL — в древовидной структуре. См. DASH и его манифест .mpd для сравнения с HLS.

Оба дизайна делают одну и ту же работу: манифест говорит плееру, какие варианты существуют, где живёт каждый сегмент и какова его длительность. Всё остальное — на усмотрение плеера.

Распространение через CDN

Когда сегменты и манифесты существуют в виде файлов, стриминговый сервис загружает их на сервер-источник — обычно объектное хранилище вроде S3 или R2 — и позволяет сети доставки контента реплицировать их на граничные узлы по всему миру. CDN, которые вы увидите в сетевых запросах, включают Akamai, Cloudflare, Fastly, AWS CloudFront, граничную сеть Google и частные CDN, которые Netflix (Open Connect) и YouTube размещают внутри интернет-провайдеров.

Причина, по которой CDN так важны для стриминга, — это кэшируемость. Сегмент — это статический файл с URL, который не меняется. Первый зритель в регионе тянет сегмент с origin; граница кэширует его; каждый зритель в этом регионе в течение следующего часа или двух получает его с сервера в десятках миллисекунд от себя. Для популярного видео на YouTube подавляющее большинство запросов сегментов никогда не доходит до origin YouTube — они обслуживаются из кэширующего бокса, физически находящегося внутри вашего провайдера.

Это также объясняет, почему стриминг так хорошо масштабируется. Добавление миллиона одновременных зрителей в Токио не добавляет миллиона круговых обходов до Калифорнии — оно добавляет нагрузки на токийский граничный узел, у которого файл уже был. Математика прощает так, как ни один докризисный 2010 года стриминговый протокол не позволял.

Рабочий процесс плеера

Теперь мы вернулись к вашему устройству. Ваш браузер загружает страницу, страница запускает JavaScript-плеер (обычно shaka-player, hls.js, video.js или фирменную сборку поверх одного из них), а плеер просит элемент <video> страницы начать воспроизведение. Дальше плеер крутит плотный цикл:

1. Получить манифест. Один HTTPS GET. Ответ — несколько килобайт текста.
2. Разобрать манифест и выбрать начальный вариант. Плееры выбирают на основе оценки пропускной способности (опирающейся на недавнюю историю или сетевую информацию устройства), разрешения экрана устройства и запаса безопасности, чтобы первый сегмент с высокой вероятностью не подвис.
3. Получить первые несколько сегментов. Современные плееры распараллеливают это по одному соединению HTTP/2 или HTTP/3. Сегменты приходят одновременно.
4. Передать байты сегментов в буфер Media Source Extensions браузера. MSE — это API W3C, позволяющий JavaScript программно подавать видеоданные в элемент <video>. Дальше работает встроенный декодер браузера.
5. Декодировать и отрисовывать. Декодер — с аппаратным ускорением практически на каждом устройстве, выпущенном за последнее десятилетие — превращает сжатые кадры в необработанные пиксели, а GPU выводит их с частотой кадров видео.
6. Держать буфер заполненным. Пока пользователь смотрит сегмент N, плеер уже получает сегменты N+1, N+2, N+3.
7. Пересматривать каждый сегмент. После каждой загрузки у плеера есть свежие данные о скорости соединения. Он использует их, чтобы решить, переключать ли вариант для следующего сегмента.

Большая часть кода плеера — это бухгалтерия: отслеживание состояния буфера, повтор неудачных запросов сегментов, обработка перемотки и паузы, вставка рекламных сегментов, переключение аудиодорожек, отрисовка субтитров. Стриминговая часть концептуально мала — получить, декодировать, повторить — а инженерная сложность живёт во всех граничных случаях вокруг неё.

Адаптивный битрейт (ABR)

Адаптивный битрейт — это то, ради чего вся конструкция стоит того, чтобы её использовать. Без ABR плеер выбирал бы одно качество, придерживался его и перебуферизовался в тот момент, когда соединение не могло его поддерживать. С ABR плеер измеряет пропускную способность на каждом сегменте и переключает варианты на лету.

Базовый цикл выглядит так. После каждой загрузки сегмента плеер вычисляет эффективную пропускную способность: размер сегмента, делённый на время загрузки. Он сравнивает её со скользящим средним недавних измерений. Если пропускная способность снижается, запрос следующего сегмента уходит к варианту с более низким битрейтом. Если пропускная способность растёт и буфер в порядке, плеер поднимается. Решения принимаются между сегментами, никогда не в середине сегмента, так что переключение бесшовное.

Реальные реализации ABR более тонкие. Они отслеживают заполненность буфера (здоровый буфер может рискнуть более высоким вариантом; опустошающийся буфер должен быстро падать), учитывают разрешение экрана (нет смысла стримить 4K на ноутбук с 720p) и используют модели предсказания — скользящие средние, низкочастотные фильтры, иногда оценщики на машинном обучении — чтобы избежать колебаний между вариантами. Два доминирующих алгоритма ABR в 2026 году — это BOLA (на основе буфера) и MPC (управление с прогнозирующей моделью), оба присутствуют в плеерах с открытым исходным кодом. Полный разбор — в статье логика ABR внутри каждого современного плеера.

Видимый пользователю итог: вам не нужно выбирать качество. Это делает плеер, секунда за секундой, и переключения обычно невидимы. Когда они не невидимы — когда вы замечаете внезапную размытость на экране Netflix — это ABR выбирает более низкий вариант, чтобы сохранить непрерывность воспроизведения.

Шифрование: три уровня, которые часто смешивают

Шифрование в стриминге — это больше, чем кажется, и три независимых уровня регулярно валят в одну кучу. Это не одно и то же.

HTTPS = транспортная безопасность. Каждый современный поток обслуживается по TLS. Это защищает байты от подслушивающих в сети: интернет-провайдер, атакующий по Wi-Fi или корпоративный прокси не могут прочитать, что течёт мимо них. HTTPS не мешает принимающему браузеру читать байты — он строго о канале.

Шифрование сегментов AES-128 = уровень содержимого. И HLS, и DASH поддерживают шифрование самих сегментов с помощью AES-128 в режиме CBC или CTR. Манифест несёт URL ключа; плеер получает ключ по HTTPS и расшифровывает каждый сегмент перед декодированием. Это защита уровня содержимого: она делает байты бесполезными, даже если кто-то их получил, но воротами является сам URL ключа. Любой, кто может дотянуться до URL ключа, может расшифровать сегменты. Многие live-платформы и платформы для авторов используют шифрование сегментов AES-128 как базовый уровень защиты.

DRM = расшифровка с лицензионным сервером и аппаратной поддержкой. Widevine (Google), FairPlay (Apple) и PlayReady (Microsoft) оборачивают политику поверх шифрования сегментов. Сегменты по-прежнему зашифрованы AES (в рамках MPEG Common Encryption, ISO/IEC 23001-7), но ключ контента обёрнут так, что распаковать его может только доверенный исполняемый модуль на вашем устройстве. Лицензионный сервер проверяет подписку, доверие к устройству и регион перед выдачей лицензии. Расшифровка происходит в аппаратно поддерживаемом защищённом модуле — GPU получает расшифрованные кадры напрямую, не пропуская их через память приложения. Именно это защищает Netflix, Disney+, Apple TV+ и большинство платных стриминговых сервисов. Подробный разбор — в как Widevine и FairPlay контролируют премиум-потоки.

Эти уровни складываются. Премиум-поток Netflix использует HTTPS для транспорта, CMAF-сегменты, зашифрованные по CENC, и Widevine или FairPlay для выдачи ключей через лицензионный сервер. Live-трансляция Twitch использует только HTTPS. Платформа платных курсов может использовать HTTPS плюс шифрование сегментов AES-128, но без DRM. Знание того, какие уровни в игре, говорит, какова на самом деле техническая планка для доступа к байтам — и где проходят границы законного использования.

Сохранение даже незашифрованного потока требует корректно говорить на всех этих протоколах, в правильном порядке, и обрабатывать граничные случаи, которые плеер обходит молча. VidMost был построен, чтобы выполнять эту работу в фоне — разбор манифестов, получение сегментов, обработка AES, DRM через встроенный Widevine L3, ремультиплексирование контейнеров — так что видимый пользователю шаг сводится к: вставил URL — получил MP4.

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

Описанный выше конвейер описывает, по сути, каждый коммерческий стриминговый сервис в 2026 году. Различия — в том, какие протоколы, кодеки и DRM выбирает каждый сервис и как они договариваются с вашим устройством.

• YouTube. Основной протокол — MPEG-DASH в вебе и на Android, HLS отдаётся на Safari, iOS, AirPlay и большинство смарт-ТВ. Почти весь контент — это CMAF: один набор fMP4-сегментов обслуживает оба манифеста. Кодеки: H.264 для совместимости, VP9 для большинства воспроизведений, AV1 для потоков высокого разрешения на поддерживаемых устройствах. Widevine и FairPlay DRM для фильмов/аренды ТВ; без шифрования для загрузок пользователей.
• Netflix, Disney+, Apple TV+, HBO Max, Prime Video. Все используют смесь HLS и DASH в зависимости от клиента, с CMAF как общим форматом сегмента. DRM обязателен — Widevine, FairPlay или PlayReady выбираются устройством. Кодеки включают H.264, H.265, AV1 и оверлеи Dolby Vision/Atmos. Лицензионные серверы проверяют регион, подписку и доверие к устройству при каждом воспроизведении. Netflix держит собственный CDN (Open Connect) внутри многих интернет-провайдеров.
• Twitch. Только HLS, причём сегменты .ts всё ещё встречаются наряду с CMAF. Live-трансляции имеют задержку от 2 до 5 секунд в low-latency-вариантах и от 15 до 30 секунд в стандартных. Сегменты без шифрования — модель защиты Twitch основана на идентичности и уровне аккаунта, а не на шифровании контента.
• Bigo Live, OnlyFans live, Chaturbate, Fansly. Live-стриминг на основе HLS, обычно с незашифрованными сегментами и короткими (2-секундными) фрагментами для низкой задержки. Воспроизведение в браузере использует hls.js или нативную поддержку HLS в Safari.
• Vimeo, Mux, Cloudflare Stream, JW Player. Хостинговые видеоплатформы. Они автоматически упаковывают загрузки в HLS и DASH и доставляют через свои CDN. Cloudflare Stream поставляет CMAF; Mux по умолчанию — HLS. DRM подключается по желанию для платных тарифов.
• Спорт и новости — ESPN, DAZN, BBC iPlayer, Sling TV. HLS или DASH с DRM, часто Widevine + FairPlay + PlayReady, упакованные вместе так, что одни и те же закодированные сегменты обслуживают любое устройство. Low-latency HLS (LL-HLS) — здесь тренд: задержка менее 3 секунд для live-событий, которые раньше отставали от эфира на 30 секунд.
• TikTok, Instagram Reels, YouTube Shorts. Короткие видео используют прогрессивную загрузку MP4 для самых коротких клипов и HLS или DASH для всего, что длиннее минуты. Те же варианты CDN и кодеков, что и у длинноформатных сервисов.

Разные поверхности, одна и та же машинерия. История — это повторение с вариациями: каждый сервис выбирает формат манифеста, кодировочную лестницу и комбинацию DRM, а затем гоняет один и тот же цикл «получить — декодировать — отрисовать» поверх миллиардов зрителей.

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

Знание конвейера делает очевидным один практический факт: нет единого файла для сохранения. «Видео», которое вы смотрите, восстанавливается вашим плеером из манифеста плюс нескольких сотен небольших сегментов, получаемых в реальном времени, декодируемых на лету и отбрасываемых по мере прихода следующих. Браузерное «Сохранить как» даёт вам манифест — крошечный текстовый файл без единого видеобайта внутри.

Ручной путь к воспроизводимому файлу долог. Получить и разобрать манифест (HLS .m3u8 или DASH .mpd). Выбрать правильный вариант — обычно самый высокобитрейтный, который сможет вместить ваше хранилище. Перечислить URL каждого сегмента. Получить их все (300+ запросов для 30-минутного видео при 6-секундных сегментах) до того, как подписанные URL истекут. Если присутствует EXT-X-KEY, получить ключ AES-128 и расшифровать каждый сегмент. Если поток защищён DRM, ничего из этого не сработает без CDM, способного выдать лицензию, — и даже тогда расшифрованные байты никогда не покидают защищённый модуль. Когда у вас есть обычные сегменты, ремультиплексируйте аудио и видео в один контейнер MP4 или MKV. Надейтесь, что вы правильно выбрали вариант; иначе повторите с другим.

Правильный инструмент сворачивает этот конвейер в одно пользовательское действие. VidMost разбирает манифесты HLS и DASH, выбирает доступный вариант наивысшего качества, скачивает сегменты параллельно с того же CDN, с которым уже общался ваш браузер, автоматически обрабатывает шифрование сегментов AES-128, поддерживает Widevine L3 для DRM-защищённых потоков там, где воспроизведение L3 доступно (качество может быть ограничено сервисом и уровнем DRM — премиум-платформы обычно ограничивают L3 разрешением 480p–720p), и ремультиплексирует всё в чистый MP4, готовый к воспроизведению в любом медиаплеере. Уровень протокола исчезает. Вы вставляете URL — получаете файл.

Для контента, который вы имеете законное право смотреть — лекции, за которые вы заплатили, прямые трансляции, которые вы хотите архивировать, ваши собственные трансляции, свободно лицензированные видео, — это весь рабочий процесс. Конвейер, который описывает эта статья, — это то, по чему инструмент построен ориентироваться от вашего имени.

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

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

• «Стриминг использует специальный протокол». Нет. Современный адаптивный стриминг работает поверх обычного HTTPS — того же протокола, что обслуживает HTML и JPEG. Манифесты и сегменты — статические файлы на CDN. «Протокол» в HLS или DASH — это лишь соглашение о том, что эти файлы содержат.
• «Файл скачивается, пока я смотрю». Не совсем. Сегменты скачиваются ровно вовремя для воспроизведения и удаляются, как только следующий уже в пути. На вашем устройстве никогда нет всего видео. Именно это делает «остановку сессии» эффективной и объясняет, почему стриминговая сессия ломается в момент, когда байты перестают поступать.
• «Большая пропускная способность = лучшее качество». Только если ваша пропускная способность стабильна. Канал 100 Мбит/с, проседающий до 2 Мбит/с на десять секунд, даёт вам худший опыт, чем стабильное соединение 8 Мбит/с. Кодировочная лестница тоже накладывает потолок — если самый высокий вариант 5 Мбит/с, любая пропускная способность сверх этого не покупает больше качества.
• «Буферизация означает медленный интернет». Иногда. Так же часто это слишком разреженная кодировочная лестница (ни один вариант не подходит к текущей пропускной способности), промах кэша на границе CDN, заторы в пирингах или медленная реакция ABR-алгоритма плеера. Буферизация — это плеер, просящий время, а не окончательный приговор скорости вашего соединения.
• «DRM — это то же, что и шифрование». Нет. Шифрование — это математическая операция: перемешанные байты, которые требуют ключа. DRM — это политическая система вокруг этого шифрования: лицензионный сервер, контролирующий выдачу ключа, доверенный исполняемый модуль, использующий ключ, и слой принуждения к контракту, решающий, какое устройство может воспроизводить какой контент. Шифрование — это замок; DRM — это сигнализация, распространение ключей и политика отзыва вместе взятые.
• «MP4 — это стриминговый формат». Нет. MP4 — это контейнер, формат файла, оборачивающий аудио, видео и метаданные. HLS и DASH — это стриминговые протоколы, и они могут переносить fMP4-сегменты. Обычный файл .mp4 не стримится, а скачивается прогрессивно. CMAF-сегменты, которые вы видите в HLS и DASH, происходят от MP4, но структурированы совершенно иначе.

Большая часть путаницы исчезает, как только вы внутренне принимаете конвейер. Стриминг — это файлы плюс тайминг, всё остальное — деталь.

Заключение

Интернет начал поставлять видео так же, как поставляет всё остальное: как файлы по HTTP. Затем он стал умнее в отношении того, какие файлы, в каком порядке, в каком качестве, с какого граничного кэша и декодируемые каким железом. Этот умный шаблон — манифест плюс сегменты плюс адаптивный битрейт плюс кэширование CDN — и есть вся причина, почему стриминг ощущается мгновенным, масштабируется до миллиардов зрителей и переживает грязную реальность реальных сетей. Никакого секретного протокола, никакого проприетарного сервера, никакой особой магии. Просто файлы, тайминг и очень хорошая инженерия по всему стеку.

Если вы предпочитаете полностью пропустить слой протокола и просто сохранить видео, VidMost обрабатывает HLS, DASH, fMP4, AES-128 и Widevine L3 в фоне — манифесты разобраны, сегменты получены, шифрование обработано, MP4 записан.

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

• Что такое HLS и M3U8? — дизайн «плейлист и сегменты», на котором держится большая часть стриминга.
• MPEG-DASH против HLS — когда каждый протокол выигрывает и почему большинство стриминговых сервисов поставляют оба.
• Адаптивный битрейт объяснён — логика ABR внутри каждого современного плеера.
• Контейнеры видео против кодеков — что на самом деле находится внутри сегмента.
• Что такое DRM-защищённый контент? — как Widevine, FairPlay и PlayReady контролируют премиум-потоки.