RTMP: прошлое и настоящее
Как вы понимаете, в процессе стриминга участвуют три стороны: Publisher, Server и Viewers. Это определяет два участка, на которых много лет назад преобладал RTMP. Во многом, благодаря популярности Flash-технологии на десктопах.
Со временем, когда произошёл отказ от Flash и потребление контента сместилось в сторону мобайла, ситуация изменилась. В наши дни, если рассматривать участок от сервера к зрителю, то можно однозначно сказать — RTMP на этом участке уже не используется. Его сменил протокол HLS, детище компании Apple, и ряд менее распространённых протоколов, но с той же общей идеей: шлёпать маленькие файлики (секунд 3–10) и посылать их зрителю.
Но на участке Publisher → Server протокол RTMP до сих пор не сдаёт свои позиции и является монополистом. Если вы хотите стримить на Facebook, YouTube или Twitch вы должны использовать RTMP. В силу этого и производители стриминг софта, и железа тоже вынуждены поддерживать RTMP. Тем более, никакой другой альтернативы никто особо и не предлагал.
ПРИМЕЧАНИЕ: некоторые платформы могут принимать на вход HLS/DASH. Но этот путь особо не популярен, потому что любой “фрагментарный” протокол - это несколько секунд (!) задержки уже в начале пути.
Что-же не устраивает в RTMP ?
Замечу, что Adobe (владелец протокола RTMP) перестала его развивать в тот момент, когда похоронила технологию Flash, а было это достаточно давно.За это время успели появиться новые кодеки (h265, av1), и возможно скоро появятся ещё.
Вы, наверное, читали обзоры кодеков, где говорят что кодек .h265 может дать выигрыш 25–50%! То есть вместо 5Mbs вам достаточно интернет-канала условно в 3Mbs. Согласитесь, это здорово! Особенно, если вам нужно передать сигнал по LTE.
Увы, но использовать даже h265 внутри RTMP не получится. Пожалуй, это и есть основная претензия к RTMP — он не подходит для новых кодеков.
ПРИМЕЧАНИЕ: наверное, некоторые скажут: "эй, китайские энкодеры пишут что могут h265 в RTMP!" Могут, но это уже какой-то не официальный диалект RTMP, и понять его может только сервер от того же китайца.
Кто раньше встал, того и тапки
Конечно, команды разных размеров по всему миру делали свои протоколы. Например, понятно, что у LiveU есть свой крутой протокол, да ещё и с поддержкой бондинга. Но именно компания Haivision подсуетилась, особенно в маркетинговой части, и первой подарила публике замену для RTMP. Протокол назвали SRT. Грамотный маркетинг, в частности ставка на open-source, сделал своё дело, и SRT набирает популярность.SRT: особо интересные моменты
Итак: SRT основан на UDP (а RTMP основан на TCP), что позволило "затюнинговать" его под современные реалии
// UDP-хейтерам этот момент я раскрою в следующем посте
В SRT есть режимы “можно терять данные”(по умолчанию) и “ничего не терять” (по аналогии с TCP).
Есть режим пробивки файрвола, когда нет выделенного IP (см ниже).
Режим “можно терять данные“ стоит по умолчанию, и рекомендован для Live-streaming’а с низкой задержкой. Конечно, SRT будет в рамках дозволенного интервала времени пытаться переслать потерянные данные.
Кстати, это время как раз регулируется параметром Latency который присутствует во многих SRT-энкодерах. И по умолчанию он стоит в 120ms. То есть, если пакет данных потерялся, система пытается его снова послать и снова, и на всё есть 120ms, потом он снимается с обработки.
На практике, при большом проценте потерь, это выглядит как артефакты на картинке. Если говорить про отличие от RTMP в этом вопросе, то в SRT вы сами определяете степень компромисса между “скорость доставки” и “качество доставки”.
Режим "ничего не терять" предназначен в SRT для передачи файлов, где потеря одного байта может поломать весь файл. В энкодерах для стриминга вряд ли вы встретите такую опцию.
Также стоит отметить, что протокол активно развивается в рамках open-source, и уже есть обсуждения как добавить в протокол бондинг.
SRT ходит сквозь файрвол? Бывает…
Надо сказать, что для UDP (на котором построен SRT) есть старый метод пробивки файрвола, которым пользовался ещё Скайп, когда был p2p.
Утрировано звучит так: если два гнома подбегут к разделяющей их стене к одной точке и одновременно (!) ударят по одному и тому же кирпичу, то тогда есть шанс пробить дырку.
В SRT это назвали “рандеву режимом”, и при настройке его обоим участникам нужно знать внешний IP друг-друга (по сути это координаты “точки” в которую надо бить), и ещё согласовать время “удара”. То есть нужно решить проблему согласования. Делать это “ручками” можно, но не тривиально.
Кстати, продукты категории SRT-cloud от разных производителей как раз и снимают эту боль с вас: поскольку все стороны используют единое ПО, то они могут автоматически договориться по каким-то своим протоколам через центральный сервер, и тогда будет возможность пробивать файрвол уже методом SRT и дальше общаться напрямую.
Моё личное мнение: ручная настройка рандеву нетривиальна. Лучше веровать в ipv6. Кстати, видел, что МТС выдаёт ipv6 для LTE без проблем (в отличие от ipv4) и, насколько я знаю, там нет проблем с фильтрацией трафика.
Ну и кто победит?
Технически SRT конечно уделывает RTMP. Вопрос в том, пойдёт ли SRT в массы или так и останется профессиональной вещью. Нужно сказать, что крупные платформы Facebook и YouTube как то не замечены в гребле в сторону SRT. Поэтому производители всяких массовых стрим-железок типа экшен-камер, дронов, накамерных стримеров, так и будут плодить RTMP-железки, ведь юзерам нужно стримить на эти платформы. И особого резона внедрять SRT им пока нет.
В общем, время покажет.
