RTMP直播搭建必看,RTMP协议是如何工作的

什么是RTMP协议?

RTMP协议是搭建直播常用协议之一,RTMP协议是专有的双向通信协议,用于通过 Internet 进行低延迟、实时音频、视频和数据流传输,由Macromedia开发,Adobe 随后收购了它。RTMP 的工作原理是在 RTMP Client 和 RTMP Server 之间建立和维护通信路径,以实现快速、可靠的数据传输。

RTMP 最初是为使用 Adob​​e 的 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 由 Adob​​e 引入,用于其超级流行的 Adob​​e Flash Player,数百万网站使用该播放器向其用户显示视频。在其鼎盛时期,Adobe Flash Player 可能出现在 90 – 95% 的带有视频内容的网站上。

Adobe对 RTMP 的定义如下——

实时消息传输协议 (RTMP) 旨在实现 Adob​​e Flash Platform 技术(包括 Adob​​e Flash Player 和 Adob​​e AIR)之间音频、视频和数据的高性能传输。RTMP 现已作为开放规范提供,用于创建支持以与 Adob​​e 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协议是如何工作的
图片来源: Wikipedia

通过将视频流分割成切片,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协议是如何工作的
图片来源: Wikipedia

第二步:连接

连接步骤发生在 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 数据源:

  1. OBS Studio,
  2. FFmpeg
  3. Dacast.com
  4. Bitmovin.com
  5. Ant Media Server
  6. 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

(0)

相关推荐

发表回复

登录后才能评论