RTMP的工作原理
Posted LiveVideoStack_
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了RTMP的工作原理相关的知识,希望对你有一定的参考价值。
翻译:Alex
技术审校:章琦
本文来自OTTVerse,作者为Krishna Rao Vijayanagar。
▲扫描图中二维码了解音视频技术大会更多信息▲
Easy-Tech #028#
什么是RTMP?
RTMP(Real-Time Messaging Protocol,实时消息传输协议)是一种用于低延迟、实时音视频和数据传输的双向互联网通信协议,由Macromedia(后被Adobe收购)开发。RTMP的工作原理是:通过建立和维护RTMP客户端和RTMP服务端之间的通信路径来实现快速、可靠的数据传输。
RTMP最初用于Adobe Flash Player的媒体传输,但是众所周知,Flash在2020年12月已被弃用。这意味着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由Adobe推出,用于超级流行的Adobe Flash播放器中,数百万网站曾使用这款播放器向用户展示视频。在鼎盛时期,大约超过90~95%有视频内容的网站上都使用Adobe Flash播放器来播放视频。
Adobe对RTMP的定义如下:
RTMP (实时信息传输协议)用于在Adobe Flash平台技术(包括Adobe Flash播放器和 Adobe AIR)间实现音频、视频和数据的高性能传输。现在,作为一种开放规范,RTMP可用于创建实现与Adobe Flash播放器兼容的AMF、SWF、FLV和F4V等开放格式的音频、视频和数据传输的产品和技术。——Adobe
然而,随着Flash的弃用,RTMP不再用于向Adobe Flash播放器传输视频,同时还要面临与基于HTTP的视频传输协议MPEG-DASH和HLS的竞争。但是,RTMP仍然在向编码器传输视频的过程中发挥着重要作用,我们在下文将会讲到。
RTMP的工作原理
正如我们在上文中所了解到的,RTMP是一种基于TCP的、用于数据、音频和视频传输的双向通信协议。
RTMP的工作原理是:通过建立和维护RTMP客户端和RTMP服务端之间的通信路径来实现快速、可靠的数据传输。
与基于HTTP的传输协议HLS和DASH的操作相似,RTMP也是将多媒体流分割成切片:通常情况下,音频为64字节,视频为128字节。切片的大小可以由客户端和服务端之间协商获得。
传统观点认为切片尺寸不应太大,也不应太小。较大的切片在写入操作中引起延迟,而太小的切片则会增加CPU的负载。
图片来源: 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,之后握手完成,连接建立。
图片来源: 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规范: https://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf 。
第三步:推拉流
在RTMP握手和连接步骤后,RTMP客户端和RTMP服务器之间的连接已经建立,现在就可以传送数据了。为了实现数据的传输,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(来源:https://developers.facebook.com/blog/post/2019/04/16/live-video-uploads-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服务器。更多关于RTMFP的详细信息,请阅读:
https://www.adobe.com/in/products/adobe-media-server-extended/rtmfp-faq.html 。
RTMP中音频和视频的编解码器支持
在继续学习前,让我们一起来看下RTMP中的编解码器支持。头部文件说明了对于下列编解码器的支持:
-
音频:AAC、MP3
-
视频:H.264/AVC、FLV容器中的VP6
哪里支持RTMP?
一些商业和开源编码器以及流媒体引擎支持RTMP,无论是拉流,或生成RTMP 数据源(推流)。你可以使用:
-
OBS Studio, 免费的广播和直播软件,可以生成RTMP数据源
-
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推拉流。
我们下次再见,保重,请继续Streaming!
致谢:
本文已获得作者Krishna Rao Vijayanagar授权翻译和发布,特此感谢。
原文链接:
https://ottverse.com/rtmp-real-time-messaging-protocol-encoding-streaming/
延伸阅读:
开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系
以上是关于RTMP的工作原理的主要内容,如果未能解决你的问题,请参考以下文章