Что такое доставка видео и почему это сложнее, чем отдать JPEG

Опубликовано: 2026-05-20 · Время чтения: 16 мин · Автор: Николай Сапунов, CEO Фора Софт

Кратко

Доставка видео – это дисциплина о том, как доставить движущуюся картинку с камеры на экран зрителя вовремя, по порядку и в нужном качестве, чаще всего через сети, которыми издатель не управляет. Фотография уходит с сервера один раз – и всё; видео должно приходить и приходить по 24, 30 или 60 кадров в секунду в течение всего эфира, нередко миллионам зрителей одновременно, нередко в прямом эфире. Вся индустрия – кодеки, сегментаторы, упаковщики, CDN, адаптивные плееры, декодеры – существует, чтобы этот непрерывный, упорядоченный конвейер реального времени выдерживал реалии публичного интернета. К концу статьи вы сможете нарисовать пайплайн стриминга на салфетке и сказать, где он обычно ломается первым.

Зачем эта статья

Если вы решаете, стоит ли запускать стриминговый продукт, оцениваете подряд, считаете бюджет CDN или просто хотите перестать вежливо кивать инженерам – это ваша база. Все следующие статьи раздела «Видеостриминг» – про HLS, DASH, WebRTC, про бюджеты задержки, про адаптивный битрейт, про мультиCDN-архитектуры – исходят из того, что эта модель у вас уже в голове. Мы писали этот материал в первую очередь для умного нетехнического читателя; старший инженер по стримингу при этом должен подписаться под каждым фактом. Если на пятом абзаце станет очевидно – вы сэкономите время на всём остальном.

Самое простое сравнение: фото и видео

Представьте, что вы выложили на сайт одну фотографию – JPEG с чашкой кофе. Браузер где-то делает запрос. Сервер читает файл с диска, отдаёт около двухсот килобайт байт по сетевому соединению, и браузер один раз рисует картинку. Вся сделка длится несколько сотен миллисекунд. Если сеть на секунду стряхнётся, картинка появится чуть позже. Никто не жалуется. Работа закончена в тот момент, когда пришёл последний байт.

А теперь представьте ту же чашку, но снятую: 30-минутное живое кулинарное шоу в 1080p и 30 кадрах в секунду. Браузер запрашивает «видео». Что отдать?

Честный ответ: один файл отдать нельзя. Даже если бы он у вас был, простую модель ломают сразу две проблемы. Первая: несжатое 30-минутное 1080p-видео весит примерно 200 гигабайт – отправить такое до того, как зрителю надоест, невозможно. Число, которое описывает размер видеопотока за секунду воспроизведения и называется битрейтом, считается как разрешение × глубина бит × частота кадров. Для несжатого 1080p при 30 fps это 1920 × 1080 × 24 бит × 30 ≈ 1,49 Gbps, то есть около 187 мегабайт каждую секунду или 5,6 гигабайт в минуту. Самый быстрый домашний интернет выдержит крошечную долю. Вторая: в прямом эфире файла ещё нет – повар продолжает готовить.

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

Четыре работы стримингового пайплайна

Любой стриминговый пайплайн – от одного канала на Twitch до Netflix в восьми регионах – последовательно выполняет одни и те же четыре работы. Назовём их: захват (capture), кодирование (encode), доставка (deliver) и воспроизведение (play). За каждую отвечает свой класс инженеров, и у каждой свой типичный первый отказ.

Захват – момент, когда реальная сцена становится цифровым сигналом: сенсор камеры сэмплирует свет, микрофон сэмплирует звук. На выходе – несжатые пиксели и звуковые сэмплы. Здесь происходят и первые продакшн-факапы: отвалившийся HDMI, расфокусированный объектив, слишком тихий микрофон. Что испортилось здесь – ниже по конвейеру уже не починить.

Кодирование – это превращение несжатого видео в поток, который вообще можно отправить. Программа под названием кодек (от coder-decoder) сжимает сырые пиксели, используя два вида избыточности: пространственную (внутри одного кадра много областей похожего цвета) и временную (соседние кадры обычно отличаются лишь движущимися объектами). Современные кодеки – H.264, H.265, AV1, VVC, плюс старый MPEG-2, до сих пор живущий в эфирном вещании. Подробно мы разбираем кодеки в разделе Video Encoding. Пока удержите одно число: хорошо настроенному H.264 1080p при 30 fps достаточно около 4,5 Mbps. Это примерно в 330 раз меньше, чем несжатой версии выше.

Доставка – часть, которую большинство недооценивает. Сюда входит упаковка закодированного потока в дружественные сети куски, распределение этих кусков через сеть доставки контента – сокращённо CDN, цепочку серверов рядом со зрителями, – и реакция на сетевые условия в реальном времени. Вся протокольная лексика живёт здесь: HLS, DASH, CMAF, WebRTC, MoQ, SRT, RTMP. Каждый из них – рецепт того, как двигать сжатое видео через определённый тип сети с определённым целевым латенси.

Воспроизведение – это приложение или браузер зрителя, которые делают четыре вещи одновременно: тянут следующий кусок, решают, поднимать или опускать качество, декодируют кусок и рисуют кадры точно в нужный момент. Плеер – больше кода, чем кажется. Современные веб-плееры hls.js, Shaka Player и dash.js – это десятки тысяч строк, со своими стейт-машинами, политиками буферизации и восстановлением после ошибок.

Захват – это железо. Кодирование – математика. Доставка – сеть. Воспроизведение – софт. Дисциплина видеостриминга – это искусство держать все четыре работы синхронно, по порядку, со скоростью, которую ждёт глаз.

Нажмите, чтобы увеличить

Что на самом деле означает «вовремя, по порядку и в качестве»

Три ограничения, делающие видео не равным JPEG, – это время, порядок и качество. Они не независимы. Если потянуть одно – другие почти всегда ослабнут.

Вовремя – каждый кадр должен быть готов к показу ровно в свой момент. 30 fps даёт плееру 33 миллисекунды на кадр; 60 fps – 16. Если следующий кадр к этому моменту не декодирован, зритель видит предыдущий – это и есть видимый stutter, ночной кошмар любого стримингового инженера. Концепция плеерного буфера существует именно для того, чтобы поглощать джиттер – вариацию времени прихода соседних пакетов, – чтобы у декодера всегда был готов следующий кадр. Типичный HLS-плеер несёт буфер 6–30 секунд; WebRTC-плеер – 50–500 миллисекунд. Чем короче буфер, тем ниже сквозная задержка – и тем меньше запас на любую сетевую дрожь.

По порядку – плеер обязан показать кадр 100 после 99 и до 101. Транспортный протокол под капотом относится к этому очень серьёзно. TCP, надёжный байтовый протокол, на котором построен веб, повторно перешлёт потерянный пакет и подождёт его до того, как выдать следующий; это ожидание стоит latency. UDP, который использует WebRTC, ждать не будет – он попросит плеер обойтись тем, что пришло. Выбор между TCP и UDP – основа любого протокола в этой области. Развернёт тему статья TCP, UDP и выбор, который делает каждый стриминговый протокол.

В качестве – картинка должна выглядеть приемлемо на устройстве с учётом сети. Здесь появляется adaptive bitrate streaming, сокращённо ABR. Энкодер выпускает не один поток, а лестницу – обычно пять–семь версий одного видео в нарастающем битрейте и разрешении, скажем, 360p на 600 kbps вплоть до 1080p на 4500 kbps. Файл-манифест – playlist в HLS и MPD в DASH – перечисляет все ступени. Плеер постоянно мерит фактическую скорость загрузки и выбирает максимально высокую ступень, которую удерживает. Когда качество падает в электричке и снова растёт дома – это работает ABR. Механику разбирает статья про adaptive bitrate streaming.

Live, VOD и бюджет задержки

На одном и том же пайплайне живут два больших семейства стриминга, и ведут они себя очень по-разному.

Video on demand (VOD) – контент существует целиком до того, как кто-то нажал play: серия Netflix, записанная лекция, ролик на YouTube. Дедлайна нет, поэтому система может в своё удовольствие закодировать несколько ABR-лестниц, заранее упаковать каждый сегмент, разогнать всё по краям CDN и дать плееру буферизовать с запасом. Задержка для VOD – не ограничение; ограничения – качество, стоимость и надёжность.

Live-стриминг – контент рождается, пока зритель смотрит: концерт, футбольный матч, экстренные новости. Теперь к каждому шагу пайплайна прибит таймер. Энкодер работает в реальном времени; упаковщик режет сегменты, пока камера ещё снимает; CDN должен распространять свежие сегменты до того, как они устареют; плеер обязан держать буфер достаточно тонким, чтобы ощущаться «лайвом», но достаточно толстым, чтобы пережить чихающий Wi-Fi-роутер. Между ними – категория near-live: новости с задержкой 30 секунд; спорт с «букмекерской» задержкой; live shopping. Сравнение всех трёх – в статье Live, VOD и near-live.

Главное число, на котором живёт каждый стриминговый инженер, – latency, разница во времени между тем, что произошло в реальном мире, и моментом, когда зритель это увидел. Стандартная мера – glass-to-glass latency, от объектива до глаза по всему пайплайну. Классический HLS-стек обычно даёт 20–30 секунд. Low-Latency HLS, современный стек Apple, – 2–5 секунд. WebRTC-доставка – 200–500 миллисекунд. Каждый шаг вниз стоит инженерной сложности и нередко реальных денег. Бюджет мы раскладываем в статье Задержка, glass-to-glass, end-to-end.

Почему интернет делает это сложнее, чем кажется

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

Во-первых, сеть, на которой вы публикуете, – не та сеть, через которую смотрит зритель. Вы управляете своим origin-сервером; вы не управляете мобильным оператором зрителя, его Wi-Fi-роутером, перегруженным аплинком кофейни и подводным кабелем между Сингапуром и Марселем. Реальное продакшн-видео должно выдерживать колебания пропускной способности на порядок, всплески packet loss при перегрузке соты и джиттер, который растёт на каждом разделяемом линке.

Во-вторых, форму архитектуры задаёт масштаб. Раздавать одному зрителю с одного сервера – нормально для хобби-проекта. Раздавать миллиону зрителей с одного сервера невозможно: сетевая карта не выпихнет столько бит, диски не прочитают столько сегментов, а трафик у origin разорит вас. CDN решает это, копируя сегменты на edge-серверы в сотнях городов, и большинство запросов отвечает близко к зрителю. Один edge Cloudflare или Akamai раздаёт тысячи одинаковых потоков из одной кэшированной копии. Топологию мы разбираем в статье Что такое CDN глазами стримингового инженера.

В-третьих, устройства разные. Один и тот же поток обязан проиграться на iPhone с Safari, Android-телефоне с Chrome, smart-TV на webOS, Xbox, Roku, ноутбуке с браузером и десятилетнем Samsung в гостинице. У каждого – своё подмножество поддерживаемых кодеков, протоколов и DRM-систем. Задача стриминговой команды – выпустить достаточно вариантов и достаточно протоколов, чтобы покрыть матрицу устройств, не взорвав счёт за хранение.

Прикинем на числах: 1 поток, 1 миллион зрителей, 90 минут

Сделаем ограничения осязаемыми.

Спортивный live-матч идёт 90 минут. Издатель целится в пиковую аудиторию 1 миллион одновременных зрителей по ABR-лестнице со средним рендиционом 4 Mbps. Одновременный исходящий трафик откуда-то:

1 000 000 зрителей × 4 000 000 бит/с = 4 000 000 000 000 бит/с
= 4 терабита в секунду

Современная сетевая карта на 100 гигабит держит 100 Gbps. Чтобы вытолкнуть этот трафик с одного origin, нужно 40 таких карт под завязку, и такой машины не существует. Этот расчёт – причина, по которой любой серьёзный live-эвент идёт через CDN: 4 Tbps, размазанные, скажем, по 200 edge-городам, – это 20 Gbps на город, что в норме укладывается в edge-кластер, особенно с кэшированием. За все 90 минут матча данных уехало:

4 Tbps × 5400 с = 21 600 Tb = 2,7 петабайт

Это «вся Библиотека Конгресса», переданная дважды, за один вечер. Поэтому экономика CDN – отдельная интересная тема; разбираем в CDN cost economics.

Картинка стоит тысячи страниц спеки

Стриминговый пайплайн на одной диаграмме выглядит обманчиво просто. Правда прячется в стрелках.

Обратите внимание: доминирует именно буфер плеера. Все прочие этапы – миллисекунды, буфер – секунды. Уменьшение буфера – главный рычаг для низкой задержки и самый быстрый способ получить подвисания, если ошибиться в оценке сети.

Типичная ошибка: «давайте просто зальём MP4»

Первый порыв любого толкового инженера, новичка в видео, – залить один MP4 и натравить на него тег <video>. Работает. MP4 играет. Инженер решает, что стриминг – это тривиально.

Тривиально – ровно до тех пор, пока не наступило что-то из следующего:

• больше одного зрителя нажимает play одновременно на медленной сети;
• зритель на мобильнике, и картинка зависает на третьей рекламной паузе;
• другой зритель – на старом Samsung TV, который не понимает AV1;
• контент в эфире и стартует до того, как загрузка закончилась;
• зритель прыгает к 47-й минуте двухчасового видео;
• юристы просят зашифровать поток, чтобы его нельзя было скачать.

Паттерн «MP4 + <video>» ломается ровно тогда, когда аудитория или сценарий перестают быть тривиальными. Вся индустрия – ABR-лестницы, сегментированные протоколы, CDN, адаптивные плееры, DRM, мультиCDN-стиринг – существует потому, что продакшн-видео на масштабе – это не та же задача, что JPEG.

Где здесь Фора Софт

Фора Софт с 2005 года строит видеостриминг, WebRTC, конференц-связь, OTT, e-learning, телемедицину, видеонаблюдение и AR/VR-продукты – больше 239 завершённых проектов. Пайплайн, описанный выше, для нас не учебник, а схема на первой доске на любом проекте. Мы помогаем клиентам выбирать протоколы и CDN под целевой бюджет задержки, проектировать адаптивные плееры, которые аккуратно восстанавливаются на плохих сетях, и выходить на матрицу устройств без двойной оплаты за один и тот же контент. Если вы оцениваете стриминговый продукт и хотите второго мнения – мы с радостью прочитаем архитектуру и скажем, где она ляжет первой.

Ключевые мысли

• Видео – это упорядоченный во времени непрерывный поток; JPEG – одноразовый файл.
• В любом стриминговом пайплайне четыре работы: захват, кодирование, доставка, воспроизведение.
• Сжатие делает битрейт подъёмным; ABR помогает качеству выживать на плохих сетях.
• Задержка, порядок и качество всегда обмениваются друг на друга при выборе протокола.
• CDN и многоуровневый origin существуют потому, что ни один сервер не отдаст миллион live-зрителей.
• Самая простая модель – «залить MP4» – ломается, как только в кадре появляются аудитория, устройства или live-дедлайн.

Что читать дальше

• Live, VOD и near-live: три задачи, которые выглядят одинаково, но решаются по-разному
• Задержка, glass-to-glass, end-to-end: что именно означают эти секунды
• Полный пайплайн стриминга, от и до

CTA: Поговорить с инженером по стримингу · Смотреть наши кейсы · Скачать шпаргалку по пайплайну стриминга (PDF)