Протоколы видеостриминга: RTMP, SRT, HLS, DASH, WebRTC — что выбрать для ваших задач

Автор: Роман Зенькин, старший системный аналитик EdgeЦентр

В видеостриминге используется не один протокол, а два разных: один доставляет поток от источника на сервер (ingest), второй раздаёт его зрителям (delivery). Для ingest сегодня выбирают RTMP или SRT, для delivery — HLS или DASH, а когда нужна задержка меньше секунды — WebRTC. Путать эти два класса нельзя: RTMP отлично работает как ingest и не работает как delivery, HLS наоборот.

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

Сравнение протоколов: сводная таблица

Если вам нужен быстрый ответ, какой протокол выбрать, он здесь. А ниже мы разберём всё, что обозначено в этой таблице, подробнее.

Уточнения к таблице: 

• Протоколы, основанные на HTTP, работают поверх TCP (HTTP/1.1 и HTTP/2) или QUIC (HTTP/3).
• Задержка HLS указана для классической реализации.
• Задержки в SRT и RIST зависят от размера буфера. Эти протоколы также применяются для контрибуции (ingest) между площадками.
• WebRTC поддерживает двустороннюю связь, а штатной поддержки DRM (защиты от копирования) в нём нет.

Низкая задержка и масштабируемость — противоположные требования. HLS и DASH дёшевы на миллионах зрителей, потому что это обычные HTTP-файлы, которые кешируются CDN. WebRTC даёт задержку меньше секунды, потому что не кешируется вообще, и каждому зрителю нужна отдельная сессия. Выбор протокола — это поиск компромисса между масштабируемостью и низкими задержками. Чтобы выбрать решение, которое идеально подойдёт для ваших задач, вам нужно определить оптимальное соотношение между лёгкостью масштабирования и задержками.

Ingest и delivery: почему это разные задачи

Путь видео от камеры до зрителя состоит из двух участков с принципиально разными требованиями.

Ingest (контрибуция) — доставка потока от источника (камеры, энкодера, OBS, аппаратного кодера на выезде) до вашей платформы. Здесь один отправитель и один получатель. Канал часто нестабильный: мобильный интернет с площадки события, спутник, публичный Wi-Fi. Главное требование — не потерять кадры и восстановиться после потерь пакетов. Масштабирование не нужно, так как соединение одно.

Delivery (дистрибуция) — раздача обработанного потока зрителям. Здесь один источник и от сотни до миллионов получателей на самых разных устройствах и сетях. Главное требование — масштабируемость и совместимость. Устойчивость к потерям решается буфером на стороне плеера.

Из этого следует, что протоколы, оптимальные для одного участка, плохи для другого. RTMP держит одно соединение и умеет быстро восстанавливаться. Но раздать через него видео миллионам зрителей невозможно: он не кешируется на CDN. HLS может раздавать поток на весь мир, потому что это статические файлы. Но использовать его для контрибуции бессмысленно, потому что он добавит задержку там, где она не нужна.

Между ingest и delivery есть ещё один этап — транскодинг и упаковка. Разберём его отдельно, потому что именно там принимаются решения, определяющие и качество, и стоимость.

Транскодирование: что происходит между ingest и delivery

Поток, пришедший от источника, нельзя раздать зрителям без изменений. Полученное видео проходит через 5 этапов.

1. Декодирование. Входящий поток распаковывается в несжатые кадры. Это самая ресурсоёмкая операция после кодирования.

2. Кодирование в несколько качеств. Из одного исходника формируется набор вариантов с разным разрешением и битрейтом — битрейтная лестница. Она нужна, чтобы зритель с нестабильным интернетом смотрел 480p, а зритель со стабильной оптикой — 4К, и оба не видели буферизации.

При этом таблица выше — это примерные значения, а не строго фиксированное правило, и многое зависит от конкретной ситуации. Например, для контента с малым количеством движения (лекция, презентация) битрейты можно снижать вдвое без потери качества, а для спорта и динамичных трансляций — наоборот повышать.

3. Нарезка на сегменты. Кодированный поток режется на файлы фиксированной длительности. Резать можно только по опорным кадрам, поэтому размер интервала между опорными кадрами (GOP) должен быть согласован с длиной сегмента, иначе точной нарезки не получится.

4. Упаковка и формирование плейлистов или манифестов. Сегменты складываются в контейнер и описываются в плейлисте или манифесте. Здесь же применяется шифрование, если используется DRM (технология защиты контента от копирования).

5. Публикация на раздачу. Файлы становятся доступны CDN.

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

Адаптивный битрейт: как плеер выбирает качество

Наличие лестницы само по себе ничего не даёт, нужен механизм переключения. Это и есть адаптивный битрейт (ABR, adaptive bitrate). Он реализуется на стороне плеера, а не сервера.

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

Логика решения строится на двух семействах алгоритмов:

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

Современные плееры комбинируют оба подхода: буферная логика как основа, оценка пропускной способности для быстрого старта.

Что из этого следует:

• Шаг между качествами не должен быть слишком большим. Если между 720p и 1080p разрыв в три раза, переключения будут резкими и заметными. Соседние ступени обычно разводят в 1,5–2 раза.
• Но слишком много вариантов — тоже плохо. Каждая ступень удорожает транскодинг и хранение, а плеер всё равно использует три-четыре из них. Пять ступеней покрывают почти все реальные сценарии.
• Верхняя ступень должна быть достижимой. Вариант 8K в лестнице, который не может загрузить почти никто из вашей аудитории, — это оплаченное впустую кодирование и хранение.

RTMP: почему он жив спустя двадцать пять лет

Real-Time Messaging Protocol создавался Macromedia в конце 1990-х для Flash Player. Flash умер в 2020 году, а RTMP — нет.

Как устроен. Постоянное TCP-соединение, поверх которого идут чанки (маленькие фрагменты) аудио, видео и метаданных. Поддерживает мультиплексирование — передачу нескольких потоков в одном соединении. Работает с кодеками H.264 и AAC.

Почему исчез из delivery. Требует Flash или специального плеера — ни один современный браузер не воспроизводит RTMP нативно. Постоянное соединение не кешируется CDN, а значит, каждый зритель нагружает сервер. Часто блокируется корпоративными файрволами, потому что использует нестандартный порт 1935.

Почему остался в ingest. Его поддерживают буквально все: OBS Studio, vMix, Wirecast, аппаратные энкодеры, мобильные приложения, камеры. Настройка сводится к двум полям — URL сервера и ключ потока. Задержка на участке контрибуции 2–5 секунд, чего для большинства сценариев достаточно.

О каких ограничениях стоит знать. RTMP работает поверх TCP, а TCP при потере пакета останавливает передачу до успешной повторной отправки. На плохом канале это даёт не деградацию качества, а замирание картинки. Кроме того, в классическом RTMP нет поддержки современных кодеков H.265 и AV1, и многоканальный звук через него не передать без расширений, поддержка которых у вендоров неполная.

Что в итоге. Оставляйте RTMP как основной или запасной вариант ingest ради совместимости. Не используйте его для раздачи зрителям.

SRT: контрибуция через ненадёжные сети

Secure Reliable Transport разработан Haivision, открыт в 2017 году и с тех пор стал фактическим стандартом для передачи видео через интернет там, где раньше нужны были выделенные каналы.

Как устроен. Работает поверх UDP, но добавляет собственный механизм восстановления потерь — ARQ (запрос повторной передачи). Ключевая идея: приёмная сторона держит буфер заданной длины и запрашивает переотправку потерянных пакетов, пока буфер позволяет. Разработчик сам выбирает компромисс между задержкой и устойчивостью, задавая размер буфера.

Что это даёт на практике. По каналу с потерей 5–10% пакетов (типичная мобильная сеть на мероприятии) SRT доставляет поток без видимых артефактов, тогда как RTMP на том же канале будет постоянно замирать. При этом задержка настраивается: от 200 мс для контролируемых каналов до 2 секунд для тяжёлых условий.

Какие дополнительные преимущества. Имеет штатное шифрование AES, передаёт любые кодеки (протокол не привязан к формату полезной нагрузки), поддерживает режимы caller, listener и rendezvous, позволяющие устанавливать соединение через NAT без проброса портов.

О каких ограничениях стоит знать. Не воспроизводится браузерами, не кешируется CDN, так как это протокол контрибуции, а не раздачи. Поддержка в оборудовании шире, чем несколько лет назад, но всё же уступает RTMP: старые энкодеры с ним не работают.

RIST: то же самое, но для вещателей

Reliable Internet Stream Transport решает ту же задачу, что SRT, и разработан консорциумом Video Services Forum как открытый стандарт.

Ключевое отличие — происхождение и позиционирование. RIST создавался вещательной индустрией и стандартизирован как открытая спецификация, тогда как SRT вырос из продукта одного вендора. Для телевещателей и операторов, у которых закупки завязаны на соответствие отраслевым стандартам, это имеет значение. Технические возможности при этом такие же, как у SRT: восстановление потерь, шифрование, работа через NAT.

Практический вывод. Если вы не телеканал и не оператор связи, выбирайте SRT. У него шире экосистема и больше документации. Если вы работаете с вещательным оборудованием, проверьте, что поддерживает ваш парк: возможно, RIST окажется единственным доступным вариантом.

HLS: стандарт, на котором держится индустрия

HTTP Live Streaming создан Apple в 2009 году и сегодня остаётся самым распространённым протоколом доставки видео.

Как устроен. Поток нарезается на короткие сегменты — файлы по 2–10 секунд. Формируется текстовый плейлист .m3u8, где перечислены сегменты. Плеер скачивает плейлист, затем сегменты по очереди обычными HTTP-запросами.

Гениальность решения в его простоте: для сети это не видео, а последовательность статических файлов. Их кеширует любая CDN, они проходят через любой файрвол, их отдаёт любой веб-сервер. Именно поэтому HLS масштабируется на миллионы зрителей без специальной инфраструктуры.

Двухуровневая структура плейлистов. Мастер-плейлист перечисляет доступные варианты качества, каждый со своим битрейтом и разрешением. Плеер выбирает подходящий и обращается к медиа-плейлисту этого варианта, где уже перечислены конкретные сегменты. Такая структура и делает возможным адаптивный битрейт.

Как выглядит плейлист изнутри

Мастер-плейлист — обычный текстовый файл. Ничего бинарного, всё читаемо:

Медиа-плейлист конкретного варианта перечисляет уже сами сегменты:

Что здесь важно на практике:

• BANDWIDTH должен указывать пиковый, а не средний битрейт варианта. Занижение приводит к тому, что плеер выбирает слишком тяжёлый вариант и уходит в излишнюю буферизацию.
• CODECS обязателен для корректной работы на Apple-устройствах. Плеер по нему определяет, сможет ли он вообще воспроизвести вариант, не скачивая сегменты.
• EXT-X-TARGETDURATION — максимальная длительность сегмента, округлённая вверх. Плеер использует её для расчёта интервала перезагрузки плейлиста.
• EXT-X-MAP указывает на файл инициализации — признак того, что используется fMP4, а не MPEG-TS.
• Отсутствие EXT-X-ENDLIST означает прямой эфир: плеер будет периодически перезапрашивать плейлист в ожидании новых сегментов. Для VOD этот тег обязателен, иначе плеер не поймёт, что запись закончилась.

Формат контейнера. Исторически сегменты были в MPEG-TS — формате, унаследованном от цифрового телевидения с накладными расходами около 10%. Современный HLS использует fMP4 (fragmented MP4), он же CMAF. Практический выигрыш от перехода огромен: те же сегменты подходят и для HLS, и для DASH, то есть не нужно хранить две копии библиотеки.

Задержка. Главный недостаток классического HLS. Она складывается из длины сегмента, умноженной на количество сегментов, которые плеер буферизует перед стартом. При сегментах по 6 секунд и буфере в три сегмента задержка составит 18 секунд минимум, а на практике — 20–45 секунд. Для VOD это неважно, для прямого эфира — критично.

LL-HLS решает эту проблему тремя механизмами: 

1. частичными сегментами: плеер получает куски по 200–500 мс, не дожидаясь завершения полного сегмента;
2. блокирующей перезагрузкой плейлиста: сервер удерживает запрос, пока не появится новая часть вместо периодического опроса;
3. подсказками предзагрузки.

Результат — 2–5 секунд при сохранении всей совместимости с CDN.

MPEG-DASH: открытый стандарт с той же логикой

Dynamic Adaptive Streaming over HTTP — стандарт ISO, опубликованный в 2012 году. Принцип тот же: сегменты плюс манифест, доставка по HTTP.

Ключевые отличия от HLS:

• Манифест в XML (.mpd) вместо текстового плейлиста. Он выразительнее: описывает периоды, наборы адаптации, представления, шаблоны сегментов — но и тяжелее для разбора.
• Не привязан к кодекам. HLS исторически ориентирован на H.264 и H.265, DASH формально принимает любой кодек, включая AV1 и VP9.
• Родная поддержка Common Encryption (CENC). Это даёт удобную работу с Widevine и PlayReady. По сути, DASH и есть основной транспорт для этих DRM-систем.
• Не поддерживается нативно на устройствах Apple. Это и есть причина, по которой DASH не вытеснил HLS: на iOS и tvOS без HLS не обойтись.

Как устроен манифест MPD

В отличие от плоского плейлиста HLS, манифест DASH — иерархический XML. Упрощённо структура выглядит так:

Что даёт эта структура на практике:

• Period позволяет описать несколько независимых участков в одной презентации. Именно так вставляют рекламные блоки: отдельный период со своим контентом, не ломающий основной поток.
• AdaptationSet группирует взаимозаменяемые варианты. Видео, аудио на разных языках, субтитры — это отдельные наборы. Плеер комбинирует их независимо. В HLS многоязычное аудио описывается заметно менее изящно.
• SegmentTemplate задаёт правило формирования имён вместо перечисления каждого сегмента. Для длинного фильма это разница между манифестом в килобайт и манифестом в сотни килобайт.
• type="static" против "dynamic" различает VOD и прямой эфир — аналог EXT-X-ENDLIST в HLS.

Практический вывод. Если вы отдаёте контент на все платформы и используете DRM, вам понадобятся оба: DASH с Widevine и PlayReady для Android, Windows и браузеров, HLS с FairPlay для устройств Apple. Это не дублирование работы, если вы используете CMAF — сегменты общие, различаются только манифесты.

CMAF: как перестать хранить две копии

Common Media Application Format — не протокол, а формат контейнера, и он решает главную экономическую проблему мультиформатной доставки.

До CMAF отдача и в HLS, и в DASH означала два набора сегментов: MPEG-TS для первого, fMP4 для второго. Библиотека занимала вдвое больше места, транскодинг выполнялся дважды, а CDN кешировал две независимые копии — то есть процент попадания в кеш эффективно делился надвое.

С CMAF сегменты общие. Различаются только манифесты — текстовый .m3u8 и XML .mpd, которые весят килобайты и указывают на одни и те же файлы.

Экономия прямая: вдвое меньше объём хранения, вдвое меньше нагрузка на транскодинг, лучше эффективность кеша. Для библиотеки в несколько тысяч часов это заметные деньги.

Отдельно CMAF даёт chunked-передачу, на которой построены и LL-HLS, и LL-DASH.

WebRTC: когда нужна задержка меньше секунды

Web Real-Time Communication создавался для видеозвонков — двусторонней связи в браузере без плагинов. Отсюда все его свойства.

Как устроен. Работает поверх UDP, использует SRTP для медиа, ICE и STUN/TURN для установки соединения через NAT. Соединение устанавливается между конкретными участниками — это его сила и его ограничение.

Что даёт:

• Задержка 200–800 миллисекунд, то есть практически реальное время.
• Двусторонняя связь: зритель может не только смотреть, но и говорить.
• Нативная поддержка во всех современных браузерах без плеера и плагинов.

Какова цена. WebRTC не кешируется, и это делает его в разы дороже HLS и DASH. Каждому зрителю нужна отдельная медиа-сессия на сервере. Раздача на 10 000 зрителей требует кластера медиасерверов (SFU) и стоит на порядок дороже, чем HLS на ту же аудиторию. Кроме того, адаптация качества работает иначе и грубее, чем ABR в HLS, а штатной поддержки DRM нет.

Когда WebRTC оправдан:

• Ставки и аукционы в реальном времени, где задержка в 5 секунд означает финансовые потери.
• Интерактивные форматы, где зрители выходят в эфир.
• Видеосвязь, телемедицина, удалённое управление.
• Игровые и торговые интерфейсы, где картинка синхронизирована с действием.

Когда это дорогая ошибка: 

• Вебинары и конференции на тысячи зрителей
• Концерты и спортивные трансляции без интерактива
• Любой другой сценарий, где зритель просто смотрит

Во всех этих случаях задержка в 3–5 секунд никого не беспокоит, а LL-HLS обойдётся в разы дешевле.

Кодеки: чем кодировать поток

Протокол определяет, как видео доставляется. Кодек — как оно сжато. Это независимые решения, но связанные: не все кодеки одинаково поддерживаются на всех платформах.

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

Для прямого эфира это работает иначе: там кодирование идёт в реальном времени постоянно, и запас по вычислительным ресурсам должен быть всегда. Поэтому в live-сценариях H.264 держится дольше, чем в VOD.

Совместимость с протоколами. DASH формально принимает любой кодек. HLS исторически ориентирован на H.264 и H.265, поддержка остальных зависит от устройства. Значит, если вы отдаёте AV1 или VP9, обязательно держите параллельную лестницу H.264 как запасную, иначе часть аудитории не увидит ничего.

Задержка: из чего складывается и как сократить

Понимание бюджета задержки важнее выбора протокола, так как часто оказывается, что протокол ни при чём.

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

Но есть и обратная сторона. Короткие сегменты означают больше HTTP-запросов, выше накладные расходы и большую нагрузку на CDN. Сегмент в 1 секунду вместо 6 увеличивает число запросов в шесть раз. Так что это компромисс, а не бесплатное улучшение.

Дерево решений: какой протокол под какую задачу

Тонкости выбора: на что ещё обратить внимание, кроме задержки

Целевые устройства. Если в аудитории есть iPhone, iPad или Apple TV — HLS обязателен, альтернатив нет. Smart TV разных вендоров поддерживают разный набор: перед запуском проверьте на реальных устройствах, а не по документации.

Требования к защите контента. Лицензионный контент студий требует multi-DRM, а это фактически предопределяет связку DASH с Widevine и PlayReady плюс HLS с FairPlay. Для собственных видеокурсов часто достаточно подписанных ссылок с ограниченным сроком жизни.

Бюджет на инфраструктуру. Разница в стоимости между HLS и WebRTC на аудитории в 50 000 исчисляется десятками раз. Считайте до выбора архитектуры, а не после.

Наличие компетенций. HLS с CDN эксплуатируется силами обычной команды разработки. Кластер медиасерверов WebRTC требует людей, которые умеют его чинить в три часа ночи.

Резервирование. Для критичных эфиров планируйте два независимых ingest-потока и переключение между ними. Протокол здесь вторичен: важно, чтобы платформа умела принимать резервный поток и переключаться без разрыва у зрителей.

HTTP-протоколы: почему они масштабируются, а остальные нет

Это главное свойство, определяющее экономику всего стриминга, поэтому давайте остановимся здесь подробнее.

Сегмент HLS или DASH — это обычный файл, запрошенный обычным GET-запросом. Для CDN он ничем не отличается от картинки. Отсюда следует всё остальное:

• Сегмент кешируется. Первый зритель в регионе инициирует его загрузку на узел, все остальные получают из кеша. При тысяче одновременных зрителей в городе ваш сервер отдаёт сегмент один раз, а не тысячу.
• Нагрузка на источник не зависит от числа зрителей. Она зависит от числа регионов и от длины сегмента. Это принципиально другая математика: аудитория растёт в сто раз, нагрузка на origin — нет.
• Работает везде. Порт 443, обычный HTTPS. Проходит корпоративные файрволы, прокси, мобильные сети без исключений.

Для прямого эфира есть нюанс: сегменты появляются постоянно, и каждый новый сегмент — это гарантированный cache miss в каждом регионе. Чем короче сегменты, тем чаще промахи. Именно здесь особенно полезен шилдинг: промежуточный узел собирает запросы от всех edge-серверов и обращается к вашему источнику один раз вместо десятков.

Важно понимать, что на live-трансляции cache hit ratio (процент попадания в кеш) 95%+ достижим и является нормой. Если он заметно ниже, ищите причину в заголовках кеширования сегментов или в неправильно настроенном ключе кеша, например, когда в URL сегмента попадают уникальные параметры сессии, и каждый зритель получает «свой» уникальный файл.

Диагностика: как понять, что с потоком что-то не так

Мы приведём базовый набор проверок, который стоит уметь делать до обращения в поддержку.

Что внутри потока. ffprobe показывает кодеки, разрешение, битрейт и структуру:

Список вариантов и их битрейты. Мастер-плейлист достаточно просто скачать и прочитать:

Проверьте, что заявленные BANDWIDTH соответствуют реальности и что список вариантов тот, который вы настраивали.

Отдаются ли сегменты из кеша. Ключевая проверка для live: если каждый сегмент — промах, нагрузка идёт на ваш сервер:

Реальная длительность сегментов. Расхождение заявленного EXTINF и фактической длительности — частая причина рассинхрона аудио и видео:

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

Резервирование: что ломается на живом эфире

Выбор протокола не спасёт трансляцию, если рядом нет резерва. Разберём самые частые точки отказа от источника к зрителю.

Точка 1: источник. Камера, ноутбук с OBS, аппаратный энкодер. Отказ — потеря картинки целиком. Резерв: вторая камера и второй энкодер, готовые к переключению. Для ответственных эфиров нужны два независимых оператора.

Точка 2: канал контрибуции. Самое слабое звено на выездных мероприятиях. Отказ — обрыв или деградация до неприемлемого качества. Резерв: два независимых канала — например, проводной плюс агрегированный мобильный от разных операторов. Здесь SRT даёт преимущество: он переживёт то, на чём RTMP сдастся.

Точка 3: приём на платформе. Резерв: два ingest-эндпоинта, желательно в разных дата-центрах. Платформа должна уметь принимать основной и резервный поток одновременно и переключаться между ними, не разрывая сессию у зрителей. Это свойство платформы, которое надо проверить заранее, а не в момент аварии.

Точка 4: транскодинг. Отказ — эфир идёт, но зрители не получают вариантов качества. Резерв: дублирование транскодера с автоматическим переключением.

Точка 5: раздача. Отказ CDN или его региона. Резерв: второй CDN-провайдер с переключением на уровне DNS или логики плеера. Оправдано для эфиров, где цена простоя высока.

Точка 6: плеер. Отказ — ошибка воспроизведения на части устройств. Резерв: корректная обработка ошибок в плеере, автоматический повтор, откат на запасную лестницу H.264.

Если предстоит ответственный эфир, проведите полную репетицию за сутки до события. Отдельно отрепетируйте переключение на резервы, чтобы чётко знать, что делать при аварии.

Минимальный набор, который стоит настроить даже для рядовых трансляций: 

• Два ingest-потока и автоматическое переключение при пропадании основного.
• Запись эфира на случай, если раздача всё-таки прервалась.

Запись превращает провалившийся эфир в VOD-материал и спасает мероприятие.

Типичные ошибки при выборе протокола

1. Взять WebRTC ради «низкой задержки», не посчитав стоимость. Самая дорогая ошибка в этом списке. На вебинаре задержка в 4 секунды никому не мешает, а затраты различаются в разы.
2. Отдавать только DASH. Устройства Apple его не воспроизводят нативно. Часть аудитории просто не увидит контент.
3. Использовать RTMP для раздачи зрителям. Работало до 2020 года, пока был Flash. Сейчас не воспроизводится браузерами.
4. Резать сегменты по 1 секунде «на всякий случай». Число запросов вырастает шестикратно, растёт нагрузка на CDN (и расходы, если модель тарификации основана на количестве запросов), а выигрыш в задержке нужен не всем.
5. Не согласовать GOP с длиной сегмента. Нарезка возможна только по опорным кадрам. Несогласованность даёт плавающую длительность сегментов и рассинхрон.
6. Не оставить запасной ingest. Единственный RTMP-поток с одной точки — гарантированный обрыв эфира при проблеме с каналом.
7. Хранить две копии библиотеки для HLS и DASH. Решается переходом на CMAF, экономит половину объёма хранения и половину транскодинга.
8. Выбрать протокол до того, как определены целевые устройства. Список платформ, на которых видео должно быть доступно, определяет решение сильнее, чем любые технические предпочтения.

Часто задаваемые вопросы

Какой протокол выбрать для стриминга? Для доставки зрителям в большинстве случаев — HLS, а при требовании к низкой задержке — LL-HLS. Для приёма потока от источника — RTMP ради максимальной совместимости или SRT, если канал нестабильный. WebRTC нужен только там, где задержка должна быть меньше секунды и есть интерактив: ставки, аукционы, двусторонняя связь.

Чем отличается HLS от RTMP? Это протоколы для разных задач. RTMP доставляет поток от источника на сервер по постоянному TCP-соединению и не воспроизводится браузерами. HLS раздаёт видео зрителям в виде последовательности статических файлов по HTTP, кешируется CDN и поддерживается всеми устройствами. RTMP используют как ingest, HLS — как delivery.

Какая задержка у HLS? У классического HLS — от 15 до 45 секунд. Она определяется в основном длиной сегмента и глубиной буфера плеера, а не скоростью сети. LL-HLS с частичными сегментами и блокирующей перезагрузкой плейлиста снижает задержку до 2–5 секунд, сохраняя совместимость с CDN.

Что лучше — HLS или DASH? Они решают одну задачу и близки по возможностям. HLS обязателен, если в аудитории есть устройства Apple, — там он единственный вариант. DASH удобнее при использовании Widevine и PlayReady и не привязан к конкретным кодекам. На практике крупные сервисы отдают оба, используя CMAF, чтобы сегменты были общими и не приходилось хранить две копии.

Зачем нужен SRT, если есть RTMP? SRT устойчив к потерям пакетов, тогда как RTMP на плохом канале замирает. При потере 5–10% пакетов, что типично для мобильной сети на выездном мероприятии, SRT доставит поток без видимых артефактов. Кроме того, SRT штатно шифрует поток, настраивает компромисс между задержкой и надёжностью и передаёт любые кодеки, включая H.265 и AV1.

Можно ли раздавать видео через WebRTC на большую аудиторию? Технически да, экономически чаще всего нет. WebRTC не кешируется CDN, каждому зрителю нужна отдельная сессия на медиасервере. Раздача на десятки тысяч зрителей требует кластера медиасерверов и обходится на порядок дороже, чем HLS на ту же аудиторию. WebRTC оправдан, когда задержка меньше секунды принципиальна.

Что такое CMAF и зачем он нужен? Это общий формат контейнера для сегментов, позволяющий использовать один набор файлов и для HLS, и для DASH. Различаются только манифесты. Без CMAF пришлось бы хранить две копии всей библиотеки, дважды выполнять транскодинг и держать в кеше CDN два независимых набора сегментов.

Какой длины должны быть сегменты? Классический ориентир — 6 секунд, это компромисс между задержкой и накладными расходами. Для низкой задержки используют 1–2 секунды или частичные сегменты LL-HLS по 200–500 мс. Помните о цене: сегменты в 1 секунду вместо 6 увеличивают число HTTP-запросов в шесть раз, что повышает нагрузку на CDN и стоимость по модели тарификации за запросы.

Нужен ли CDN для видеостриминга? Для HLS и DASH — да, практически всегда. Именно кеширование сегментов на узлах делает возможной раздачу на большую аудиторию: без CDN весь трафик идёт с вашего сервера, и он упрётся в канал задолго до интересных цифр. Для WebRTC обычный CDN не применим — там нужна инфраструктура медиасерверов.

Работает ли RTMP в браузере? Нет. RTMP требовал Flash Player, поддержка которого прекращена в 2020 году. Ни один современный браузер не воспроизводит RTMP нативно. Именно поэтому RTMP остался только на участке ingest, где браузер не нужен, а для доставки зрителям используются HLS и DASH.