Полное руководство по RTMP: что это такое и когда его использовать?
Протокол обмена сообщениями в реальном времени (RTMP) — это широко используемый формат потокового вещания. Он существует уже много лет и стал важным инструментом для вещателей, операторов сетей и многих других отраслей. Однако некоторые ошибочные представления о RTMP сделали его менее популярным, чем он мог бы быть.
Но что такое RTMP? Как он работает? И стоит ли вам использовать его для своей следующей прямой трансляции?
Узнайте об этом и многом другом ниже.
Что такое RTMP?
RTMP — это сетевой протокол или система, используемая для потоковой передачи медиаконтента через интернет на основе технологии Transmission Control Protocol (TCP).
TCP — это один из компонентов, составляющих набор интернет-протоколов. Другим важным компонентом является интернет-протокол, также называемый IP.
RTMP — это сетевой протокол или система, используемая для потоковой передачи медиаконтента через Интернет.
Вместе TCP и IP действуют как коммуникационные мосты между прикладным и сетевым уровнями. Подумайте об этом так: прикладной уровень включает в себя то, с чем вы обычно взаимодействуете, например, браузер Mozilla Firefox или любое другое пользовательское приложение.
Чтобы браузер Firefox загрузил веб-страницу, он должен отправить запрос на сервер сайта. Получив запрос, сервер отправляет запрашиваемый ресурс (например, видеопоток, предварительно записанное видео на YouTube или Html-код для веб-страницы).
Чтобы поддерживать эффективную связь (т.е. избежать потери или задержки корреспонденции), сообщение должно быть разобрано на более мелкие части, называемые пакетами. Это делается на стороне отправителя, а после получения сообщения оно вновь собирается для пользователя.
TCP — это компонент, который занимается разбиением сообщения на пакеты или более мелкие части, которые могут быть переданы эффективно и качественно.
Уровень IP действует как агент пересылки, который определяет наилучшие маршруты для передачи пакетов через Интернет.
Протокол RTMP используется многими популярными медиаплеерами, включая Adobe Flash Player, VLC Media Player, QuickTime Player и Windows Media Player. RTMP также поддерживается некоторыми веб-браузерами, включая Google Chrome и Mozilla Firefox.
Для большинства пользователей при выборе решения для потокового вещания первоочередной задачей является передача контента. Если качество разрешения потоковой передачи низкое, то для большинства потребителей это будет решающим фактором. Аналогичным образом, решение для потоковой передачи с высокой задержкой, буферизацией или слишком долгой загрузкой перед воспроизведением контента не будет пользоваться успехом.
Именно здесь RTMP проявляет себя во всей красе. С момента своего появления RTMP гарантирует низкую задержку, минимальную буферизацию и одно из лучших разрешений потоковой передачи при условии, что сетевое соединение достаточно сильное и быстрое.
Еще одним плюсом RTMP является его способность поддерживать массовую потоковую передачу одновременно и без серьезных проблем.
Однако, несмотря на то, что RTMP существует уже много лет, в последнее время она стала объектом повышенного внимания, поскольку эта система небезопасна для пользователей.
Вот как возникает уязвимость(и) в системе безопасности:
Во-первых, протокол RTMP не имеет встроенного шифрования. Поэтому любая связь или передача пакетов при использовании RTMP открыта для прослушивания неавторизованными группами или атак типа «человек посередине».
Еще один фактор, способствовавший уязвимости безопасности RTMP, заключается в том, что его исходный код долгое время был проприетарным. Проприетарное программное обеспечение (т.е. программное обеспечение, права собственности и контроля над которым ограничены организацией, разработавшей или купившей его) обычно регулярно получает исправления безопасности, но этого недостаточно.
Новые уязвимости появляются часто, а сообщество, созданное вокруг программного обеспечения с открытым исходным кодом, гарантирует относительно более частые и качественные исправления безопасности. Это то, что RTMP упустил для повышения своей безопасности.
Попробуйте прямую трансляцию Wave.video
Надежная и простая в использовании мультистриминговая платформа для стримеров любого уровня Попробуйте сейчас
Разновидности RTMP
Варианты RTMP включают следующее:
- Real-Time Messaging Protocol Server(RTMPS) — похож на RTMP, только имеет шифрование, т.е. включен уровень защищенных сокетов (SSL) и Transport Layer Security (TLS), и поддерживает все проигрыватели с включенным Flash-плеером. Он используется в сценариях, где крайне важно предотвратить фальсификацию или несанкционированный доступ к данным при их передаче.
- Encrypted Real-Time Messaging Protocol(RTMPE) — это очень универсальный потоковый протокол, который использует для передачи данных как протокол управления транспортом (TCP), так и протокол пользовательских дейтаграмм (UDP). RTMPE также шифрует все передаваемые данные с помощью фирменного шифрования Adobe, чтобы избежать несанкционированного доступа и несанкционированного вмешательства.
- Real-Time Messaging Protocol Tunnel(RTMPT) — RTMPT использует механизм туннелирования для обхода брандмауэров , которые обычно блокируют весь трафик RTMP. На практике RTMPT требует, чтобы клиент отправил модифицированный HTTP-запрос на сервер, который отвечает почти такой же HTTP-передачей. Клиент и сервер используют идентификатор сессии; как только соединение установлено, между ними может начаться передача данных.
- Real-Time Media Flow Protocol(RTMFP) — RTMFP — это усовершенствованная версия RTMP, в которой используется другой формат кодирования UDP для достижения высокопроизводительной потоковой передачи мультимедиа .
История потоковой передачи данных RTMP
Real-Time Messaging Protocol (RTMP) изначально был собственным протоколом, разработанным компанией Macromedia для потоковой передачи аудио, видео и данных через интернет между Flash-плеером и сервером.
RTMP сегодня используется многочисленными популярными онлайн-сервисами, такими как Facebook, Twitch и Twitter, для потоковой передачи видео в реальном времени.
Первый публичный релиз RTMP был выпущен в 2002 году. В 2009 году компания Adobe выпустила версию RTMP с открытой спецификацией, известную как OpenRTMP. Основное различие между RTMP и OpenRTMP заключается в том, что в OpenRTMP можно использовать любой медиасервер, а не только Flash Media Server (FMS).
Кроме того, открытая спецификация RTMP обладает большей гибкостью в отношении того, как разработчики могут защитить или сконфигурировать одноранговую функциональность. Это призвано стимулировать инновации и сотрудничество через конкуренцию и открытый доступ разработчиков для создания идеального решения RTMP.
Главный принцип
RTMP использует технику, называемую «потоковой передачей», для доставки контента. Это означает, что данные передаются небольшими частями, называемыми «кусками». Куски собираются на другом конце, поэтому пользователь может смотреть или слушать контент, не дожидаясь его полной загрузки.
Работа RTMP состоит из двух частей: Доставка на первую и последнюю милю.
Доставка на первую милю обычно включает передачу мультимедиа от кодера на сервер с помощью RTMP. Доставка на последней миле относится к передаче медиа с сервера на устройство пользователя. Во второй части используется Flash-плеер или аналогичный инструмент. Есть сообщения, что Adobe прекращает поддержку Flash; следовательно, это означает конец доставки «последней мили».
В ответ на это индустрия приняла протокол Hypertext Transfer Protocol (HTTP), более эффективное решение для потоковой передачи данных.
Варианты RTMP, такие как RTMPT, в настоящее время используют HTTP для инкапсуляции и передачи мультимедиа.
Как работает RTMP Ingest
Это, вероятно, одно из достоинств RTMP, благодаря которому он существует так долго. Когда мир перешел от просмотра медиа на компьютерах к просмотру на мобильных устройства х , RTMP столкнулся с проблемой.
Например, RTMP полагался на плеер Adobe Flash для обеспечения бесперебойной потоковой передачи, но была небольшая проблема. Мобильные устройства не поддерживали Adobe Flash player; по сути, RTMP стал бесполезен для пользователей, которые хотели получить те же потоковые услуги на своих мобильных устройствах.
В ответ компания Apple разработала протокол HLS для поддержки функции потокового вещания на мобильных устройствах.
Было вполне разумно ожидать, что RTMP устареет. К счастью, он продолжал жить вместе с RTMP ingest, создав свою нишу в качестве идеального протокола для передачи мультимедиа от кодера к серверу.
RTMP ingest отдает приоритет функционированию недорогих кодеров и, как правило, предлагает пользователям потоковую передачу с низкой задержкой.
Она включает в себя три основных компонента:
1. Рукопожатие
Когда клиент хочет подключиться к серверу RTMP, ему сначала необходимо установить рукопожатие. Этот процесс начинается с отправки клиентом запроса «connect» на сервер, который включает информацию о клиенте и типе соединения, которое он пытается установить.
Затем сервер отвечает сообщением «connected», которое содержит информацию о сервере и типе установленного соединения.
Наконец, клиент и сервер обмениваются сообщениями для подтверждения того, что они все еще соединены, и для согласования любых параметров, необходимых для соединения.
2. Соединение
Основной целью входящего соединения RTMP является предоставление средств для потоковой передачи медиаконтента от источника к месту назначения.
Источником медиа может быть прямая трансляция с камеры, предварительно записанное видео, аудио или другое медиа. Местом назначения обычно является сервер потокового мультимедиа, который распространяет контент среди зрителей.
Соединение RTMP ingest состоит из трех компонентов:
- Кодер преобразует видео- и аудиосигнал в цифровой формат, который можно передавать через Интернет.
- Транспорт: Это среда, по которой кодированный сигнал передается от кодера к серверу; обычно это делается через UDP или TCP.
- Сервер получает закодированный сигнал и делает его доступным для зрителей (обычно упаковывая его в формат типа Flash).
3. Потоковая передача
Когда пользователь передает контент на медиасервер, сервер должен сначала закодировать входящее видео и аудио, прежде чем отправлять его всем подключенным клиентам.
Процесс кодирования и переформатирования видео и аудио в стандартный формат файла называется транскодированием. Он включает в себя преобразование входного сигнала в форму, которая может быть воспроизведена на различных устройствах.
Подробнее о потоковом вещании Существует два типа потокового вещания: в прямом эфире и по требованию. Прямая трансляция — это трансляция в режиме реального времени, а трансляция по требованию — это когда пользователи могут смотреть контент в удобном для них месте.
Прямая трансляция требует постоянного соединения между клиентом и сервером, а трансляция по требованию — нет.
RTMP использует TCP для поддержания постоянного соединения между клиентом и сервером, обеспечивая потоковую передачу с низкой задержкой. Однако RTMP не очень хорошо подходит для потоковой передачи по требованию.
Альтернативы RTMP для загрузки
SRT и WebRTC — основные претенденты, которые могут сравниться с возможностями RTMP или даже превзойти их. Вот краткий обзор этих двух альтернатив:
Безопасный надежный транспорт (SRT)
SRT заполняет пробелы, с которыми не справился RTMP, например, поддерживает потоковое вещание с низкой задержкой, даже если пользователь подключен к относительно ненадежной сети. Это делает его отличным выбором для потокового вещания как в прямом эфире, так и по требованию.
Поскольку он имеет открытый исходный код, его возможности безграничны, и можно не беспокоиться о том, что поддержка разработчиков будет прекращена.
Веб-коммуникации в реальном времени (WebRTC)
WebRTC выигрывает благодаря возможности публикации через браузер. WebRTC HTTP Ingest Protocol (WHIP) также находится в разработке, и для пользователей это означает, что они смогут осуществлять потоковую передачу с помощью только веб-браузера вместо того, чтобы возиться с кодировщиками, как в случае с RTMP.
Альтернативы ППТМ для эвакуации
В списке альтернатив RTMP egress лидируют HTTP Live Streaming (HLS), MPEG-DASH и WebRTC.
Вот краткий обзор альтернатив:
HLS и MPEG-DASH
Эти две технологии практически одинаковы, только HLS является проприетарной, а MPEG-DASH — с открытым исходным кодом.
Самое лучшее в этих двух устройствах то, что они разработаны для обеспечения низкой задержки, оптимального качества мультимедиа и даже для работы с ненадежными сетевыми соединениями.
WebRTC также является достойной альтернативой решениям RTMP egress .
Умирают ли RTMP и Flash?
Короткий ответ: скорее всего, нет. Длинный ответ немного сложнее.
Постоянный рост популярности HTML5 и распространение способных альтернатив Flash могут создать впечатление, что RTMP и Flash умирают. Но это не так.
Flash уже давно переживает упадок, уступив в последние годы значительную долю рынка HTML5, и его некогда доминирующее положение в мире видео теперь постоянно находится под угрозой.
Тем не менее, он по-прежнему широко представлен в Интернете и используется многими популярными сайтами, включая YouTube и Facebook.
Что касается RTMP, то он по-прежнему широко используется для потоковой передачи аудио- и видеоконтента. Однако его будущее менее определенно, чем у Flash.
Компания Adobe объявила о прекращении поддержки RTMP в 2020 году, что может означать конец этого протокола. Тем не менее, существует множество альтернатив, основанных на RTMP, поэтому он, вероятно, будет продолжать использоваться в той или иной форме еще долгие годы.
Так стоит ли вам стримить с помощью RTMP?
Это зависит от обстоятельств. Взгляните на некоторые плюсы и минусы использования RTMP.
Плюсы
- Это очень стабильно. По сравнению с другими альтернативами на рынке, очень маловероятно, что при использовании сервиса с поддержкой RTMP возникнут какие-либо сбои или простои.
- Низкая задержка и минимальная буферизация. RTMP уникален в этом отношении, а это значит, что пользователи могут смотреть видео в лучшем разрешении, а на загрузку медиафайла уйдет значительно меньше времени.
- Совместимость. Прочность и надежность RTMPS побудила больше производителей разрабатывать свои продукты для легкой интеграции с RTMP.
Cons
- RTMP требует постоянного соединения между клиентом и сервером, что может быть проблематичным при перебоях в сети
- Поскольку это проприетарное программное обеспечение, у него мало гибкости для опытных пользователей.
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
Как использовать Wave.video для потоковой передачи через RTMP?
Если вы хотите передавать потоковое видео через RTMP, Wave.video — отличный вариант. Вот как его использовать:
- Создайте учетную запись на Wave.video и войдите в систему, если вы этого еще не сделали.
- Выберите видео, которое вы хотите транслировать.
- Перейдите на страницу «Destinations» на Wave.video и нажмите на «Custom RTMP».
- Далее необходимо найти URL-адрес сервера и ключ потока для содержимого, которое вы пытаетесь транслировать. Для этого перейдите на веб-сайт с потоком, который вы хотите просмотреть.
- Вы можете использовать стороннее приложение или расширение для извлечения URL и ключа, если не знаете, как это сделать.
- Скопируйте URL-адрес сервера и ключ потока.
- Вставьте URL-адрес сервера и ключ потока в Wave.video.
- Создайте или запланируйте свой поток.
- Откройте студию прямого эфира и начните трансляцию.
Вот и все, быстро и просто!
Какие кодировщики поддерживают RTMP?
Существует множество аппаратных и программных средств кодирования, поддерживающих RTMP. Некоторые из них включают:
- Adobe Media Encoder
- Студия OBS
- Элементарный сервер
- TriCaster
- Проводное вещание
- vMix
- TeraDek
- Wowza Streaming Engine
- Ниагарское видео
RTMP против RTSP — что лучше?
RTMP и RTSP — это протоколы для потоковой передачи аудио, видео и данных через Интернет. Они во многом похожи, но некоторые ключевые различия делают их идеальными для разных ситуаций или предпочтений.
Вот краткая информация о ключевых различиях между ними:
- RTMP лучше подходит для потокового вещания в реальном времени, а RTSP — для потокового вещания по требованию.
- RTMP имеет меньшую задержку, в то время как RTSP может обеспечить более высокое качество видео.
- Для RTMP требуется Flash Media Server, в то время как RTSP может работать с любым медиа-сервером.
Итак, какой протокол лучше? Все зависит от ваших конкретных потребностей.
RTMP — хороший выбор, если вам нужна низкая задержка и вы не против использовать Flash. RTSP может быть идеальным вариантом, если вам нужно высококачественное видео или вы хотите использовать не Flash-медиасервер.
Что такое формат сообщений действия (AMF)?
AMF — это двоичный формат для кодирования и передачи данных через Интернет, который часто используется в сочетании с RTMP.
AMF позволяет передавать данные, несовместимые с RTMP, например, объекты ActionScript. Он также обеспечивает эффективный обмен данными между приложениями Flash и серверами.
Что такое URL RTMP и как получить его из Facebook или YouTube?
URL RTMP — это уникальный идентификатор, используемый для потоковой передачи видеоконтента в реальном времени на различные платформы.
Обычно он содержит IP-адрес, имя домена и номер порта.
Вы должны создать событие прямой трансляции на любой из платформ, чтобы получить его с YouTube или Facebook. Как только вы это сделаете, вы сможете найти URL RTMP в настройках события.
Заключительные размышления
RTMP, несомненно, оставил свой след в мире. Находится ли он на пути к выходу? В качестве решения для выхода — возможно, для входа — нет!
Даже если появятся другие альтернативы с такими же или более широкими возможностями, RTMP будет оставаться актуальным для передачи мультимедиа и потокового вещания.
Присоединяйтесь к нашей рассылке — это бесплатно!
Мы публикуем только хорошее
Связанные
Как протестировать веб-камеру на Windows и macOS
Как вести прямую трансляцию в Instagram на компьютере
Познакомьтесь с прямым потоковым вещанием Wave.video
Как вести прямую трансляцию на TikTok: полное руководство
Мы будем держать вас в курсе событий!
Присоединяйтесь к 5 000 маркетологов, которые читают наши статьи первыми
Что такое RTSP и зачем он нужен?
Роботы-курьеры, дроны, беспилотные автомобили и другие достижения современной науки и техники уже не кажутся чем-то из мира фантастики. Они стали привычным (ну, или почти) явлением для нас. Встроенные IP-камеры позволяют им “видеть” происходящее, а нам — видеть мир их “глазами”. А что, если мы Вам скажем, что в основе зрения (IP-камер) этих высокотехнологичных существ лежит технология, которой уже более 20 лет?
Слабо верится? Тогда садитесь поудобнее и готовьтесь к потрясению.
Мы расскажем Вам, как технология из 90-ых успешно используется и по сей день, почему до сих пор не нашлось ничего лучше и зачем вам об этом знать.
Спойлер: имя этому ветерану — RTSP.
В этой статье мы постараемся рассказать про RTSP, RTP, RTCP, как они существуют в современных IP-камерах, поддерживающих HEVC (H.265), с технологиями компьютерного зрения и аналитикой, а также каким образом они смогли дожить до сегодняшнего дня. Что же в RTSP хорошего и удачного и почему он не используется в телевидении?
Содержание:
- Что такое RTSP и зачем он нужен?
- Почему не UDP?
Что такое RTSP и зачем он нужен?
RTSP (Real Time Streaming Protocol) — протокол прикладного уровня, созданный для систем телекоммуникации и развлечений и предназначенный для управления доставкой мультимедиа данных. RTSP — сигнальный протокол, он управляет сессией передачи данных.
Изначально RTSP должен был использоваться для доставки развлекательного телевидения. И это действительно было так до поры до времени. Затем судьба-злодейка распорядилась иначе: RTSP был стёрт с лица телевидения и сейчас его можно встретить исключительно в IP-камерах.
Заложенные в RTSP принципы мы можем наблюдать и в современном стандарте WebRTC.
RTSP можно сравнить с пультом управления для телевизора. С его помощью можно запускать, ставить на паузу, останавливать и т. п. видео на телевизоре — медиа сервере. Да и управление происходит не через инфракрасное излучение, а через интернет. Передавать сам контент с помощью пульта от телевизора человечество пока не научилось (хотя какие наши годы), а управлять им — более чем.
Стоп, получается, что RTSP только управляет контентом, а как же передаётся сам контент?
На транспортном уровне для передачи потока в режиме реального времени используется протокол RTP (Real-Time Protocol). Роль RTSP эĸвивалентна удалённому управлению сервером потоĸового медиа. IP-камеры могут использовать как TCP, так и UDP для передачи потоĸового ĸонтента. Однако следует заметить, что для данной задачи в UDP нет практического смысла.
Почему не UDP?
Ввиду отсутствия современных механизмов компенсации потерь. Таким образом, данные просто-напросто теряются где-то по дороге. В нашей практике мы придерживаемся TCP, где в одном потоке в симбиозе сосуществуют данные и управление этими данными. Следует заметить, всё это прекрасно работает.
С понятием разобрались, с предназначением в общем смысле — тоже. А что с практикой?
Приведём пример: допустим, Вы установили видеонаблюдение на своем участке и опасаетесь, что у Вас украдут видеорегистратор вместе с записанными на нём данными и вы никогда не увидите лиц плохих парней. Что же делать в таком случае, не в сейфе же держать? Вы можете настроить запись видео прямиком в облако. С помощью RTSP-протокола возможна передача информации на удалённый облачный сервис. Кроме того, если захотите удалённо просмотреть архив с DVR, то связь с ним тоже будет происходить по протоколу RTSP, но только при условии, что у оборудования имеется поддержка RTSP-протокола. Для как такового вещания на веб-сайт RTSP уже не используется (хотя какие его годы, правда?), его затмили и вытеснили более молодые представители стриминговых технологий — HLS и DASH, не оставив нам даже тени взамен ему даже шанса на сопротивление и борьбу.
Связь между RTSP и HTTP RTP (RTCP)
Сходства:
- Оба используют простой теĸст для отправĸи сообщений, а синтаĸсис протоĸола RTSP аналогичен HTTP.
- RTSP изначально был разработан таĸим образом, чтобы быть совместимым с ранее написанным ĸодом анализа протоĸола HTTP.
Отличия:
- RTSP сохраняет состояние. Команды RTSP должны знать, в ĸаĸом состоянии они находятся в данный момент. Иными словами, ĸоманды RTSP всегда отправляются по порядĸу, ĸаждая следующая ĸоманда идёт после предыдущей. RTSP не разорвет соединение, в ĸаĸом бы состоянии он ни находился. HTTP же не сохраняет состояние. После того, ĸаĸ протоĸол отправит ĸоманду, соединение будет разорвано, и между ĸомандами нет зависимости.
- RTSP использует порт 554, а HTTP использует порт 80.
- По сравнению с RTSP, HTTP-запросы отправляются ĸлиентом, а отвечает — сервер. При использовании RTSP и ĸлиент, и сервер могут отправлять запросы, то есть RTSP может быть двунаправленным.
Не упустите обновления RTSP и других протоколов!
Подпишитесь, чтобы получать последние новости отрасли.
Подписаться на наши новости
Взаимосвязь между RTSP, RTP, RTCP и SDP
Давайте закрепим, каким образом между собой связаны RTSP, RTP, RTCP и SDP:
- RTP (Real Time Protocol)
Протоĸол передачи в реальном времени. RTP предоставляет временные метĸи, серийные номера и другие методы для обеспечения времени обработĸи во время передачи данных в реальном времени. - RTCP (Real-Time Transport Control Protocol)
Протокол для обеспечения ĸачества обслуживания и управления участниĸами. RTP и RTCP используются вместе. - RTSP (Real-Time Streaming Protocol)
Протокол для управления доставкой данных. - SDP (Session Description Protocol)
Протокол для описания сессии передачи потоковых данных.
Основные методы протоĸола RTSP. SIP и RTSP
Здесь мы хотели бы затронуть также и SIP (Session Initiation Protocol), чтобы наглядно выделить характерные особенности RTSP и противопоставить его SIP.
SIP (Session Initiation Protocol) похож на RTSP чисто визуально, однако логика у них весьма разная. Например, для RTSP чаще всего характерна одна TCP-сессия, в то время как для SIP это — антипаттерн.
Давайте проведём сравнение на основе SDP. В RTSP SDP сегодня используется исключительно для описания контента. В SIP же, так же как и в WebRTC (являющимся продолжением SIP) SDP используется для настройки портов и сетевой коммуникации.
Ниже перечислены основные методы RTSP:
Методы Описание DESCRIBE Запрос описания содержимого, например, в формате SDP OPTIONS Запрос поддерживаемых методов PLAY Запрос начала вещания содержимого PAUSE Запрос временной остановĸи вещания RECORD Запрос на записывание содержимого сервером REDIRECT Запрос на перенаправление на другое содержимое SETUP Запрос установĸи транспортного механизма для содержимого ANNOUNCE Запрос на обновление данных описания содержимого TEARDOWN Запрос на остановĸу потоĸа и освобождение ресурсов RTSP. Было/стало
Начнём с небольшого экскурса в историю.
RTP вместе с RTCP были разработаны в 1996 г. и закреплены в стандарте RFC 1889. SDP же увидел свет уже в апреле 1998 г. в стандарте RFC 2327. RTSP был разработан также в апреле 1998 г. инженерным советом Интернета (англ. Internet Engineering Task Force, IETF) и отразился в стандарте RFC 2326. Он незамедлительно приобрел большую популярность, поскольку с его помощью стало возможным проигрывание видео и аудио напрямую через интернет без необходимости скачивания контента на клиентское устройство. Люди были в восторге, сколько времени и ресурсов это может сэкономить!
RTSP родом из сетей, где задержки и потери при доставке небольшие по количеству и стабильные, т. е. из локальных сетей. Оттуда же и многие другие решения.
RTSP задумывался и разрабатывался ещё тогда, когда задачу управления доставкой до клиента хотели возложить на сервер. Таким образом, сервер отвечал за всю логику: что, когда и кому необходимо слать. Можно сказать, что сервер должен был быть максимально сложным, а клиент — максимально незамысловатым и простым. При переходе к протоколам HLS и DASH ситуация оказалась прямо противоположной. Теперь уже клиент — витиеватый, а сервер — примитивный. Получилось так, что функции интеллектуального контроля за доставкой сервера RTSP не дожили до сегодняшнего дня и канули в лету.
Современные RTSP-сервера по большей части представляют собой IP-камеры, которые и не знают о всех тех возможностях RTSP, которые задумывались десятки лет назад. Это значит, что абсолютно неважно будет ли какая-либо обратная связь от клиента. Если клиент получает данные — здорово, не получает — что ж, бывает, его проблемы.
Заметим, что RTSP создавался бок о бок с телефонией. И создавался он на базе уже существующих на рынке крайне удачных решений, немного видоизменив их: RTP для доставки данных, RTCP для сигнализации качества доставки этих данных (QoS) и SDP для передачи информации о контенте. Чтобы Вы понимали насколько удачными были эти решения, то те же RTP и RTCP, разработанные около 25 лет назад, сейчас в том же виде используются и в стандарте WeRTC, который является стандартом де-факто для общения в реальном времени! Таким образом, ещё в то время в них заложили всё, что было необходимо, чтобы оставаться на плаву до сих пор! Как Вам такое Илон Маск?
В своё время RTSP занимал лидирующие позиции среди стриминговых технологий для передачи видео- и аудиопотоков. Однако с течением времени технологии на основе HTTP с использованием алгоритма адаптивного битрейта затмили RTSP и RTMP. Несмотря на это RTSP и по сей день активно используется в области видеонаблюдения для захвата потока с IP-камер.
Важно отметить, что RTSP для IP-камер и для телевидения — это два абсолютно разных протокола. Тот самый RTSP для телевидения можно встретить только в legacy-системах, которые просто стоят и работают.
Раз уж мы начали разговор об RTSP, то грех не затронуть и RTMP.
RTSP vs RTMP
RTMP (Real Time Messaging Protocol) создавался как протокол для передачи функций, удалённого управления кодом, некий RPC-протокол, как раньше был CORBA или сейчас gRPC. RTMP был достаточно сложный сам по себе. На самом деле, как бы грубо это ни звучало, но RTMP жив лишь потому, что его вовремя начали поддерживать CDN. Сейчас практически любой CDN даёт возможность передачи видео по RTMP, но не проигрывания. Сегодня RTMP — это лишь протокол публикации, но никак не проигрывания, т. к. преимуществ по сравнению с нынешними HLS, CMAF и др. у него нет. В былые времена IP-камеры практически жили на кодеке MPEG-4 Part 2, а телевидение цвело и пахло на MPEG-2. А потом все дружно переехали на MPEG-4 Part 10, он же H.264, или AVC. Правильно, нечего на месте стоять, пора развиваться.
Хорошо, кодеки сменили, а как же RTSP и RTMP? Их в топку? А вот не тут-то было.
Помните, что RTSP был собран из уже самих по себе удачных решений: RTP, RTCP, SDP? Так вот IP-камеры, благодаря гибкости SDP, без всяких проблем и изменений перешли на H.264. Точно таким же образом IP-камеры переехали на H.265, или HEVC. RTMP же не смог так плавно совершить подобные переходы. Почему же? Да потому что RTMP не обладает такой суперспособностью возможностью добавлять новые кодеки, т. е. расширяться.
Как говорится, выживают сильнейшие.
Flussonic и RTSP
IT-продуктам, которые написаны впопыхах и не самым лучшим образом, переход с UDP на TCP дался с трудом. Качественно освоить асинхронную модель программирования им не удалось. На практике это выражается в переводе TCP-сокета в режим “неблокирующий”, в котором данные могут теряться, т. е. попытки софта писать данные в сокет оказываются тщетными, поскольку сокет заблокирован. В итоге, сама операционная система данные не принимает. Получается, что софт на камере просто “выбрасывает” данные, вследствие чего мы получаем просто месиво.
Есть ли способы решения этой проблемы? Конечно, например, соединить IP-камеру с сервером напрямую с помощью провода. Несмотря на то, что это официальный способ установки камер (они в общем-то не были предназначены для передачи данных через Интернет), в современных реалиях это кажется нелепым и несерьёзным решением.
Во Flussonic есть режимы для восстановления синхронизации. Например, если китайская камера теряет синхронизацию и данные, то во Flussonic реализованы специальные механизмы для восстановления потерянных байтов информации, которые тем самым позволяют реанимировать поток данных. Круто? Круто!
Что нужно для того, чтобы начать получать видео с IP-камеры во Flussonic?
Во-первых, IP-адрес камеры. Во-вторых, одного IP-адреса камеры недостаточно для получения с неё видео. Всегда нужно указать ещё один путь. Он не всегда приводится в документации, поэтому, возможно, придётся обращаться к продавцу или производителю камеры.
Как выглядят RTSP-ссылки:
- rtsp://hostname/path — синтаксис;
- rtsp://user:password@ip/path — URL с указанием авторизации;
- rtsp2://hostname/path — включает транскодирование звука в AAC.
- rtsp://192.168.0.100/h264 — пример настоящей ссылки.
Во Flussonic помимо всего прочего можно использовать опцию tracks=1 для захвата только видеодорожки. Ниже приведён пример конфигурации:
stream fake < input fake://fake; >stream input_rtsp < input rtsp://localhost/fake tracks=1; >Flussonic Media Server позволяет получать потоĸи по RTSP и многим другим протоколам.
Как добавить IP-камеру во Flussonic и вывести видео на веб-сайт можно узнать в документации.
С этими и многими другими возможностями Flussonic Вы можете ознакомиться в документации.
В чем разница между RTSP, RTMP, HLS?
В чем разница между RTSP, RTMP, HLS ? Надо получить видео поток без минимальной задержки. Приложение под android, а на android как знаю с RTMP проблемы. Но есть RTSP и HLS.
Отслеживать
задан 2 ноя 2016 в 13:18
721 6 6 серебряных знаков 19 19 бронзовых знаков1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Разница RTMP/RTSP/HLC в спецификациях интерфейсов, по сути одно и тоже, ТОЛЬКО В ПРОФИЛЬ.
RTMP — это перекодированный с RTSP поток во Flash Media .
HLC — это http обвертка UDP потока.
Рекомендую использовать HLC , так как он более адаптивен. RTSP спецификацию не меняли лет 5-6. Много косяков, рассчитан больше не стриминг, нежели upload .
¶ Стриминг в реальном времени
То, что показывает YouTube в прямых трансляциях — это не совсем реальное время. Достаточно посмотреть трансляцию какого-нибудь футбольного матча и его интернет-версию: гол в интернете случается на полминуты-минуту позже. Это HLS, HDS, MPEG-DASH — способы доставки потоков для массовой аудитории с заметной буферизацией и поверх протокола HTTP, то есть, без существенных отличий от обычных веб-страниц.
Но видеопроизводство и доставка контента требуют передачи если не в реальном времени, как в аналоговом телевидении, то хотя бы с допустимой задержкой.
¶ Допустимая задержка
- В телефонии принято считать реальным временем задержку 200 мс . Считается, что задержки меньше этого значения человек не замечает.
- В телевидении режиссер будет негодовать, если рассинхронизация между потоками будет превышать 1 кадр . При 25 кадрах в секнду это 40 мс . Рассинхронизация изображения и звука в 2-3 кадра — это плохо, но возможно, большую задержку увидит даже нетренированный зритель.
- В IP видео общепризнанных ориентиров нет, но ни 40, ни 120, ни 200 мс для технологий, работающих поверх обычных компьютерных сетей, недостижимы в общем случае. Нам придется работать с задержками 250-500 мс . Такие задержки доставки потоков дают IP-камеры RTSP. Но и на видеовыходе они тоже дают задержку — большинство цифровых камер в принципе работают не совсем в реальном времени.
¶ Рабочий процесс
На рисунке ниже показан путь от камеры до зрителя, режиссера (на микшере) и оператора (если камера управляется удаленно через веб-инструменты. Это частный случай, в общем можно назвать больше протоколов и вариантов управления. Но рассмотрим именно его, тем более, что он реализован в МИЭМе.
Потоковый
микшер
Стример
Стриминговая платформа
Пользователь
Оператор в
веб / мобильном приложении
Медиасервер
RTSP камераViewer does not support full SVG 1.1
Каждый этап задействует свои протоколы. В этот раз рассмотрим получение потоков с источников (здесь это камера) и передачу выходного потока (эфирной программы) на стриминговую платформу. В качестве такой платформы по умолчанию в этом курсе будем рассматривать Youtube, но на его месте может быть и VK, OK, Facebook, Twitch и т.д. Можно запустить и собственный сервер. Обобщенно всё стриминговое производство описывается так:
Contribution
Distribution
ProcessingViewer does not support full SVG 1.1
- Capture — создать потоки на источниках (камерах, кодерах)
- Contribution — собрать потоки с источников, доставить их в микшер
- Processing — обработка, линейный монтаж, титрование, кодирование для стриминга, управление источниками
- Distribution — отправить выходной поток (программу) на платформу, с нее раздать зрителям.
- Consuming — получение зрителями потоков со стриминговой платформы.
¶ RTMP vs RTSP
RTSP — Real-Time Streaming Protocol. 1998
RTMP — Real-Time Messaging Protocol. 2009, но использовался ранее
В нашем частном (!) случае мы рассматриваем в качестве источников RTSP устройства: это камеры, кодеры или программные серверы потоков RTSP.
¶ RTSP:
- Протокол включает в себя два протокола: медиаданные передаются по RTP, а команды по RTCP.
- Сервером выступает источник медиа, к нему подключаются клиенты-«зрители».
- Поток может быть защищен, обычно логин и пароль берутся из пользовательских данных на устройстве (камере, кодере).
- Передача потока происходит по запросу клиента. По аналогии с видеоплеером с пультом управления: зритель подает команду, плеер выполняет указанное действие.
- Источник в таком случае должен быть доступен по IP. То есть, нужно иметь «белый адрес» в сети.
- Порт по умолчанию для RTSP: 554, может быть и TCP, и UDP.
- Обычно у RTSP устройств работает автообнаружение в локальной сети в пределах своего сегмента. Используется Web Service Discovery, а для этого требуется multicast.
- Устройства RTSP обеспечивают минимальную задержку доставки потоков среди всех рассматриваемых протоколов. Быстрее работает только захват веб-камер или сигналов от HDMI/SDI устройств, но оба эти случая не относятся к работе с сетевыми потоками от источников.
То есть, RTSP-камеры бесполезны, если мы не можем «достучаться» до них по сети. Например, если такая камера находится в локальной сети, снаружи она доступна только если:
- На NAT проброшен порт. Если таких камер несколько, то пробросить придется несколько разных портов.
- Вы подключаетесь в VPN и образуете тоннель в эту локальную сеть.
Пример бесполезности работы с RTSP камерой: вы можете поставить соответствующее приложение на ваш смартфон, но работать с такой камерой вы сможете только внутри локальной сети. Например, постримить народные гуляния с улицы не получится — у вас нет прямого IP адреса в сети мобильного оператора.
Как все-таки решить задачу стриминга RTSP из общественных сетей: Если подключиться к VPN, то ваш поток можно будет увидеть на микшере — у смартфона будет прямой адрес и даже в локальной сети.
Зачем может понадобиться RTSP стриминг, если любая стриминговая платформа предлагает приложения RTMP-стриминга без всяких VPN? Дело в том, что отправить поток — это половина дела. Нужно его ещё принять. Если вы используете известные платформы, то туда вы отправите, а принять этот же поток для монтажа на микшере уже не сможете. Если даже поставить свой сервер RTMP, вы получите задержку от двух секунд, причем, эта задержка может меняться по ходу трансляции из-за накапливающихся ошибок и других помех.
¶ RTMP
Этот протокол изначально был закрытым проприетарным протоколом Adobe Flash-медиасервера. Здесь важно не путать Flash как технологию графики и анимации в браузерах и Flash Video (FLV), которое по сей день применяется для доставки видеопотоков.
Flash-анимацию официально похоронили в 2020, причём, хоронили почти 10 лет, начиная с мобильных устройств, где с ней было особенно много проблем.
В 2009 году Adobe опубликовала спецификацию протокола, но хитро — она была неполная. Существуют разные серверы, в т.ч. модуль для прокси-сервера NGINX, с ним имеет смысл познакомиться, если хотите работать со стримингом.Что нужно знать про RTMP:
- Сервером в RTMP является получатель потока. И сервер ничего не знает о том, кто на него посылает поток. Просто есть адрес сервера, имя потока и, по желанию, логин и пароль. Если эти данные скомпрометированы, то передавать на ваш канал могут другие источники — это потенциальная опасность. Сервер по умолчанию работает на порту 1935.
- Клиент при этом может не иметь прямого адреса и потому не возникает проблем со стримингом со смартфона из любой сети.
- Внутри своей экосистемы Flash видео работало весьма быстро: задержки не превышали задержку междугородней сотовой связи (она, конечно, больше 200 мс). Но при работе с веб-плеерами или микшерами задержки редко бывают меньше двух секунд.
- Структура Flash Video не гарантирует одинаковую длительность кадров. Синхронизация потоков там возможна только по стечению обстоятельств. То есть, для однокамерной съёмки без надобности в обратной связи этот способ передачи потоков подходит, но не для многокамерной съемки или передачи, требующей диалогового формата.