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-ингеста; нет – для профессиональной контрибьюции по lossy-каналам публичного интернета, где SRT или WHIP оправдывают свои затраты.

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

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

Эта статья – канонический референс по блоку 3 RTMP: что это на самом деле, почему протокол выжил после смерти Flash, откуда берётся задержка в 2–5 секунд, почему TCP одновременно обеспечивает надёжность на стабильном канале и вызывает зависания при потерях в сети, что добавил 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. В 2005 году Adobe приобрела Macromedia и унаследовала RTMP. Наконец, в декабре 2012 года Adobe опубликовала спецификацию под названием RTMP 1.0 Specification и больше не обновляла её. Все последующие реализации основываются на интерпретации этого документа 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 байт, однако любой современный энкодер договаривается о размере чанка 4096 байт, чтобы снизить накладные расходы на каждый чанк). Чанки от разных сообщений могут чередоваться в рамках одного 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 для приёма потока, а стоимость миграции – необходимость убедить сотни вендоров энкодеров и десятки миллионов стримеров перейти на что-то новое – была неприемлемо высокой. Результат – статус-кво 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. Приёмник не может передать эти чанки приложению, пока отправитель не отправит 47 повторно (это занимает один round-trip – обычно 30–200 миллисекунд в зависимости от пути), пока ретрансляция не дойдёт до получателя, а тот её не подтвердит. Это называется head-of-line blocking и является доминирующим режимом отказа RTMP в сетях с потерями. Всплеск потерь в 2% на пути с RTT в 90 миллисекунд эффективно ставит весь поток на паузу на два-три раунд-трипа, пока TCP восстанавливает соединение.

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

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

Это самая существенная операционная разница между RTMP и современными альтернативами. RTMP отлично работает при стабильном проводном подключении с потерей пакетов менее 1 процента. Однако он не справляется с нагрузкой на загруженном бизнес-канале или 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-сегменты для доставки. Каждый этап добавляет задержку в 100–500 мс. В пайплайне «RTMP ingest → HLS delivery» (наиболее распространённый сценарий для социальных платформ) ingest-сервер обычно тратит 2–4 секунды на создание двух сегментов HLS, прежде чем первый из них станет доступен зрителям. Эта задержка возникает на стороне доставки, но складывается с задержкой на стороне 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 секунды на стороне доставки и работает наиболее эффективно, когда задержка на стороне источника не превышает 1 секунды; WHIP стремится к задержке «от экрана до экрана» менее 500 миллисекунд; SRT – настраиваемый протокол, обеспечивающий задержку от 120 мс до нескольких секунд в зависимости от выбранного окна буферизации. Задержка RTMP в диапазоне 2–5 секунд – это максимальный показатель среди современных протоколов приёма, и он определяется параметрами GOP, размером отправочного буфера и поведением TCP, а не особенностями самого протокола.

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

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

RTMP (обычный, порт 1935). Оригинальный протокол. Без шифрования. Сегодня используется небольшим количеством небольших платформ и внутри облачных ingest-путей, где данные не покидают сеть оператора. Каждая крупная социальная платформа отменила поддержку обычного 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-платформ – AWS IVS, Cloudflare Stream, Dolby Millicast, Mux – поддерживается три протокола: RTMPS, SRT и WHIP на одной поверхности, что позволяет выбрать оптимальный инструмент в зависимости от способа доставки контента. Разделение чёткое: социальные платформы – только RTMPS, developer-платформы – гибкие по протоколам.

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

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

В 2022 году небольшая группа заинтересованных сторон – Adobe, YouTube, Twitch, Veovera Software Organization и несколько независимых разработчиков – создала проект enhanced-rtmp, чтобы зафиксировать поведение расширений кодеков в виде публичной спецификации. Первый релиз, 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. Поддержка E-RTMP была добавлена в FFmpeg начиная с версии 7.0.

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

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

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

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

Энкодер выдаёт 6 000 000 бит/с сжатого видео и около 192 000 бит/с стереоаудио в формате AAC – итого 6 192 000 бит/с полезной нагрузки. Накладные расходы 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 – три односторонних RTT. Команды connect, createStream и publish добавляют 120 миллисекунд раунд-трипов. Полное время от «нажал стрим» до «первого чанка видео в сети» – примерно 270 миллисекунд.

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

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

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

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

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

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

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

Ошибка 4: доверять поведению энкодера при 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 и исчез более полувека назад. Если вы читаете в статье 2026 года, что «RTMP умирает», автор имеет в виду distribution; если он говорит об ingest – он ошибается. О distribution-стороне и о том, почему она действительно мертва, мы подробно рассказываем в статье RTMP для distribution и почему он по-настоящему умирает.

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

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

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

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

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

Переходите на SRT, если ваш канал контрибуции проходит через публичный интернет (бизнес-канал, Wi-Fi на стадионе, мобильная связь), бюджет задержки позволяет окно повторной передачи 1–3 секунды, ваша платформа поддерживает SRT-ингест (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 только потому, что он «старый». Возраст – не недостаток. Протокол работает, экосистема энкодеров его поддерживает, а стоимость миграции вполне реальна. Переходите, когда операционная проблема на стороне контрибьюции вынуждает это сделать, а не потому, что вендорский блог объявил протокол мёртвым.

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

Вердикт 2026

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

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

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