RTMP в 2026: мёртвый протокол, бессмертный дефолт

Последняя сверка: 2026-05-20 со спецификацией Adobe RTMP 1.0 (21 декабря 2012, архив на rtmp.veriskope.com), релизной версией Enhanced RTMP v2 от Veovera Software Organization (2024), опубликованным сравнением протоколов ingest для YouTube Live, документацией Twitch Inspector, инженерными постами Wowza, Mux и Cloudflare, а также с актуальным статусом поддержки RTMP в OBS Studio 32, FFmpeg 7 и крупнейших соцплатформах.

TL;DR

RTMP – это TCP-протокол контрибьюции, который Macromedia выпустила в 2002 году, Adobe формально опубликовала в 2012-м, и за 24 года никто не смог выгнать его из экосистемы энкодеров. В 2026 году RTMP – дефолтный ingest-протокол для YouTube Live, Twitch, Facebook Live, X, Kick, LinkedIn Live, TikTok Live и примерно 70–90 процентов всей контрибьюции «энкодер → платформа» в мире, хотя его повсеместно называют «мёртвым», потому что Flash-плеер умер в 2020-м. Точная формулировка такая: RTMP мёртв на delivery-участке и жив на contribution-участке – экосистема энкодеров (OBS, vMix, Wirecast, FFmpeg, Larix, всё железо от Teradek до Blackmagic) стандартизировалась на push по RTMP и Flash для этого никогда не требовался. Вопрос 2026 года не в том, мёртв ли RTMP, а в том, стоит ли вам его использовать: да – почти для любого consumer- и social-platform ingest; нет – для профессиональной контрибьюции по lossy-каналам публичного интернета, где SRT или WHIP оправдывают свои расходы.

Зачем это понимать

Если вы выбираете протокол контрибьюции для живого продукта в 2026 году, RTMP – выбор с минимальной стоимостью входа и максимальным потолком: его понимает каждый энкодер на планете, его принимает каждая платформа, на которую вы можете публиковать, и в эфир можно выйти за пятнадцать минут. Подвох в том, что те же самые пять абзацев, которые объясняют, почему RTMP универсален, объясняют и почему 2-процентный всплеск потерь на аплинке площадки уложит поток. Знание того, где заканчивается рабочая огибающая RTMP, – самый полезный кусок контрибьюшен-знания, который продакт-менеджер, основатель или operations-лид может держать в голове.

Эта статья – канонический референс блока 3 по RTMP: что это на самом деле, почему он пережил смерть Flash, откуда берётся потолок задержки в 2–5 секунд, почему TCP – одновременно причина надёжности на чистом аплинке и причина зависаний на lossy-аплинке, что добавил Enhanced RTMP (E-RTMP) в 2024 году и как он стоит рядом с SRT, WHIP и broadcast-grade семейством в решении 2026 года. К концу статьи вы сможете защитить решение «мы шиппим RTMP» или «мы съехали с RTMP» на планёрке без последующих звонков.

Что такое RTMP – одной страницей

Real-Time Messaging Protocol, сокращённо RTMP, – это TCP-протокол прикладного уровня для доставки аудио, видео и данных между клиентом (энкодером) и сервером (ingest endpoint). Macromedia спроектировала его примерно в 2002 году, чтобы запитать продукт Flash Communication Server; Adobe купила Macromedia в 2005-м и унаследовала RTMP; Adobe наконец опубликовала спецификацию как публичный документ – RTMP 1.0 Specification, 21 декабря 2012 – и больше её не поддерживала. Каждая реализация после этого – community-driven чтение того документа 2012 года плюс де-факто поведение OBS Studio, кода-замены librtmp в FFmpeg, Wowza Streaming Engine и крупных соцплатформ.

Механически RTMP работает по одному TCP-соединению на порту 1935 по умолчанию. Сессия начинается с трёхэтапного рукопожатия (пакеты C0 / S0, затем C1 / S1, затем C2 / S2, каждый по 1536 байт), договаривается о соединении (команда connect), открывает поток (команда createStream) и публикует данные (команда publish на стороне энкодера или play для исторического случая Flash-воспроизведения на стороне клиента). Сами данные нарезаются на сообщения (message): аудио-сообщение, видео-сообщение или сообщение метаданных, – и каждое сообщение далее фрагментируется на чанки (chunks) согласованного размера (дефолт – 128 байт, но любой современный энкодер договаривается о chunk size 4096 байт, чтобы срезать накладные расходы per-chunk). Чанки разных сообщений могут чередоваться в одном TCP-соединении – так RTMP несёт аудио, видео и управляющие данные по одному сокету, не позволяя одному из них голодать.

Wire-формат бинарный, точность таймингов миллисекундная, и протокол несёт таймстампы end-to-end, чтобы приёмник мог пересобрать оригинальный поток с тем же временным соотношением аудио и видео, которое произвёл энкодер. Это вся архитектура. Протокол не согласует кодеки (энкодер декларирует их в сообщении метаданных, и сервер верит ему на слово), не делает adaptive bitrate (энкодер выбирает один битрейт и шлёт его; если соединение не вытягивает, энкодер буферизует, дропает кадры или отключается) и не делает никакой выборочной ретрансмиссии (TCP ретранслирует всё, по порядку, без понятия «это уже поздно – пропусти»).

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

Короткая версия того, как RTMP сюда попал

История важна, потому что она же – ответ на «почему RTMP до сих пор дефолт в 2026». RTMP родился внутри Flash-экосистемы Macromedia. С 2002 примерно по 2015 доминирующей моделью видео в вебе был Flash Player, проигрывающий RTMP-поток с Flash Communication Server: плеер и сервер – оба продукты Adobe, протокол между ними – RTMP, и весь стек – вертикально интегрированный. Каждый энкодер, который хотел отправить видео на сайт с Flash, говорил по RTMP, потому что сервер ничего другого не принимал. К 2010 году на рынке были сотни энкодеров – софт (Adobe Flash Media Live Encoder, Wirecast, Wirecast Pro, X-Split), железо (Teradek, Telestream, Blackmagic Web Presenter) и платформенные энкодеры (собственный инструментарий ingest для YouTube). Все говорили по RTMP. Этот инсталлбейс стал рвом.

Потом Flash умер. Спад начался около 2010-го, когда Apple выпустила iOS без Flash; HTML5-теги для видео появились в браузерах между 2011 и 2014 годами; и к январю 2021 года каждый крупный браузер вырезал поддержку Flash-плагина из кодовой базы. Сторона воспроизведения архитектуры Flash + RTMP схлопнулась за пятилетку. Сторона контрибьюции – нет, потому что контрибьюция никогда не зависела от Flash. Экосистема энкодеров продолжала говорить по RTMP, соцплатформы уже стандартизировались на RTMP для ingest, и стоимость миграции – попросить сотню вендоров энкодеров и десять миллионов стримеров согласиться на замену – была запретительной. Результат – статус-кво 2026 года: RTMP мёртв в браузерах, мёртв как протокол воспроизведения, мёртв там, где пользователь смотрит, – и универсальный дефолт там, где энкодер пушит.

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

Почему TCP – одновременно фича и баг

Почти каждое интересное свойство RTMP и почти каждая операционная боль ведут к одному решению, которое Macromedia приняла в 2002 году: RTMP едет по TCP. Будем конкретны, что это значит.

TCP – Transmission Control Protocol – один из двух транспортов, на которых работает интернет (второй – UDP, его мы разбираем в статье TCP и UDP в стриминге). TCP даёт три гарантии: каждый отправленный байт доходит, каждый байт приходит в том же порядке, в котором был отправлен, и протокол автоматически замедляет отправителя при перегрузке сети. Эти гарантии – то, что делает TCP хорошим для файлов, веб-страниц, почты и всего, где пропустить байт неприемлемо. Они же – то, что делает TCP неудобным для живого видео, где пропустить кадр лучше, чем получить его с опозданием.

Вот эта неудобность, одним абзацем. Допустим, энкодер отправляет 100 видео-чанков по RTMP, и чанк 47 теряется где-то между площадкой и ingest-сервером. TCP гарантирует доставку по порядку, а значит чанки 48, 49, 50 и каждый последующий будут сидеть в сетевом буфере приёмника, ожидая чанк 47. Приёмник не может отдать чанки начиная с 48 приложению, пока отправитель не ретранслирует 47 (это занимает один round-trip – обычно 30–200 миллисекунд в зависимости от пути), ретрансмиссия не дойдёт, а приёмник её не подтвердит. Это называется head-of-line blocking и это доминирующий режим отказа RTMP на lossy-сетях. 2-процентный всплеск потерь по пути с RTT в 90 миллисекунд эффективно ставит весь поток на паузу на два-три раунд-трипа, пока TCP восстанавливается.

Вторая половина поведения TCP – congestion control. Когда TCP детектирует потерю пакета, он интерпретирует это как сигнал перегрузки сети и режет скорость отправки – обычно вдвое в зависимости от варианта TCP (классический Reno режет вдвое; современный BBR пробует мягче). Для потока 6 Mbps одно событие ретрансмиссии режет эффективную скорость отправки до 3 Mbps на несколько секунд, затем TCP осторожно разгоняется. Энкодер шлёт 6 Mbps, соединение тащит 3 Mbps – буфер энкодера наполняется, кадры дропаются, зрители видят зависание.

Сравните с UDP-протоколом с выборочной ретрансмиссией вроде SRT. Когда SRT теряет чанк 47, приёмник отправляет один NAK (negative acknowledgment) с просьбой прислать чанк 47, отправитель ретранслирует только 47, а приёмник продолжает выдавать 48, 49, 50 приложению по мере поступления. Бюджет задержки на ретрансмиссию настраиваемый (рекомендованное значение – 4 × RTT пути); если 47 не успевает восстановиться, приёмник записывает дыру с этим sequence number и идёт дальше. Приложение видит однокадровый глитч вместо многосекундного зависания.

Это самая большая операционная разница между RTMP и современными альтернативами. RTMP отличный на чистом проводном аплинке с потерями менее 1 процента. RTMP схлопывается на загруженном бизнес-канале или Wi-Fi стадиона с 3–5-процентными вспышками потерь. Протокол в порядке; нижележащий транспорт – неправильный для публичного интернета на краю контрибьюции.

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

Потолок задержки 2–5 секунд – откуда число

RTMP стабильно описывают как «низкозадержный» протокол с полом задержки glass-to-glass в 2–5 секунд. Три компонента складываются в это число, и понимание каждого – то, что позволяет правильно построить реальный продукт вокруг RTMP в сравнении с альтернативами.

Буферизация на энкодере. Энкодеру нужно накопить достаточно видео, чтобы сформировать GOP – group of pictures, фрагмент кадров между ключевыми, – прежде чем он сможет начать отправку. Типичная конфигурация OBS выдаёт ключевой кадр каждые 2 секунды, то есть энкодер начинает сессию с буферизации примерно 2 секунд видео до того, как первый кадр уйдёт с площадки. Можно сократить интервал до 1 секунды или даже 0,5 секунд, но ценой эффективности сжатия (больше ключевых кадров – больше общий битрейт). Дефолт 2 секунды не случаен; это точка компромисса между качеством видео и задержкой контрибьюции для большинства сценариев.

Поведение TCP send buffer. RTMP едет по TCP-сокету, в который пишет операционная система. Ядро держит send buffer; энкодер пишет RTMP-чанки в этот буфер быстрее, чем сеть его драэнит; буфер устанавливается в стабильное состояние в несколько сотен килобайт. Эти буферизованные данные сидят в ядре, ожидая, пока сеть их вынесет, и добавляют 200 мс – 1000 мс задержки на стороне отправителя. Операторы, агрессивно тюнящие RTMP-пайплайны, сокращают TCP send buffer через SO_SNDBUF, но получают другой режим отказа (энкодер блокируется на write(), когда сеть кратковременно замедляется, и может дропать кадры). Большинство продакшен RTMP-деплоев принимают эту буферную задержку.

Пакетизация и форвардинг на ingest-стороне. Ingest-сервер принимает RTMP-чанки, пересобирает их во фреймы, и либо пушит вниз по конвейеру в транскодер, либо отдаёт packager-у, который делает HLS- или DASH-сегменты для delivery. Каждый шаг добавляет 100–500 мс. Для пайплайна «RTMP ingest → HLS delivery» (доминирующий паттерн для социальных платформ) ingest-сервер часто тратит 2–4 секунды на формирование двух сегментов HLS, прежде чем первый станет доступен зрителям; эта задержка на стороне delivery, но она складывается с contribution-стороной, которую видит зритель.

Арифметика вслух: 2 секунды GOP-буферизации энкодера + 0,5 секунды TCP send buffer + 0,3 секунды RTT публичного интернета + 0,5 секунды пакетизации на ingest + 1,5 секунды буфера плеера на стороне зрителя = 4,8 секунды задержки glass-to-glass, что ровно посередине диапазона 2–5 секунд, которое цитирует каждый вендор. Сократите GOP, сократите буфер плеера – и доведёте число до 2 секунд; удлините для устойчивости – и подниметесь до 8–10 секунд. Диапазон 2–5 секунд – это дефолт, не жёсткий предел.

Для контекста: LL-HLS целится в 2–4 секунды на стороне delivery и лучше всего работает, когда контрибьюция добавляет не больше 1 секунды; WHIP целится в задержку glass-to-glass меньше 500 миллисекунд; SRT настраиваемый – от 120 мс до нескольких секунд в зависимости от выбранного окна задержки. 2–5 секунд RTMP – это самый высокий потолок среди современных ingest-протоколов, и потолок задаётся GOP + send buffer + поведением TCP, не чем-либо в самом протоколе.

Варианты RTMP – семейное древо

Большинство людей, говорящих «RTMP», имеют в виду RTMP – оригинальный plain-text TCP-протокол на порту 1935. Существует несколько вариантов; вы встретите их в природе, и вам стоит уметь их назвать.

RTMP (обычный, порт 1935). Оригинальный протокол. Без шифрования. Сегодня используется длинным хвостом маленьких платформ и внутри облачных ingest-путей, где байты не покидают сеть оператора. Каждая крупная социальная платформа задепрекейтила plain RTMP для ingest между 2018 и 2022 годами в пользу TLS-варианта ниже.

RTMPS (TLS-защищённый, порт 443 или 1936). RTMP, обёрнутый в TLS-туннель – ровно так же, как HTTPS – это HTTP в TLS. Это то, что YouTube Live, Twitch, Facebook Live, X, Kick, LinkedIn, TikTok и в общем-то все коммерческие платформы требуют в 2026 году для ingest. Семантика протокола идентична; провод шифруется тем же стеком TLS 1.2/1.3, который защищает HTTPS. RTMPS – единственный вариант RTMP, который современный продакшен-стек должен принимать в публичном интернете.

RTMPE (проприетарное шифрование Adobe). До-TLS-попытка шифрования, которую Adobe встроила в Flash Media Server. Публично взломана в 2008 году и репутацию не восстановила. Избегайте. В 2026 RTMPE никто не шиппит, кроме как мост совместимости с легаси-железом.

RTMPT (туннелированный через HTTP). RTMP внутри HTTP-запросов для прохождения файрволлов, блокирующих порт 1935. Полезен в 2010-м, нерелевантен в 2026-м – RTMPS на порту 443 проходит файрволлы так же хорошо и использует современный TLS-стек.

RTMPTE (туннелирование + шифрование). Стэкните оба варианта выше. Не надо.

RTMFP (Real-Time Media Flow Protocol). Совершенно другой протокол от Adobe, работающий поверх UDP вместо TCP. Спроектирован для peer-to-peer Flash-приложений. Принадлежит к семейству RTMP только по имени и Adobe-родословной – другой транспорт, другой сценарий, никогда широко не разворачивался вне Flash, в 2026 году эффективно устарел.

Когда дальше в статье мы говорим «RTMP», мы имеем в виду RTMP/RTMPS – TCP-вариант контрибьюции, опционально завёрнутый в TLS, который поддерживает любая крупная платформа. Экзотические варианты – сноски.

Что на самом деле требуют платформы

Полезное упражнение: перечислить социальные и потребительские платформы, принимающие живой ingest в 2026 году, и отметить, какие протоколы принимает каждая. Таблица ниже дистиллирует опубликованную документацию на май 2026 года.

Из таблицы видны два паттерна. Первый: каждая крупная социальная платформа – YouTube, Twitch, Facebook, TikTok, Kick, X, LinkedIn – требует RTMPS и не принимает ничего другого. Если вы публикуете в социалки, в 2026 году вы шиппите RTMPS. Второй: developer-platform уровень – AWS IVS, Cloudflare Stream, Dolby Millicast, Mux – принимает все три RTMPS / SRT / WHIP на одной поверхности и позволяет выбрать правильный инструмент под путь контрибьюции. Разделение чистое: социальные платформы – RTMPS-only, developer-платформы – protocol-flexible.

Enhanced RTMP (E-RTMP) – что изменилось в 2024

Два десятилетия спецификация RTMP формально поддерживала только видеокодек H.264 и аудиокодек AAC. Современные кодеки – H.265 (HEVC), AV1, VP9 – не входили в спецификацию, и большинство энкодеров, которые хотели проталкивать их через RTMP-пайплайн, использовали нестандартные расширения codec-ID, которые одни серверы принимали, а другие – нет. Результат – медленная per-vendor каша флагов совместимости.

В 2022 году небольшая группа стейкхолдеров – Adobe, YouTube, Twitch, Veovera Software Organization и горстка независимых контрибьютеров – сформировала проект enhanced-rtmp, чтобы записать поведение codec-расширений в виде публичной спецификации. Первый релиз, Enhanced RTMP v1, вышел в 2023 году с формальной поддержкой VP8, VP9, H.265 (HEVC) и AV1 плюс сигнализация HDR-метаданных. Второй релиз, Enhanced RTMP v2, финализированный в 2024-м, добавляет мультитрек аудио и видео, фичу reconnect-request для устойчивости соединения и таймстампы с наносекундной точностью для тугой синхронизации с MP4- и CMAF-контейнерами вниз по конвейеру. Спецификация v2 – «Release Version» – заявление Veovera, что ключевые фичи стабильны и пригодны к продакшену.

Практическая картина E-RTMP в 2026-м – смешанная.

Где E-RTMP шиппится. YouTube Live принимает H.265 по E-RTMP для HDR-контрибьюции. OBS Studio 30+ выдаёт H.265 и AV1 по E-RTMP через встроенный энкодер. Larix Broadcaster шиппит E-RTMP как конфигурируемую опцию. Nimble Streamer и Wowza Streaming Engine принимают E-RTMP ingest. FFmpeg добавил поддержку E-RTMP в 7.0.

Где E-RTMP пока не шиппится. Twitch всё ещё требует H.264; HEVC не принимается. Facebook Live, TikTok Live, Kick и X не объявляли о поддержке E-RTMP в 2026-м. Старое железо без firmware-апдейтов не умеет E-RTMP и, возможно, никогда не научится. Длинный хвост CDN-ingest endpoint – в основном H.264-only.

Главное: E-RTMP реален, задокументирован, и шиппится на developer-platform уровне – но для «я пушу в социалку» консервативный дефолт – это всё ещё RTMPS + H.264. Следите за changelog-ами социальных платформ через 2026 и 2027 годы; именно там приземлится следующая волна adoption.

Разобранный пример – RTMP на проводе, числа вслух

Представьте, что вы публикуете поток 1080p60 на 6 Mbps из OBS Studio в RTMPS-ingest YouTube Live. Математика вслух:

Энкодер выдаёт 6 000 000 бит/с сжатого видео плюс примерно 192 000 бит/с стерео AAC-аудио – итого 6 192 000 бит/с полезной нагрузки. Per-chunk накладные расходы RTMP небольшие – 12-байтовый заголовок на первом чанке сообщения, 1 или 4 байта на последующих чанках того же сообщения – и добавляют менее 1 процента к полезной нагрузке. Округлим до 6,2 Mbps на проводе.

TCP-рукопожатие с ingest-сервером занимает один RTT – допустим, площадка в Лондоне, ingest во Франкфурте, RTT 30 миллисекунд. TLS добавляет ещё два RTT (TLS 1.2; TLS 1.3 – один), так что защищённый сокет устанавливается через 30 + 60 = 90 миллисекунд после первого SYN. Рукопожатие RTMP добавляет ещё 30 миллисекунд на C0+C1, S0+S1+S2, C2 – три single-RTT обмена. Команды connect, createStream и publish добавляют 120 миллисекунд раунд-трипов. Полное время от «нажал стрим» до «первого чанка видео в сети» – примерно 270 миллисекунд.

После этого per-message накладные расходы RTMP стабильны: чанки текут так быстро, как TCP-сокет драэнит, GOP-буфер энкодера держит около 2 секунд видео в любой момент, TCP send buffer держит ещё 0,3–1 секунды в зависимости от тюнинга ядра. End-to-end задержка контрибьюции от линзы до ingest-сервера YouTube – примерно 2,5–3,5 секунды.

Пайплайн YouTube затем упаковывает входящий RTMP-поток в HLS-сегменты, гонит adaptive-bitrate транскодинг и отдаёт сегменты своему CDN. HLS-плеер зрителя буферизует два-три сегмента до воспроизведения, добавляя ещё 6–8 секунд сверху. End-to-end задержка glass-to-glass дефолтного потока YouTube Live приземляется в районе 9–12 секунд – заметно выше contribution-пола 2–5 секунд самого RTMP, потому что основную часть задержки добавляет delivery-стек.

Последнее число – то, в чём ошибается большинство. RTMP – не причина того, что поток YouTube Live отстаёт от реальности на 10 секунд; HLS – причина. RTMP – причина того, что он максимум на 3 секунды медленнее того же потока, контрибьюченного через WHIP, и даже эти 3 секунды штрафа в основном невидимы, если delivery – HLS, потому что буфер HLS их затмевает.

Типичные ошибки

Ошибка 1: тестировать RTMP на офисном Ethernet и шиппить на площадку. Офисный аплинк – 99,9% поведение без потерь при RTT 60 мс до любого облачного региона. Почти у каждого аплинка площадки разброс RTT 30–200 мс, базовая частота потерь 0,3–1%, и эпизодические всплески 3–5%, когда сеть здания загружена. RTMP идеально работает в офисе и зависает в поле. Всегда тестируйте на представительном пути – а если продакшен-путь непредсказуем, не шиппите RTMP, шиппите SRT.

Ошибка 2: жёстко зашить keyframe interval на 4 секунды. Некоторые легаси-гайды рекомендуют 4-секундный интервал ради «лучшего сжатия». На ingest YouTube Live 4-секундный интервал толкает contribution-задержку за 6 секунд и полностью отключает LL-HLS delivery на платформе. Дефолт 2026 – 2 секунды для всего, кроме VOD-архивных воркфлоу.

Ошибка 3: шиппить plain RTMP (без TLS) на публичный ingest endpoint. Каждая крупная платформа задепрекейтила plain RTMP между 2018 и 2022 годами. Plain RTMP несёт stream key и видеобайты в открытом виде; любой в сети площадки может перехватить stream key и захватить ваш publishing-слот. Всегда используйте RTMPS. Накладные расходы TLS на современном энкодере незаметны.

Ошибка 4: доверять reconnect-поведению энкодера в RTMP. Большинство энкодеров реализуют RTMP-реконнект через разрыв TCP-сокета и повторную установку сессии. Реконнект занимает 200–800 миллисекунд, в течение которых энкодер буферизует кадры; если реконнект дольше локального буфера, кадры дропаются. Enhanced RTMP v2 ввёл явный механизм reconnect-request, которым платформы могут попросить энкодер переподключиться в выбранный сервером момент; если вы контролируете оба конца – используйте его.

Ошибка 5: считать, что «RTMPS на порту 443» пройдёт любой файрволл. Он проходит большинство файрволлов, потому что 443 – порт HTTPS. Не проходит DPI-файрволлы, которые смотрят SNI-расширение TLS-рукопожатия и блокируют не-HTTPS-трафик. Для корпоративной контрибьюции на площадке проверьте путь через security-стек площадки заранее.

Ошибка 6: путать RTMP-для-ingest и RTMP-для-distribution. RTMP – универсальный дефолт для ingest (энкодер → сервер). RTMP для distribution (сервер → зритель) умер вместе с Flash и пропал больше полудесятка лет назад. Если читаете «RTMP умирает» в статье 2026 года – автор имеет в виду distribution; если он имеет в виду ingest – он не прав. Distribution-сторону и почему она действительно мертва мы разбираем в статье RTMP для distribution и почему он по-настоящему умирает.

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

Фора Софт с 2005 года шиппит софт для живого стриминга – для видеоконференций, OTT, e-learning, телемедицины, видеонаблюдения и AR/VR. Мы собирали RTMP-пайплайны контрибьюции для клиентов, пушащих в YouTube Live и Twitch; гибридные RTMPS + SRT-пайплайны, где оператор выбирает протокол per-площадка; полные миграции с RTMP на WHIP, когда цель задержки опускалась ниже секунды. Протокол меняется; продакшен-дисциплина – нет. Дисциплина, которая важна, – размер буфера энкодера, валидация контрибьюшен-пути при представительных потерях, бэкап-энкодер для failover, инструментирование ingest endpoint для QoE – идентична для всех трёх протоколов. RTMP – самое простое место, чтобы стартовать.

Миграция с RTMP – когда, как и когда не нужно

Дерево решений 2026 года для «стоит ли уходить с RTMP» короткое.

Останьтесь на RTMP, если ваш путь контрибьюции – проводной аплинк с потерями менее 1 процента, цель задержки – 3 секунды и выше на стороне контрибьюции, вы публикуете в социальную платформу, которая требует RTMPS, и ваша экосистема энкодеров фиксирована (каждый оператор уже использует OBS или железо, которое нельзя заменить). Это большинство продуктов live-стриминга в 2026 году, и «оставить RTMP» – правильный, скучный ответ.

Переходите на SRT, если ваш путь контрибьюции – публичный интернет на площадке (бизнес-канал, Wi-Fi стадиона, мобильная связь), бюджет задержки позволяет 1–3 секунды retransmission window, ваша платформа поддерживает SRT-ingest (Cloudflare Stream, Mux Live, Dolby Millicast, AWS Elemental MediaConnect), и вы наблюдали многосекундные зависания RTMP на загруженных аплинках. SRT – стандарт полевой контрибьюции не просто так – он абсорбирует 3-процентный всплеск потерь, который RTMP не вытягивает.

Переходите на WHIP, если цель задержки ниже 1 секунды, ваш энкодер может быть браузером или WHIP-совместимым нативным инструментом, и ваш ingest endpoint умеет WHIP (любая developer-платформа от Cloudflare до LiveKit и Dolby Millicast). WHIP оправдывает себя на интерактивных сценариях – live shopping, платные Q&A, live-коучинг, спортивные ставки – где 2–5 секунд RTMP слишком медленно.

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

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

Вердикт 2026

RTMP – 24-летний протокол, спроектированный под стек, которого больше нет, у которого с 2012 года не было активного мейнтейнера, который никто бы не изобрёл сегодня и который тем не менее несёт 70–90 процентов всей живой контрибьюции в мире. Этот парадокс – повсеместно осмеян как устаревший, повсеместно развёрнут в продакшене – больше следствие координационной задачи экосистемы энкодеров, чем самого протокола.

Точная рамка 2026 года из трёх частей. RTMP жив на стороне контрибьюции, потому что каждый энкодер в мире его понимает, а каждая социальная платформа его принимает. RTMP мёртв на стороне distribution, потому что Flash умер, и HTTP-доставка (HLS, DASH) его заменила. RTMP показывает свой возраст на lossy-путях контрибьюции, потому что TCP – неправильный транспорт для видео на краю – именно там SRT и WHIP отбирают свою долю рынка контрибьюции и продолжат отъедать долю RTMP через 2027 и 2028 годы.

Если из этой статьи стоит вынести один совет: шиппите RTMPS по умолчанию, знайте профиль потерь своего пути контрибьюции и держите в кармане план миграции на SRT или WHIP на тот день, когда сеть площадки заставит решение принять. Это и есть playbook RTMP-2026.