什么是RTMP协议?
RTMP协议是搭建直播常用协议之一,RTMP协议是专有的双向通信协议,用于通过 Internet 进行低延迟、实时音频、视频和数据流传输,由Macromedia开发,Adobe 随后收购了它。RTMP 的工作原理是在 RTMP Client 和 RTMP Server 之间建立和维护通信路径,以实现快速、可靠的数据传输。
RTMP 最初是为使用 Adobe 的 Flash 播放器播放流媒体而设计的,但众所周知,从 2020 年 12 月起,Flash 已被弃用。这是否意味着 RTMP 已死,尘埃落定?没有!
RTMP 仍然在现代视频流管道中发现了几个用例,尤其是在转码器的输入和输出中。这是由于 RTMP 的低延迟、实时流媒体特性。
大多数行业标准编码器(encoding.com、Bitmovin、Harmonic、AWS Elemental 等)都可以生成 RTMP 输出源。同样,Twitch、YouTube、Facebook Live 等流媒体服务以及 Dacast、Ant Media、Wowza 等其他直播平台也可以接收 RTMP 提要。
本文深入研究了 RTMP 协议,包括:
- RTMP的历史
- RTMP如何工作?
- 如何建立 RTMP 连接?
- RTMP 的替代品
- RTMP 的优点和缺点。
事不宜迟,让我们直接进入 RTMP 协议的历史。
RTMP 协议的历史
RTMP 由 Adobe 引入,用于其超级流行的 Adobe Flash Player,数百万网站使用该播放器向其用户显示视频。在其鼎盛时期,Adobe Flash Player 可能出现在 90 – 95% 的带有视频内容的网站上。
Adobe对 RTMP 的定义如下——
实时消息传输协议 (RTMP) 旨在实现 Adobe Flash Platform 技术(包括 Adobe Flash Player 和 Adobe AIR)之间音频、视频和数据的高性能传输。RTMP 现已作为开放规范提供,用于创建支持以与 Adobe Flash Player 兼容的开放 AMF、SWF、FLV 和 F4V 格式交付视频、音频和数据的产品和技术。
然而,随着 Flash 的弃用,RTMP 不再用于向视频播放器传输视频,并且正在见证来自 MPEG-DASH 和 HLS 等基于 HTTP 的视频传输协议的激烈竞争。但是,RTMP 仍然在与编码器之间的视频传输中发挥着重要作用,我们将在以后的部分中介绍这一点。
RTMP 如何工作?
正如我们在介绍中看到的,RTMP 是一种基于 TCP 的通信协议,用于数据、音频和视频的双向通信。
RTMP 的工作原理是在 RTMP Client 和 RTMP Server 之间建立和维护通信路径,以实现快速、可靠的数据传输。
类似于 HLS 和 DASH 等基于 HTTP 的传输协议的行为方式,RTMP 也将多媒体流分成通常为 64 字节的音频和 128 字节的视频片段。片段的大小可以在客户端和服务器之间协商。
传统观点认为尺寸既不能太小也不能太大。大片段大小会导致写入操作延迟,非常小的片段会增加 CPU 的负载。
通过将视频流分割成切片,RTMP 可以将来自不同视频流的切片交织在一起,并在单个连接上传输,这种方法被称为 “多路复用”,与视频直播中的统计多路复用类似。不过在实际中,包含几个切片的数据包被交织在一起后,使得 RTMP 传输更加高效,并允许 RTMP 创建多个虚拟、可寻址的视频传输通道。在解码端,这些交织的数据包可以被解复用,从而获取到最初的音频和视频数据。
RTMP 连接设置:握手、连接、推拉流
现在,让我们一起来了解 RTMP 连接是如何建立的,从而帮助我们更好地理解 RTMP 协议的工作原理。RTMP 建立连接可分为三步:握手、连接和推拉流。
让我们分别看下这三个步骤。
第一步:握手
RTMP 中的握手过程相对简单,在建立 TCP 连接后进行。在此握手过程中,每一方(客户端和服务端)发送三个数据包,分别为 C0、C1、C2 (客户端)和 S0、S1 、S2(服务端)。
下面是对 RTMP 握手过程的解释:
客户端向服务器发送 C0 数据包,数据包中包含客户端请求的 RTMP 版本。
然后客户端在没有等到服务器表示已接收到 C0 的情况下,发送包含了 1536 字节随机数据的 C1。
此时,服务器必须等到它收到 C0 才能响应 S0 和 S1(可选)。在这个阶段,服务器知道客户端所请求的 RTMP 版本。服务器响应 S0 和 S1—— 它们本质上是 C0 和 C1 的副本。
然后客户端和服务器交换 C2 和 S2,之后握手完成,连接建立。
第二步:连接
连接步骤发生在 RTMP 客户端和 RTMP 服务端之间的握手之后。在连接过程中,客户端和服务器使用 AMF 编码交换编码过的信息。
AMF 代表 Action Message Format,用于在 Adobe Flash 客户端和 Flash 媒体服务器之间发送信息。或者,程序员可以使用 AFM 序列化 ActionScript 和 XML 的对象图。AMF 在 RTMP 流传输中用于客户端和服务器之间的通信,表明信息类型和内容。更多关于 AMF 的信息,可以在这里阅读:https://en.wikipedia.org/wiki/Action_Message_Format 。
下面的示例显示了由客户端向 RTMP 服务器发出的信息。其中使用了连接 URL、音频编解码器、视频编解码器和所使用的 AMF 版本号。在此示例中,AMF 的版本为 3.0。
(Invoke) "connect"
(Transaction ID) 1.0
(Object1) { app: "sample", flashVer: "MAC 10,2,153,2", swfUrl: null,
tcUrl: "rtmpt://127.0.0.1/sample ", fpad: false,
capabilities: 9947.75 , audioCodecs: 3191, videoCodecs: 252,
videoFunction: 1 , pageUrl: null, objectEncoding: 3.0 }
RTMP 服务器将用这样的消息响应它:
(Invoke) "_result"
(transaction ID) 1.0
(Object1) { fmsVer: "FMS/3,5,5,2004", capabilities: 31.0, mode: 1.0 }
(Object2) { level: "status", code: "NetConnection.Connect.Success",
description: "Connection succeeded",
data: (array) { version: "3,5,5,2004" },
clientId: 1728724019, objectEncoding: 3.0 }
在此步骤中,客户端和服务器还交换“Set Peer Bandwidth”和“Window Acknowledgement Size”协议消息。成功执行后,这些消息表示连接已建立,现在服务器可以传输视频数据。音视频编解码器等参数的取值请参考RTMP规范。
第三步:推拉流
- createStream
- play
- play2
- deleteStream
- closeStream
- receiveAudio
- receiveVideo
- publish
- seek
- pause
在这些命令的帮助下,才有可能使用 RTMP 协议传输视频。
现在你对 RTMP 连接的工作原理已经有了基本的理解,接下来让我们了解一些常用的 RTMP 变体。
RTMP 的变体:RTMPS、RTMPT、RTMFP、RTMPE、RTMP Proper
在这一部分,我们将简单介绍用于特定目的的 RTMP 变体,让我们从 RTMPS 开始。
RTMPS: RTMPS 只是基于 TLS/SSL 连接的 RTMP。与 RTMPE 相比,设置和使用 RTMPS 要复杂一些,但是能够确保一定程度的安全性。如果你计划使用 RTMP 将视频传输到 Facebook Live,你需要使用 RTMPS。
RTMPE: RTMPE 使用了包含 Diffie–Hellman key exchange 和 HMACSHA256 的行业标准加密。它生成了一对 RC4 密钥,其中:
第一个密钥用于加密从服务器向客户端发出的媒体数据。
第二个密钥用于加密向服务器发送的数据。
RTMP Proper: 是指使用 1935 端口、基于 TCP 的 RTMP 的别名。
RTMPT: RTMPT 建立在 HTTP 协议之上,是通过 HTTP 封装后的 RTMP 协议。它允许 RTMP 信息穿过防火墙,封装的信息可以是 RTMP Proper、RTMPS 或 RTMPE 数据包。
RTMFP: RTMPF 基于 UDP 协议(而非 TCP),而且没有使用 RTMP Chunk Stream。RTMFP 设计用于直接在 P2P 之间进行低延迟、实时的音频和视频通信,而无需通过 RTMP 服务器。
RTMP 中音频和视频的编解码器支持
在继续学习前,让我们一起来看下 RTMP 中的编解码器支持。头部文件说明了对于下列编解码器的支持:
音频:AAC、MP3
视频:H.264/AVC、FLV 容器中的 VP6
哪里支持 RTMP?
一些商业和开源编码器以及流媒体引擎支持 RTMP,无论是拉流,或生成 RTMP 数据源(推流)。你可以使用:
OBS Studio, 免费的广播和直播软件,可以生成 RTMP 数据源:
- OBS Studio,
- FFmpeg
- Dacast.com
- Bitmovin.com
- Ant Media Server
- Wowza
等其他更多的 RTMP 推拉流的解决方案。
RTMP 推流替代方案
由于 Adobe 结束了对于 Flash 的支持,RTMP 现在所面临的是不太确定的未来。对于推流而言,你还可以考虑其他替代方案。
HLS 是可以替代 RTMP 的流行方案。HLS 是流媒体行业中的公认标准,从编码器、打包器、加密(DRM)、CDN 到设备上的播放,它获得了来自视频生态的广泛支持。
另一个选择是 MPEG-DASH,它也是基于 HTTP 的视频传输协议。和 HLS 一样,DASH 也获得了广泛支持,也可以看作 RTMP 的替代方案。
基于 HTTP 的协议会存在一个问题,那就是它们会增加系统时延。通常情况下,在 HLS 和 DASH 中,必须先生成一定数量的视频切片,才能创建 DASH 清单或者 HLS 播放列表。没有播放列表或者清单,播放器便无法理解生成的视频流。等待播放列表或者清单的过程增加了时延,通常情况下会对系统造成 45 秒~1 分钟的延迟。
不过,人们正在开发低延迟的 DASH 和 HLS 协议,它们能够减少基于 HTTP 的流媒体时延,并能够缓解基于 HTTP 的流媒体协议所带来的问题。
结语
我希望这篇关于 RTMP 的介绍性文章能对你有所帮助,在未来的文章中,我们将研究 RTSP、RTMP 和 RTSP 之间的区别,以及如何使用 OBS Studio 等流行工具来实现 RTMP 推拉流。
作者:Krishna Rao Vijayanagar博士,OTTVerse 的创始人
本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/7519.html