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

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

Кратко

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

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

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

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

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

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

Честный ответ: один файл передать нельзя. Даже если бы он у вас был, простую модель ломают сразу две проблемы. Первая: несжатое 30-минутное видео в разрешении 1080p весит примерно 200 гигабайт – отправить такое до того, как зрителю надоест, невозможно. Число, описывающее объём видеопотока за секунду воспроизведения и называемое битрейтом, рассчитывается как разрешение × глубина цвета × частота кадров. Для несжатого 1080p при 30 кадрах в секунду это 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 кадров в секунду достаточно примерно 4,5 Мбит/с. Это примерно в 330 раз меньше, чем объём несжатого видео.

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

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

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

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

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

Три ограничения, из-за которых видео не может сравниться с JPEG, – это время, порядок и качество. Эти параметры взаимосвязаны: если усилить один, остальные почти всегда страдают.

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

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

В качестве – картинка должна выглядеть приемлемо на устройстве с учётом условий сети. Здесь на помощь приходит adaptive bitrate streaming, или ABR. Энкодер создаёт не один поток, а целую «лестницу» – обычно от пяти до семи версий одного видео с нарастающим битрейтом и разрешением, например, от 360p при 600 кбит/с до 1080p при 4500 кбит/с. Файл-манифест – 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 минут

Сделаем ограничения более конкретными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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