我们已经准备好了,你呢?

我们与您携手共赢,为您的企业形象保驾护航!

RTSP 是目前仍在使用的两种运行时间非常长的媒体流协议之一;由于 RTSP 的流媒体服务器实用程序,您可能熟悉该首字母缩略词。您可能不太熟悉 RTSP 的悠久历史(它是 1996 年发明的!)及其现状和应用。

随着协议的发展,RTSP 流媒体有时被认为是其他“老式”流媒体技术 RTMP 的不那么受欢迎的竞争对手,或者与基于 Web 服务器的新协议相比不太相关。技术随着时间的推移发生了变化,旧的协议已经改变了角色并且仍然有用,但是在大多数情况下,它们本身不再被用作流媒体解决方案。相反,RTSP 和 RTMP 现在最常用于编码和摄取媒体,作为更大的流式工作流的“靠前英里”,而不是它们以前作为“最后一英里”交付格式的角色。

流媒体协议和视频广播可能会变得非常复杂和技术性很强,更不用说充满了首字母缩略词,但本文将在几个简明的项目符号中列出您需要了解的有关实时流媒体协议的所有信息,以确定是否使用 RTSP工作流程的关键部分,并建议潜在的 RTSP 到 RTMP 摄取解决方案,可以帮助您的 RTSP 设备输入与支持 RTMP 编码的平台更兼容。

RTSP 流媒体的历史

RTSP 流媒体已经存在了很长一段时间。 RealNetworks、Netscape 和哥伦比亚大学之间的合作伙伴关系于 1996-97 年首次开发并交付了该协议。 RTSP 协议是通过 RealNetworks 的 RealAudio 和 Netscape 的 LiveMedia 的流媒体实践的实践经验开发的。正如 Mozilla 的 wiki 所说,它的主要目的是对媒体流进行“类似 VCR 的控制”(年轻的读者,问你的父母)——换句话说,现在常见的播放、暂停、倒带和以其他方式指导观看体验的能力.

RTSP 在 1998 年被标准化为 RFC 2326,并立即成为一种有用的方式,用户可以直接从 Internet 播放音频和视频,而不必先将文件下载到他们的设备上。

它建立在当时的现有标准之上,在操作上类似于 HTTP(因此很容易与现有的 HTTP 网络兼容),并且能够使用 SDP(会话描述协议,1998 年标准化)进行多媒体通信会话。

本质上,RTSP 是一种应用层协议,它与媒体服务器进行通信以建立会话并发送诸如“暂停”和“播放”之类的命令,而不是传输实际的流数据。传统上,大多数 RTSP 服务器还使用 RTP(实时传输协议)和 RTCP(实时控制协议)来传递其媒体流。

了解 Kaltura 的实时流媒体解决方案可以为您做什么。

REQUEST A DEMORTSP 立即被用于各种用途,例如现场演示、网络摄像头站点、在线教育和网络广播,随后被包括在 YouTube 和 Spotify 等仍在使用的平台、Skype 等通信应用程序和媒体播放器中WMP 和 VLC。

RTSP 和 RTMP 曾经是互联网音频和视频流的领先技术,但是由于这两种协议都需要专用服务器来进行最后一英里的内容交付,因此它们无法很好地扩展到大型广播。随着时间的推移,基于 HTTP 的渐进式下载技术和自适应比特率流解决方案开始超越旧的首选技术。原作者 Anup Rao 和 Rob Lanphier 以及其他人在 2016 年提出了 RTSP 2.0 版,其更新旨在缩短与媒体服务器的往返通信并解决网络地址转换 (NAT) 的一些问题。

如今,RTSP 最常被用作贡献协议,即一种对内容进行编码的方法,然后通过其他方法将内容流式传输给观众。 RTSP 仍然是 IP 摄像机的首选协议,它用于大多数监控、CCTV 和会议视频技术,所有这些都可以用作直播源。

RTSP 协议是如何工作的?

从广义上讲,协议是规定数据如何从一个系统传输到另一个系统的规则。例如,众所周知的超文本传输​​协议 (HTTP) 管理 Web 服务器和浏览器之间的通信,定义页面数据和超文本/链接如何通过 Web 发送。

如上所述,RTSP 在功能上在概念上类似于 HTTP,并且在最初开发时很容易与现有的 HTTP 网络兼容。

我们之前注意到,它的作者将 RTSP 描述为媒体服务器的“网络远程控制”。它旨在控制流而不需要本地下载。当视频流启动时,使用该协议的设备会向启动设置过程的媒体服务器发送 RTSP 请求。

RTSP 还支持多种控制请求操作(也称为“命令”),例如播放、暂停、设置等。初始请求还应通过“OPTIONS”命令向客户端报告可用的选项。从那里开始,用户可以根据允许的参数观看、提示或关闭流。 RTSP 与 TCP 保持端到端的连接,通过这种稳定的连接打开众所周知的数据插口,无需任何本地下载或缓存,即可实现高传输速度。

由于 RTSP 依赖于一个专用的流媒体服务器,并且依赖于 RTP 来传输实际媒体,因此该协议不支持内容加密或丢失数据包的重传。尽管 RTSP 在语法和操作上与 HTTP 相似,但它也存在差异和不兼容性,如果不添加额外的软件,就无法从 Web 浏览器以简单、直接的方式流式传输它。由于这些因素以及前面提到的扩展到大型广播的问题,它逐渐被更新的流媒体技术所取代。

在当今的互联网上,包含 RTSP 的视频流工作流很可能会使用媒体服务器来摄取通过 RTSP/RTP 传输的流(根据其指定为“贡献协议”或“靠前英里”技术),然后利用另一种方式交付以重新打包并发送要在各种设备上观看的内容。

RTSP 与 RTMP

由于这两种协议都是视频流世界的长期主力军,让我们来看看 RTSP 和 RTMP 如何相互叠加。

RTMP 或实时消息传递协议是一种在传输控制协议 (TCP) 之上运行的技术,最初是作为 Macromedia-Adobe 的专有协议开发的,用于音频、视频和数据的实时流传输。 RTMP 的优秀功能是视频播放器和服务器之间的持久 TCP 连接,它为观看者提供一致且可靠的流。

值得注意的是,尽管它最初是为通过 Adob​​e Flash Player 进行流式传输而设计的——但遗憾的是,截至 2021 年,Flash 已不复存在。但与 RTSP 一样,如今该协议并未广泛用于实际面向观众的流传输。当作为工作流程的一部分使用时,RTMP 需要 Flash Player 技术的问题不再是一个问题。

RTMP 同样是流式音频和视频难以实现的时代(1990 年代)的产物,解决方案必须克服硬件的实际限制。它启动了互联网流媒体的兴起,并因其可靠性和效率而成为名副其实的内容交付之王。

最终,Adobe 放松了控制,并在 2012 年发布了该协议的一个版本供公众使用,但到那时,文字已成定局:Flash 开始被视为潜在的安全风险,也开始被边缘化为通过自适应比特率流和 HTML5 播放器的交付方法。几年后的 2015 年,YouTube 放弃了 HTML5 的 Flash,RTMP 作为最后一英里的技术走到了最后。

就目前的用例而言,RTMP 被广泛用作现代直播平台的摄取协议,通常被转换为 HLS(HTTP Live Streaming)并传送到适用于浏览器和移动设备的 HTML 5 视频播放器。 RTMP 在靠前英里的主要优势在于它允许用户利用低成本或开源编码器来进行直播内容。

由于这两种协议都没有广泛用于最后一英里的流传输,因此不能说它们之间已经存在真正的竞争。到目前为止,它们有许多相似之处,最好从“正确工作的正确工具”的角度来看待。 RTMP 和 RTSP 都是控制媒体流的应用级协议,都是低延迟协议,能够通过稳定的连接实时或近乎实时地按需交付媒体。

每个协议都有优点和缺点,没有正确或错误的答案;您是否使用其中一种取决于如何最好地满足您的流媒体操作的需求以及您要使用的平台和硬件的需求。

RTSP 是一个开放标准,由当时 Adob​​e 的竞争对手开发。通常,RTSP 专为端点之间的通信和控制而设计,在需要更便宜、更简单的流式传输替代方案的情况下更受欢迎。它在某些方面得到了更好的发展,因为多年来它被工程师广泛使用,RTMP 被隔离为专有技术。然而,由于之前RTMP的主导地位,很多主播对它并不熟悉。

RTSP 是本地化流的不错选择,并且经常内置在 IoT 软件中以访问视频源。 RTSP 也是大多数 IP 摄像机的标准,这使得您在会议或监控系统中依赖流输入的部分或全部设备可能会使用该协议。

示例 RTSP 到 RTMP 摄取解决方案

如您所知,RTSP 仍然广泛用于 IP 摄像头,这些摄像头通常用于视频会议、公共流/网络摄像头以及安全、监控和闭路电视系统。它们也可能只是您可以使用的输入设备。

在 Kaltura,我们意识到支持 IP 的摄像机在您的直播中的明显实用性。由于您可能会发现自己处于输入设备的优秀选择运行 RTSP 协议但您需要摄取到更喜欢 RTMP 的平台的情况下,我们的知识库提供了至少一种编码解决方法。请记住它是一个潜在的工作流程!

此外,链接文章中列出的程序可能适用于其他协议,例如 RTP、RTMP、MPEG-TS 和 ICY。以下是有关如何将 RTSP 转换为 RTMP 以进行摄取的快速细分,以确保您可以无缝地使用 IP 摄像机设备(以及所有其他 RTSP!)作为流的输入。

我们建议的方法使用中间服务器从配置 RTSP 的设备接收数据,然后从那里转换为 RTMP 流,然后将其广播到您的最终面向观众的平台。随着数据到达您的最终交付系统,它可以广播成更适合在现代设备上观看的其他格式,例如 HLS Viewer、HDS Viewer 或 MPEG-DASH Viewer。因此请记住,IP 摄像机和其他物联网设备并非仅限于 RTSP 流媒体的死胡同。使用 RTSP 设备捕获流媒体内容时,有多种选择;如果您的分发目的地对它接受的协议有限制,您仍然可以广播到中间服务器,配置参数等等! …您面向观众的目的地正在通过 RTMP 进行摄取。

如果您需要有关我们的直播产品和技术解决方案的进一步指导,我们的知识中心还提供了一系列详细的文章,涵盖了使用 Kaltura 进行直播的概述、直播编码优秀实践以及在流媒体中使用 RTMP 端点。无论您的技术问题和要求是什么,我们的目标都是为您服务。

免责声明:本站内容(文字信息+图片素材)来源于互联网公开数据整理或转载,仅用于学习参考,如有侵权问题,请及时联系本站删除,我们将在5个工作日内处理。联系邮箱:chuangshanghai#qq.com(把#换成@)

我们已经准备好了,你呢?

我们与您携手共赢,为您的企业形象保驾护航!

在线客服
联系方式

热线电话

132-7207-3477

上班时间

周一到周五

二维码
线