В чем разница между протоколом rtmp и rtsp?
Я просто хочу знать, в чем разница между протоколом rtsp и rtmp, и если на моем сервере есть mp3, и я играю его в своем андроиде с помощью http, как они отличаются в работе.
В андроиде, если я хочу реализовать rtmp или rtsp, что лучше? каковы ограничения rtmp и rtsp в android?
может кто-нибудь дать мне краткий ответ выше?
2 ответа
Протокол потоковой передачи в реальном времени (RTSP) — это протокол сетевого управления, предназначенный для использования в развлекательных и коммуникационных системах для управления потоковыми медиа-серверами. Протокол используется для установления и управления сеансами мультимедиа между конечными точками. Клиенты медиасерверов выдают команды, подобные VCR, такие как воспроизведение и пауза, чтобы облегчить управление воспроизведением медиафайлов в реальном времени с сервера.
Протокол обмена сообщениями в режиме реального времени (RTMP) был первоначально проприетарным протоколом, разработанным Macromedia для потоковой передачи аудио, видео и данных через Интернет, между Flash-проигрывателем и сервером.
Я бы использовал HTTP для потоковой передачи MP3.
Они оба являются протоколами для Streaming Media и на высоком уровне достигают того же самого. Укажите стандарт для потока медиа. Хотя RTMP был разработан и принадлежит Adobe, прежде чем стать общедоступным, тогда как RTSP был общедоступным стандартом с самого начала. Поскольку RTMP в основном используется Flash-плеером, я бы предположил, что потоки класса медиа-проигрывателя Android используют RTSP.
Какой Протокол Стриминга Лучше для Вас: RTMP или RTSP
Сравним протоколы потоковой передачи RTMP и RTSP. Расскажем, как они работают, какие у каждого плюсы и минусы. Подскажем, как выбрать в вашем случае.
Если вы хотите запустить платформу для трансляции видео с минимальной задержкой, у вас будет весьма ограниченное количество протоколов потоковой передачи данных для решения этой задачи. При этом если в качестве канала передачи видеопотока вы хотите использовать интернет, выбор будет еще меньше, поскольку вам нужно будет преодолеть ряд трудностей, например — джиттер, лаги или потеря пакетов. В этой статье мы сравним два таких протокола связи — RTMP и RTSP, опишем их преимущества с недостатками, а также дадим некоторые рекомендации по выбору наиболее подходящего для вас варианта.
Что такое протокол связи
Если сравнить видео, которые нужно отправить зрителям, с автомобилем, то протокол потоковой передачи — это правила дорожного движения и сама дорога, по которой автомобиль перемещается из одного места в другое. Если дорога хорошая, машина без проблем доедет до своей цели. Если же на дороге будут ухабы и ямы, то движение займет больше времени и машина может получить повреждения.
С видеоданными все так же: если протокол хороший, видеосигнал доберется до зрителя с минимальной задержкой и будет высокого качества. Если же протокол плохо реализован или не соответствует задаче, то видео на экране зрителя может «сыпаться», часто прерываться для подзагрузки, содержать артефакты, вовсе не грузиться или аудио- и видеосигналы будут рассинхронизированы.
Различные протоколы потоковой передачи данных ориентированы на разные аспекты потока (задачи). Обычно их делят на протоколы с адаптивным битрейтом, которые нацелены на уменьшение задержек и буферов для видеопотока, и те, что направлены на максимальное сокращение задержки, что позволяет передавать видеосигнал зрителям практически в реальном времени — live streaming.
RTMP и RTSP — это, пожалуй, два наиболее распространенных протокола, ориентированных на стриминг видео с минимальной задержкой. И хотя они созданы для достижения схожих целей, при пристальном сравнении между ними легко обнаружить существенные различия, которые важно знать.
Что такое RTMP и как он работает
Протокол обмена сообщениями в реальном времени, или RTMP — это стандартизированный протокол для передачи мультимедийных данных через интернет. Данная технология была разработана Macromedia (в настоящее время принадлежит Adobe), и изначально она использовалась для передачи данных между RTMP-сервером и Flash-плеером на устройстве пользователя. Сейчас Flash больше не используется из-за проблем с безопасностью, но RTMP все еще популярен.
Как протокол связи технология RTMP нацелена на обеспечение стабильной и плавной передачи увеличивающихся объемов данных, необходимых для передачи и приема видео в реальном времени. Что достигается посредством фрагментирования потока данных на небольшие одинаковые части (по умолчанию составляют 64 байта для аудиоданных и 128 байтов для видеоданных) и их последовательную передачу на принимающее устройство, которое затем снова собирает их в видеопоток.
После того как Flash устарел в 2020 году (Google и другие крупные игроки полностью прекратили поддержку Adobe Flash Player), RTMP стал использоваться в качестве протокола с открытым исходным кодом для вклада первой мили (передачи от кодировщика к сетевому видеохосту). Именно таким образом RTMP сейчас использует Facebook, YouTube, Periscope и большинство других платформ.
Сейчас RTMP существует в 5 вариантах:
Как работает потоковая передача RTMP
Как правило, прямая видеотрансляция работает следующим образом: камера снимает видео (или видеокарта захватывает экран) и отправляет его на хост или сервер видеоплатформы через кодировщик (этот этап обычно называют «первой милей»). Затем сервер или видеоплатформа обрабатывает этот поток и передает его дальше через сеть доставки контента (CDN) для распространения видеопотока на устройства пользователей (это «последняя миля»). Когда еще работал Flash, оба эти этапа проходили посредством RTMP, но с тех пор, как Flash устарел, RTMP больше не работает на «последней миле». С этого момента поток должен перехватить другой протокол связи (HLS, MPEG-DASH, CMAF или WebRTC).
- TCP/IP-рукопожатие. Клиент и сервер обмениваются между собой информацией, чтобы «договориться» о передаче потока.
- Установление связи. Клиент и сервер согласовывают все параметры и спецификации соединения с помощью последовательности сообщений.
- Передача потока. Клиент отправляет серверу вызов «create Stream», за которым следует сообщение проверки связи и воспроизведение.
Преимущества и недостатки RTMP
- Низкая задержка. С точки зрения прямых эфиров низкая задержка в основном означает надежное соединение, которое не отключится, даже если канал между сервером и зрителем немного нестабильный. Данный показатель также чрезвычайно важен для качества видео. Стабильное соединение RTMP обеспечивает благодаря тому, что он по умолчанию создается на TCP, тогда как низкая задержка достигается благодаря использованию эксклюзивного порта 1935, что устраняет необходимость буферизации видеопотока.
- Адаптируемость. В контексте трансляций адаптируемость означает возможность подключаться к трансляции и отключаться от нее когда угодно, кроме того, пользователи могут проматывать стрим назад (а затем и вперед) и присоединяться к прямому эфиру после его начала. Это очень полезные функции для онлайн-конференций, живых эфиров, стриминга видеоигр и простого видеозвонка.
- Гибкость. Технология RTMP позволяет интегрировать различные типы мультимедийного контента в один целостный пакет, «бесшовно» смешивая видео, аудио и текст (субтитры) на экране зрителя. Помимо этого, протокол поддерживает аудиопотоки в AAC- и MP3-форматах, а для передачи видео могут использоваться такие форматы, как MP4-, FLV- и F4V.
- Нет поддержки HTML5. Протокол RTMP не поддерживается HTML5-плеерами, которые на данный момент являются отраслевым стандартом для воспроизведения видео на стороне пользователя (в браузерах Mozilla, Google, Microsoft, Apple и Opera). Для «преобразования» RTMP-потока в HTML нужен конвектор, например HLS (протокол Http Live Stream, разработанный Apple).
- Проблемы с пропускной способностью. У RTMP есть некоторые уязвимости, связанные с низкой пропускной способностью. Они могут стать причиной периодических прерываний потоковой передачи видео, которые, как правило, очень сильно портят впечатление от просмотра видео.
- Несовместимость с HTTP. Последний недостаток RTMP — это невозможность передачи RTMP-потока через HTTP. Чтобы опубликовать RTMP-поток на сайте, нужно реализовать специальный сервер, такой как Flash Media Server, и использовать CDN или платформу потокового видео.
Что такое RTSP и как он работает
Для обеспечения плавной и согласованной потоковой передачи данных RTSP использует два других сетевых протокола связи — TCP для выдачи и приема команд управления (например, запроса на воспроизведение или остановку) и UDP (протокол пользовательских датаграмм) для доставки аудио, видео и данных. Благодаря этому клиент может начать воспроизводить RTSP-поток во время загрузки потока.
Хотят RTSP можно использовать как для прямых трансляций, так и для передачи видео по запросу, сейчас его обычно используют на последней миле для передачи видеопотока с облака в проигрыватель устройства пользователя, поскольку данный протокол позволяет зрителю воспроизводить, приостанавливать и перематывать видео. Кроме того, RTSP также популярен в системах, где нужно передать видеосигнал с камер по IP, например с IP-камер или камер видеонаблюдения.
Как работает потоковая передача RTSP
Как только устройство (плеер) узнает список команд и как сделать запрос, он передает запрос описания видеоконтента на сервер потоковой передачи, и сервер отвечает описанием этого мультимедиа. Дальше устройство отправляет запрос на загрузку, а сервер отвечает информацией о транспортном механизме, и дальше инициируется процесс потоковой передачи видео через указанный механизм.
Так как RTSP зависит от выделенного сервера и полагается на RTP, данный протокол не поддерживает шифрование видеоконтента или повторную передачу потерянных пакетов. Кроме того, RTSP не совместим с HTTP, следовательно, он не позволяет напрямую воспроизводить видеопоток в веб-браузере. Для этого нужно конвертировать видеопоток через специальный промежуточный сервер.
Преимущества и недостатки RTSP
- Сегментированная потоковая передача. Это означает возможность просмотра видео без необходимости его загрузки целиком перед просмотром, что удобно, если вам нужно организовать передачу видео по запросу.
- Настройка. RTSP позволяет создавать собственные приложения для потоковой передачи видео, которые будут использовать многопротокольный подход TCP + UCD — от видеомессенджеров до программного обеспечения для онлайн-видеоконференций.
- Меньшая популярность. Большинство веб-браузеров, видеоплееров и потоковых сервисов не поддерживают RTSP, что затрудняет трансляцию видеосигнала напрямую в браузер. Для этого необходимо использовать специальную службу потоковой передачи RTSP в реальном времени.
- Несовместимость с HTTP. Поскольку RTSP изначально создавался для использования в частных сетях, вы не можете напрямую передавать RTSP через HTTP. Для этого нужно специальное программное обеспечение, которое будет принимать видеопоток с RTSP-сервера, встраивать его на веб-страницу и давать возможность зрителям воспроизводить его на своих экранах.
Технические характеристики RTMP vs RTSP
Какой протокол лучше для вас
IP-камеры → RTSP. Практически все IP-камеры поддерживают RTSP, что обусловлено тем, что IP-камеры существовали задолго до создания протокола RTMP. И поскольку RTSP был (и остается) достаточно простым и эффективным инструментом для передачи видеосигнала, нет необходимости что-то менять.
В связке RTSP и IP-камеры, сама IP-камера действует как RTSP-сервер. Это означает, что для подключения видеокамеры к серверу IP-камеры и трансляции видео необходимо запустить RTSP-клиент, например, посредством Restreamer Red5 Pro. Данный плагин позволяет подключиться к потоку в качестве клиента и перенаправить его на другие конечные точки, поддерживающие Red5 Pro (браузер, работающий с WebRTC).
IoT-устройства → RTSP или RTMP. Датчики, дроны, роботы, машины и другие устройства Интернета вещей могут выиграть от возможности транслировать видео в реальном времени. Поскольку такая трансляция не только покажет, что «видит» IoT-устройствоно и позволит управлять им в реальном времени. Благо, в большинство этих устройств изначально встроено программное обеспечение с поддержкой RTSP. Однако некоторые производители, такие как DJI, предпочитают RTMP.
Red5 Pro Mobile SDK → RTSP. Обычно мобильные устройства не поддерживают RTSP. Однако его можно легко добавить с помощью Red5 Pro Mobile SDK, который использует RTSP для трансляции видеоконтента в реальном времени на мобильные устройства и обратно через приложение Red5 Pro. Таким образом можно создавать как отдельные соединения источник-зритель, так и вести большое количество трансляций к большому количеству зрителей (подписчиков стримера).
YouTube, Twitch, Facebook → RTMP. Несмотря на отказ от Flash Media Player, RTMP до сих пор используется в качестве протокола приема во многих сторонних потоковых сервисах и приложениях, например в YouTube Live, Twitch и Facebook. В Zoom также встроена поддерживает вывод видео потока по RTMP.
Старый аппаратный кодировщик → RTMP. Многие аппаратные кодировщики видео (особенно это актуально для старых устройств) принимают только RTMP-потоки. Если ваша задача / проект требует использования такого кодировщика, то выбор между RTMP и RTSP для вас будет очевиден.
Заключение
Споры о том, какой протокол потоковой передачи лучше — RTMP или RTSP, продолжаются уже больше двадцати лет, и, похоже, им не будет конца, пока один из протоколов не устареет окончательно. Что, скорее всего, случится еще нескоро из-за резкого роста числа влогеров, стримеров и прочих энтузиастов live-трансляций.
Правда, если подумать, вам не обязательно выбирать между одним из этих протоколов потокового видео. Выбрав надежного технического партнера, такого как компания-разработчик Merehead, вы можете разработать решение, которое вберет в себе лучшее этих двух протоколов и обойдет их недостатки. Кастомная разработка потребует немного больше времени и ресурсов, чем готовые решения, но в долгосрочной перспективе она все равно будет более выгодной.
RTMP vs. RTSP: Which Protocol Should You Choose?
The wide world of video streaming is complicated enough without needing to consider which ingest protocol best suits your goals. And if the term “ingest protocol” already has your head spinning, then strap in. It only gets more complicated when you acknowledge ongoing updates and technology (like Adobe’s Flash Player) that have long since been relegated to the scrap heap.
Scared? Don’t be. We’ve got you covered with a thorough breakdown of two of the most widely used ingest protocols: Real-Time Messaging Protocol (RTMP) and Real-Time Streaming Protocol (RTSP). In this article, we talk about what makes them unique, how they work, and most importantly, how they measure up to your needs.
Table of contents
Streaming Protocols: A Brief Review
Put simply: if your data is a passenger, then your codec is a car, and the streaming protocol is the highway and set of “road rules” that makes it possible for content to get from one place to another.
When it comes to streaming video or audio, your codec is the compressed version of those files, and the protocol is the set of rules that govern how those files are broken down and sent to their destination. After all, different playback devices require different data packages. And your media needs to be compatible with a variety of playback devices to reach end users. For example, Apple devices work with the popularly used HTTP Live Streaming (HLS) protocol, but not with Dynamic Adaptive Streaming over HTTP (MPEG-DASH).
Finally, to understand how protocols like RTMP and RTSP work (and in some cases no longer do), you need to understand that protocols can layer on top of one another. Transmission Control Protocol (TCP) acts as a foundation for RTMP. Conversely, Hypertext Transfer Protocol (HTTP) acts as the foundation for newer protocols. This will come up again when discussing pros and cons of RTMP vs. RTSP.
RTMP vs. RTSP: How They Work
That’s all well and good, but what is an “ingest” protocol and how does it fit into your streaming workflow?
Also known as a contribution protocol, ingest protocols are used for the first part of data delivery during the streaming process. Note the below graphic, which breaks streaming down into four key parts:
- Contribution – Raw video or audio data is sent to an encoder, which encodes it using an ingest protocol. This is sometimes referred to as the first mile.
- Processing – The encoded data is sent to a streaming media server. Here data may be transcoded to alter the resolution and bitrate of the original raw data. It may also be transmuxed to adjust the streaming protocol.
- Scaling and Delivery – Using edge servers or a content delivery network (CDN), your data is prepared for a larger audience. This may or may not come into play for your stream.
- Delivery – This is the last mile. The data is sent to various playback devices for viewing. Which playback devices you can reach depends on your chosen protocol(s).
Note the protocols in fine print on the right and left edges of the graphic. These are protocols that can be used at contribution and delivery. Web Real-Time Communications (WebRTC) can be used for both. However, in most case, protocols will need to adjust during the workflow.
What Is RTMP?
Remember when you tried playing videos back in the day, and your computer would tell you to update your Flash plugin? That was RTMP knocking at your door.
Real-Time Messaging Protocol (RTMP) was once the standard for streaming across the entire workflow — from contribution right through to delivery. It was developed by Macromedia (later purchased by Adobe) for streaming to Flash players.
After it was no longer proprietary, RTMP became even more widely used. For more than two decades, RTMP was the standard for live and on-demand streaming from end to end. However, it lost its luster as Flash started being phased out and HTTP-based protocols became the new standard for streaming to playback devices.
All that said, RTMP is still alive and kicking. It is the most popular ingest protocol for live and on-demand streaming. It just needs to partner with an HTTP-based protocol (like HLS or MPEG-DASH) for last-mile delivery.
RTMP Pros
The four key benefits of RTMP as an ingest protocol are: reliability, adaptability, flexibility, and low latency. Let’s break those down a little further.
Reliability
RTMP operates on a three-way handshake between the client and server. Basically, the client (where the data is coming from) pings the server (the media server that manages and transmuxes the data), asking for a connection. The server responds, starting the connection. The client then responds to that response, maintaining the session. This results in a continuous connection between where the data is coming from and where it is being transmuxed for delivery to playback devices.
The result is a very steady, reliable connection that is not subject to the whims of the server’s bandwidth. This is particularly handy where live streaming is concerned as raw data is being recorded, encoded, fed to the streaming server, and transmuxed for playback in a continuous stream.
Adaptability
With RTMP, it’s possible to set up a stream where viewers aren’t locked into one particular “direction.” In other words, they can pause, skip, and rewind. It also allows viewers to join live streams after they’ve already begun.
Flexibility
RTMP works with a wide range of media types, not just audio and visual data. RTMP supports text and graphic data. It also makes it easy to blend data types (audio, visual, and text) into one cohesive package.
Low Latency
RTMP operates with three-to-five seconds of latency. That is to say, your live stream will feature on playback devices with only a three-to-five second delay. Certainly, this is no longer the fastest available, with WebRTC coming in at sub-second ultra-low latency, but it is considered a good and reliable target.
RTMP Cons
Now for the bad news. RTMP is not perfect, and its shortcomings can best be summarized as follows: HTTP incompatible, lack of support, and susceptibility to bandwidth issues (wait, what?).
HTTP Incompatible
Let’s address the elephant in the room. RTMP is no longer viable for last-mile delivery. Of course, we already knew that; that’s why we are talking about it only for ingest purposes. It does not work with HTTP, nor can it be played on HTML5 players (the new industry standard).
Lack of Support
Adobe officially announced that Flash was no longer being supported in December of 2020. With Flash gone, there was apparently little need to keep up with RTMP. While it is still in wide use, the protocol itself is no longer being updated or support. Perhaps Adobe will be announcing its death sometime soon.
Bandwidth Issues
I know what you’re thinking. We just covered how reliable the connection between the client and server are. It’s true, but with a caveat. TCP, upon which RTMP sits, has a window in which it can store data when bandwidth is low, and the data can’t be transmitted. Once the bandwidth picks back up and streaming resumes, it can pull from that data reservoir without missing a beat. So, what’s the problem? The TCP window for saving this data is limited and there is no process in place for recovering lost data outside of this window. So, RTMP can deal with bandwidth issues, but only to a limited extent.
What Is RTSP?
Real-Time Streaming Protocol (RTSP) is a protocol developed by RealNetworks in conjunction with Netscape and Columbia University back in 1996. It’s sometimes used as an umbrella term for RTP, RTCP, and RTSPS (aka Secure RTSP).
RTSP was designed to establish and maintain a connection between the raw data source (client) and the streaming server. Additionally, it was designed to allow control of the entertainment and communication systems within a streaming server. This real-time media control allows for pause and play functionality.
This combination of reliability and control has long made it a popular choice for closed-circuit television (CCTV) and similar surveillance systems. As such, it’s the protocol of choice for many IP cameras, which has served to further its hold on this corner of the streaming market.
RTSP Pros
What are the key benefits of the RTSP protocol? It has real-time media control, has very low latency, is customizable, and allows for segmented streaming. Let’s start at the top.
Real Time Media Control
It’s worth noting that RTSP doesn’t transport the data from the client to the server itself. It works as part of a larger system of protocols. RTSP’s job is to facilitate multimedia playback by defining specific control sequences. The actual data transport is usually left up to Real-Time Transport Protocol (RTP).
The media control involved in this is nuanced and can come from either the client or the server end. Think of it as the remote control for streaming servers. The streamer themselves can manipulate the stream with play, pause, etc. even as they are recording.
Very Low Latency
How low is very low? Think less than two seconds. It’s no WebRTC, but it gets the job done fast. For this reason, RTSP is commonly used for real-time security systems.
Customizable
RTSP offers greater flexibility in terms of the protocol it uses as its foundation. We mentioned earlier that RTMP sits on top of TCP. RTSP can use TCP as well, but it also works with User Datagram Protocol (UDP), which allows for additional functionality options.
Segmented Streaming
When paired with UDP, RTSP allows you to chunk your streams so viewers can start viewing them before the content is fully downloaded. This allows for very low-latency streaming, albeit the quality of video and audio can suffer.
RTSP Cons
Like RTMP, RTSP is not HTTP-compatible. Other downsides to this ingest protocol include lack of support for broadcast over the internet and lack of optimization options.
Lack of Support
RTSP is very highly used and regarded in its specific corner of the streaming world: namely, closed and in-house private networks, especially through the use of IP cameras. However, it is not typically used for larger scale broadcasts over the internet and is, therefore, not widely supported by encoders.
Lack of Optimization Options
RTSP is not really intended for your next live broadcast to thousands of viewers. It is not optimized for quality or scalability and requires additional workflow elements to achieve what other protocols might achieve more naturally. Like RTMP, RTSP requires a dedicated server, which limits broadcast scale options.
RTMP vs. RTSP: Which Is Right for You?
We tried to cover a lot of ground in this post, but the long of the short of it is this: RTMP and RTSP are both legacy protocols that are likely headed for obsolescence. That said, they’re integrated into so many existing workflows and architectures that it could be another 30 years before they completely disappear.
They share many of the same limitations, including lack of compatibility with HTTP and HTML5 playback devices, a need for a dedicated server, and the general sense that we aren’t developing these technologies anymore – we are simply finding ways to work around them.
That said, there is still a time and place for each and which you choose depends on what you’re hoping to accomplish. After all, these protocols were designed for low latency and reliability. Ask yourself who you are trying to reach, if your stream is live or pre-recorded, if it is closed circuit or over the internet, and so on. Realistically, it shouldn’t be hard to determine which of these will best suit your workflow.
Once you’ve nailed that down, find a streaming solution that can help take your ingest protocol and make it work to your advantage.
Русские Блоги
Подключение и отличие сетевого протокола потоковой передачи мультимедиа (RTP RTCP RTSP RTMP HLS)
Подключение и отличие сетевого протокола потоковой передачи мультимедиа (RTP RTCP RTSP RTMP HLS)
Каталог статей
Резюме из трех предложений
RTP RTCP RTSP RTMP HLS разница и подключение
RTP передает данные потокового мультимедиа, RTCP управляет RTP, синхронизирует, а RTSP инициирует / останавливает потоковую передачу мультимедиа.
RTP и RTCP являются сестрами друг друга, RTSP может использовать RTP для передачи данных, но нет связи привязки, также можно использовать TCP / UDP.
RTSP, RTMP, HLS могут использоваться для прямой трансляции и по запросу, это три разных протокола прикладного уровня.
Схема уровня протокола потокового мультимедиа
Понимание расположения протокола RTP (RTCP):
RTP фактически находится между уровнем приложения и транспортным уровнем. В то же время он имеет различные характеристики прикладного и транспортного уровня. Эту особенность необходимо тщательно идентифицировать.
С точки зрения разработчиков приложений, RTP должен быть частью уровня приложения. На отправляющей стороне приложения разработчик должен написать программный код для инкапсуляции пакета (пакета данных) с помощью RTP, а затем передать пакет RTP в интерфейс сокета UDP. На принимающем оконечном устройстве после того, как пакеты RTP поступают в программу уровня приложения через интерфейс сокета UDP, пакеты RTP будут извлечены из блока данных приложения с использованием программного кода, написанного разработчиком. RTP фактически предоставляет платформу разработки для разработчиков видеопрограмм.
RTP также можно понимать как протокол транспортного уровня.Протокол RTP фокусируется на транспортном уровне и является протоколом уровня выше протокола UDP (дейтаграммы пользователя). Поскольку RTP инкапсулирует блоки данных мультимедийных приложений (включая видеопотоки и аудиопотоки), ключевым моментом является предоставление услуг транспортного уровня (временные метки, серийные номера, идентификаторы источников синхронизации и т. Д.), Поэтому RTP можно рассматривать как транспортный уровень поверх UDP. Протокол подуровня, обратите особое внимание на протокол подуровня.
В целом, протокол RTP фактически является протоколом между транспортным и прикладным уровнями, и его роль заключается в завершении инкапсуляции медиапотока поверх протокола UDP.
Потоковое мультимедиа на основе RTP
Потоковая передача — это ключевая технология для реализации потокового мультимедиа. Используйте потоковую передачу для просмотра потоковых мультимедийных программ во время загрузки. Поскольку Интернет основан на передаче пакетов, пакеты данных, принимаемые принимающей стороной, часто задерживаются и выходят из строя (потоковая передача построена на UDP).
Чтобы добиться потоковой передачи, необходимо начать с уменьшения задержки и восстановления синхронизации пакетов.
«На передающей стороне, чтобы уменьшить задержку, данные передачи часто предварительно обрабатываются (пониженное качество и эффективное сжатие (распространенные форматы сжатия, такие как aac / h264 . ))»
«Чтобы восстановить синхронизацию на принимающей стороне, часто используется принимающий буфер, а для достижения плавного воспроизведения мультимедиа обычно используется буфер воспроизведения».
Протокол RTP (Транспортный протокол реального времени) создается на основе протокола UDP и часто используется с RTSP и RTCP. Он используется для передачи мультимедийных данных в сети в режиме реального времени и предоставляет услуги сквозной передачи в реальном времени, но качество услуг не гарантируется.Качество услуг обеспечивается RTCP.
RTP — это самый базовый протокол в наборе протоколов потокового мультимедиа. Это стандарт, предложенный IETF. Он соответствует документу RFC RFC3550. RFC3550 не только определяет RTP, но также определяет поддерживающий связанный протокол RTCP.
Основная ответственность протокола RTP заключается в том, чтобы отвечать за передачу в реальном времени пакетов данных потокового мультимедиа и потоков мультимедиа. Каждое сообщение данных RTP состоит из заголовка и полезной нагрузки. Первые 12 байтов заголовка имеют фиксированное значение. Загруженные данные могут быть аудио или видео данными. Формат заголовка дейтаграммы RTP следующий: 
«RTP можно сравнить с грузовиком. Грузовик можно загружать вещами по желанию, но объем ограничен. Если он слишком велик, вам необходимо заключить субподряд. Он загружается и отправляется по одному, и он не обязательно может прибыть на противоположный конец по порядку. , Может быть, даже отсутствует "
Тип полезной нагрузки RTP
Поскольку некоторые типы появляются поздно и не имеют определенного значения PT, они могут использовать только динамическое значение PT, то есть 96–127, поэтому каждый обычно указывает значение PT H264. 96.
RTCP (протокол управления транспортировкой в реальном времени или протокол управления RTP) является родственным протоколом транспортного протокола реального времени (RTP).
RTCP часто работает вместе с RTP. RTP реализует фактическую передачу данных, а RTCP отвечает за отправку управляющих пакетов всем на телефоне. Его основная функция — обеспечивать обратную связь по качеству обслуживания, предоставляемого RTP, и синхронизировать аудио- и видеоданные. Сам он не передает никаких данных. . Они могут оптимизировать эффективность передачи за счет эффективной обратной связи и минимальных накладных расходов, поэтому они особенно подходят для передачи данных в реальном времени по сети.
Во время сеанса RTP каждый участник периодически передает пакеты RTCP. Пакет RTCP содержит статистическую информацию, такую как количество отправленных пакетов данных и количество потерянных пакетов данных, поэтому сервер может использовать эту информацию для динамического изменения скорости передачи и даже изменения типа полезной нагрузки.
В соответствии с различной управляющей информацией, передаваемой RTCP, пакеты RTCP можно разделить на ** RR ** (пакет отчета получателя), SR (Пакет исходного отчета), SE
DS (Пакет описания источника), BYE (Заявление о выезде) и ** APP ** (Спецпакет) 5 видов
Протокол потоковой передачи в реальном времени (RTSP, Real-time Streaming Protocol) — это протокол потоковой передачи мультимедиа, используемый для управления звуком или изображениями и позволяющий управлять несколькими потоками, но соединение RTSP не привязано к соединению транспортного уровня (например, RTP). Сервер даже может выбрать TCP или же UDP Для доставки потокового контента.
Его синтаксис похож на HTTP 1.1, но он не делает упор на синхронизацию времени, поэтому он может допускать сетевые задержки.Это протокол управления воспроизведением мультимедийных файлов на основе текста. RTSP определяет формат потока, и данные потока могут передаваться через RTP; поэтому эффект RTSP в реальном времени очень хорош, подходит для видеочата, видеонаблюдения и других направлений.
Запросы RTSP в основном включают, например, « Опишите (опишите), установите (настройку), воспроизведение (воспроизведение), паузу (паузу), воспроизведение (удаление), параметры (параметры) » Подождите, во время разговора RTSP, Setup Вы можете указать порт, используемый RTP / RTCP, " play ， pause ， teardown "Вы можете запускать и приостанавливать отправку RTP.
Пример запроса RTSP
Запрос НАСТРОЙКИ
Запрос SETUP указывает, как передать один медиапоток. Это необходимо сделать перед отправкой запроса PLAY. Запрос содержит URL-адрес медиапотока и спецификатор передачи. Этот спецификатор обычно включает в себя локальный порт для приема данных RTP (аудио или видео) и другой порт для данных RTCP (метаинформация). Ответ сервера обычно подтверждает выбранные параметры и заполняет недостающие части, например порт, выбранный сервером. Вы должны использовать SETUP для настройки каждого медиапотока перед отправкой совокупного запроса воспроизведения.
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001
S->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
Session: 12345678
Запрос на воспроизведение
Запрос воспроизведения на воспроизведение приведет к воспроизведению одного или всех медиапотоков. Вы можете складывать запросы воспроизведения, отправляя несколько запросов на воспроизведение. URL-адрес может быть совокупным URL-адресом (воспроизводить все потоки мультимедиа) или отдельным URL-адресом мультимедийного потока (воспроизводить только поток). Вы можете указать диапазон. Если диапазон не указан, поток будет воспроизводиться с начала и воспроизводиться до конца, или, если поток приостановлен, воспроизведение возобновится с того места, где оно было приостановлено.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Range: npt=5-20
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
ПАУЗА запрос
PAUSE Запрос на паузу Временно останавливает один или все медиапотоки, чтобы их можно было возобновить с помощью запроса воспроизведения позже. Запрос содержит агрегированный URL или URL-адрес медиапотока. Параметр области в запросе PAUSE указывает, когда следует приостановить. Если параметр scope опущен, пауза будет немедленно выполняться на неопределенный срок.
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 5
Session: 12345678
RTMP (протокол обмена сообщениями в реальном времени) — это открытый протокол прикладного уровня, разработанный Adobe Systems для передачи аудио, видео и данных между проигрывателями Flash и серверами.
Транспортный уровень RTMP — это протокол TCP, но эта надежная гарантия также вызовет некоторые проблемы, то есть предыдущие пакеты данных не доставляются по назначению, а последующие данные не могут быть переданы. К счастью, текущая пропускная способность сети может в основном соответствовать требованиям протокола RTMP для передачи видео обычного качества, а общая задержка составляет 1-3 секунды.
Базовая единица данных, передаваемых с помощью RTMP, — это сообщение, но на самом деле наименьшая единица передачи — это Chunk (блок сообщения), потому что протокол RTMP для повышения скорости передачи, при передаче данных, сообщение будет разделено, чтобы сформировать меньший Чанки, эти блоки являются Чанками.
Расширение RTMP
RTMP — это семейство протоколов, включающее базовый протокол RTMP и различные варианты, такие как RTMPT / RTMPS / RTMPE:
・ Протокол открытого текста, который работает поверх TCP, используя порт 1935;
・ RTMPE добавляет функцию шифрования на основе RTMP;
・ RTMPT инкапсулируется в HTTP-запросе и может проходить через брандмауэр;
・ RTMPS похож на RTMPT, но использует соединение HTTPS;
Протокол RTMP (протокол обмена сообщениями в реальном времени) используется Flash для передачи объектов, видео и аудио. Этот протокол основан на протоколе TCP или протоколе опроса HTTP.
Протокол RTMP похож на контейнер, используемый для хранения пакетов данных. Эти данные могут быть данными в формате AMF или видео / аудиоданными в FLV. Одно соединение может передавать несколько сетевых потоков по разным каналам. Пакеты в канале передаются пакетами фиксированного размера.
HTTP Live Streaming (HLS) — это протокол передачи потокового мультимедиа на основе HTTP, реализованный Apple Inc., который может реализовывать потоковую передачу в реальном времени и потоковую передачу мультимедиа по запросу. Он в основном используется в системе iOS для передачи звука для устройств iOS (таких как iPhone и iPad). Живое видео и программы по запросу. HLS по запросу — это, по сути, обычный сегментированный HTTP по запросу, разница в том, что его сегменты очень малы.
По сравнению с обычными протоколами прямой трансляции потокового мультимедиа, такими как RTMP, RTSP, MMS и т. Д., Самая большая разница в прямой трансляции HLS заключается в следующем: «То, что получает клиент прямой трансляции, не является полным потоком данных. Протокол HLS хранит поток данных в реальном времени как непрерывный краткосрочный медиафайл (формат MPEG-TS) на стороне сервера, и клиент непрерывно загружает его. И воспроизводите эти небольшие файлы, потому что сервер всегда будет генерировать новые небольшие файлы из последних данных в реальном времени, поэтому, пока клиент продолжает последовательно воспроизводить файлы, полученные с сервера, осуществляется прямая трансляция ».
Из этого видно, что, по сути, можно считать, что HLS — это технический способ прямой трансляции по запросу. Поскольку данные передаются по протоколу HTTP, нет необходимости учитывать проблемы с брандмауэрами или прокси, а продолжительность файла сегмента очень мала, и клиент может быстро выбрать и переключить скорость кода, чтобы адаптироваться к воспроизведению при различных условиях полосы пропускания. Однако эта техническая характеристика HLS определяет, что его задержка обычно выше, чем у обычных протоколов прямой трансляции потокового мультимедиа.
HLS предоставляет адрес m3u8, браузер Apple Safari может напрямую открывать адрес m3u8, например
Спутниковое телевидение Гонконга: http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8
подводить итоги
RTP RTCP RTSP разница и подключение
RTP передает данные потокового мультимедиа, RTCP управляет RTP, синхронизирует, а RTSP инициирует / останавливает потоковую передачу мультимедиа.
RTP и RTCP являются сестрами друг друга, RTSP может использовать RTP для передачи данных, но нет связи привязки, также можно использовать TCP / UDP.
RTSP, RTMP, HLS могут использоваться для прямой трансляции и по запросу, это три разных протокола прикладного уровня.
Отличие и подключение RTSP, RTMP, HLS
RTSP, RTMP, HLS могут использоваться для прямой трансляции и по запросу, это три разных протокола прикладного уровня.
・ HLS имеет большую задержку, подходит для видео по запросу
・ RTSP имеет лучшую производительность в реальном времени, но его реализация сложна, подходит для видеочата и видеонаблюдения.
・ RTMP сильно поддерживается браузером, и в него можно играть сразу после загрузки плагина Flash. Он очень популярен. Напротив, в браузере очень сложно воспроизводить rtsp.
О прямой трансляции
В приложениях прямой трансляции RTMP и HLS могут охватывать всех клиентов, за которыми нужно смотреть.
・ Преимущество RTSP заключается в том, что udp / rtp можно использовать на транспортном уровне с хорошей производительностью в реальном времени, а задержкой можно управлять в пределах 1 с.
・ Основным преимуществом RTMP является то, что задержка относительно мала (1-3 с), а поддержка RTMP очень полная, и он может воспроизводить поток RTMP непрерывно в течение длительного времени. В прошлом было много SIP-видео. Конференция заменена на RTMP.
・ Преимущество HLS заключается в том, что он напрямую использует протокол http для запроса потоковых данных и может свободно переключаться между версиями с разной скоростью для достижения плавного воспроизведения. Недостатком является то, что задержка относительно велика (более 10 с).
Каждый из трех протоколов имеет свои преимущества, в основном зависящие от выбора сцены.Конечно, более крупные компании могут заключать некоторые частные соглашения, чтобы обеспечить лучшее и большее соответствие сцене.