Альтернативы RTMP для отправки ваших потоков в Интернет
Изначально проприетарный протокол RTMP был разработан Macromedia (ныне Adobe) для потоковой передачи видео, аудио и данных в реальном времени между сервером и Flash-плеером. Хотя Adobe объявила, что больше не будет поддерживать Flash, RTMP остается широко используемым протоколом для потоковой передачи в реальном времени в производственных рабочих процессах. В этом посте мы разберем некоторые проблемы, с которыми сталкивается RTMP для потоковой передачи контента на “первой миле” – при осуществлении вашей трансляции в облачный сервис для распространения через CDN и расскажем про несколько альтернативных протоколов, которые стоит рассмотреть.
Реальность такова, что RTMP просто не подходит для решения сегодняшних задач по следующим причинам:
- Поддержка RTMP ослабевает, и CDN выводят из эксплуатации точки входа RTMP в пользу HLS и MPEG-DASH.
- RTMP не поддерживает потоки в кодеке HEVC.
- RTMP не поддерживает новые разрешения видео, отчасти из-за отсутствия поддержки HEVC, а также из-за того, что RTMP нельзя использовать при высокоскоростной передаче данных из-за ограничений пропускной способности.
- Исторически сложилось так, что RTMP с трудом справляется с передачей через брандмауэры.
- В RTMP возникают проблемы с безопасностью, поддержкой нескольких языков и поддержкой вставки рекламы.
Если с RTMP так много трудностей, то какие существуют альтернативы, способные передавать ваши потоки в CDN? В настоящее время ваш выбор стоит между протоколами на основе HTTP, такими как HTTP Live Streaming (HLS) и MPEG-DASH или Secure Reliable Transport (SRT), протокол с открытым исходным кодом.
Безопасный Надежный Транспорт (SRT)
Для начала, краткое руководство для тех, кто, возможно, не знаком с SRT. Разработанный компанией Haivision, SRT представляет собой новый протокол с открытым исходным кодом, который уже используется тысячами организаций по всему миру в широком спектре отраслевых приложений, от IP-камер, кодеров и декодеров до шлюзов, платформ OTT и CDN. Все больше организаций начинают использовать протокол SRT и вступают в Альянс SRT (на сегодняшний день насчитывается более 550 компаний). Такие гиганты отрасли как Avid, Brightcove, Deluxe, Global, Imagine, LTN, MediaKind, Microsoft, Net Insight, Red Bee и Telestream, поддерживают и активно используют наш протокол.
Давайте углубимся в некоторые фундаментальные различия между протоколом RTMP, основанным на HTTP и SRT.
Потоковые передачи: Непрерывная против Фрагментированной
RTMP — это технология непрерывной потоковой передачи. Пакеты, содержащие основную структуру потока MPEG I-кадров и P-кадров, отправляются от источника к получателю по мере их создания. Протоколы на основе HTTP (HLS и MPEG-DASH) основаны на том, что эти потоки упаковываются в виде фрагментов (или блоков), а затем отправляются по сети в виде сегментов файлов. Прежде чем покинуть платформу кодирования, несколько последовательностей I-кадров и P-кадров собираются и упаковываются вместе в виде файла для передачи. Этот процесс упаковки, хотя и учитывает повсеместность передачи файлов, замедляет ваш поток и значительно увеличивает сквозную задержку.
SRT, как и RTMP, представляет собой протокол непрерывной потоковой передачи, предназначенный для высокопроизводительной передачи и оптимизации пропускной способности.
Потери пакетов
TCP/IP
Как и RTMP, протоколы на основе HTTP (включая HLS и MPEG-DASH) полагаются на TCP/IP для установления связи, а также для идентификации и замены пакетов, потерянных при передаче. Протокол TCP/IP требует очень тесных отношений между отправителем и получателем, чтобы независимо от условий сети все потерянные пакеты обнаруживались и передавались повторно. Большие буферы на обоих концах потока рабочего процесса содержат пакеты, которые, возможно, потребуется повторно передать в случае их потери. Однако основная проблема передачи потокового видео на основе TCP/IP заключается в том, что повторная передача пакетов занимает очень много времени, что значительно увеличивает задержку видео. Вот как это работает: получатель подтверждает каждый пакет, отправитель на всякий случай сохраняет большой буфер всех отправленных пакетов, а затем повторно передает пакеты, которые каким-то образом не поступают в течение определенного временного окна.
Вторая серьезная проблема с TCP/IP заключается в том, что из-за всех обменов данными TCP/IP (и связанных с ними алгоритмов управления перегрузкой, которые, как правило, снижают пропускную способность), потоковая передача RTMP и HTTP имеет трудности с использованием полосы пропускания. Хорошо справляясь с более низкой пропускной способностью в течение нескольких переходов, передача на основе TCP/IP очень быстро достигает максимальной пропускной способности (иногда в диапазоне от 1.5 до 2 Мбит/с), а затем, как только это происходит, пропускная способность начинает снижаться. По сути, как TCP/IP, так и фрагменты потока станут вашими врагами при попытке передать видеопоток с высоким битрейтом = качеством.
UDP
Протокол UDP работает аналогично TCP, но без проверки на ошибки, которая замедляет работу. При использовании UDP, “дейтаграммы”, которые по сути являются пакетами, отправляются получателю. Отправитель не ждет, чтобы убедиться, что получатель получил пакет – он просто продолжит отправку следующего пакета. Если вы являетесь получателем и пропускаете некоторые пакеты UDP, это очень плохо влияет на итоговый результат. Нет никакой гарантии, что вы получаете все пакеты, и нет возможности запросить пакет снова, если вы его пропустите. Однако преимущество потери всех этих накладных расходов на обработку означает, что UDP работает быстро и часто используется для приложений, чувствительных ко времени, таких как онлайн-игры или прямые трансляции, где воспринимаемая задержка более важна, чем потеря пакетов. UDP — отличный протокол для потоковой передачи по гарантированным сетям, таким как локальная сеть или выделенные соединения частной сети WAN, например, MPLS.
SRT
Haivision создала SRT для обеспечения производительности UDP в сетях с потерями с помощью высокопроизводительного режима Caller/Listener, который не перегружает сеть бесполезными подтверждениями, поэтому он может масштабироваться и максимизировать доступную пропускную способность. Если говорить про видео, то синхронизация — это один из важнейших моментов. SRT гарантирует, что скорость пакетов (сжатый видеопоток), поступающих в сеть, идентична той, с которой они принимаются декодером, что значительно упрощает процесс декодирования. SRT предназначен для доставки видеопотока с низкой задержкой по сетям с потерями.
SRT предоставляет некоторые дополнительные функции, специально разработанные для видеопотока. Он изначально обеспечивает независимое шифрование AES, поэтому безопасность потока управляется на уровне канала. Это также позволяет пользователям легко обходить брандмауэры на протяжении всего рабочего процесса, поддерживая режимы отправки и приема (в отличие от RTMP и HTTP, которые поддерживают только один режим). SRT также может объединять несколько потоков видео, аудио и данных в одном потоке SRT для поддержки очень сложных рабочих процессов, не обременяя сетевых администраторов.
В режиме Caller/Listener SRT имеет возможность определять производительность сети в отношении задержки, потери пакетов, джиттера и доступной пропускной способности. Продвинутые интеграции SRT могут использовать эту информацию для управления инициированием потока или даже для адаптации конечных точек к изменяющимся условиям сети, как мы сделали в видеокодерах серии Makito X в режиме адаптивного сетевого кодирования.
SRT не привязан к полезной нагрузке, имеет открытый исходный код и, что самое приятное, бесплатен. С исчезновением RTMP, хотя и DASH или HLS могут быть приемлемы для распространения потоковой передачи с вашего CDN на компьютеры и мобильные устройства, SRT является явным победителем при решении задач потоковой передачи “первой мили”.
RTMP vs. SRT
Недавно мы протестировали RTMP и SRT, чтобы точно увидеть, насколько они отличаются. Чтобы ознакомиться с результатами и узнать, как два протокола показали себя в тестах на задержку и пропускную способность, скачайте наш отчет «RTMP vs. SRT«.
