流媒体之RTMP协议(其四)

欢迎诸位来阅读在下的博文~
在这里，在下会不定期发表一些浅薄的知识和经验，望诸位能与在下多多交流，共同努力！

江山如画，客心如若，欢迎到访，一展风采

前期博客

流媒体与直播的基础理论（其一）
流媒体协议RTSP（其二）
流媒体协议HLS（其三)

参考书籍

《FFmpeg入门详解——流媒体直播原理及应用》——梅会东

一、PTMP简介

RTMP，实时消息传输协议基于TCP，是一个协议簇，包括RTMP基本协议及RTMPT/RTPS/PTMPE等多种变种。RTMP是一种用于进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/Red5等。RTMP与HTTP一样，都属于TCP/IP四层模型的应用层。

• 采用tcp协议，避免了多媒体数据在广域网传输过程中的丢包对质量造成影响。
• 采用FLV封装格式，支持H.264视频编码方式，可以在很低的码率下显示质量还不错的画面。
• 基于udp的RTMFP是其一个变种，能提高实时性问题。
• 一个重大局限是，该协议的播放依赖于Flash Player，由于Flash Player存在安全漏洞问题，现在不受欢迎了。
• 目前常用来进行推流。

变种解析：

• RTMP工作在TCP之上，默认的端口号是1935。
• RTMPE在RTMP的基础上增加了加密功能。
• RTMPT封装在HTTP请求之上，可穿透防火墙。
• RTMPS类似于RTMPT，增加了TLS/SSL的安全功能。

二、RTMP的交互流程

RTMP Client与RTMP Server的交互流程分为4个步骤：

1. 握手，类似于TCP握手
2. 建立连接，建立客户端和服务器之间的“网络连接”。
3. 建立流，建立客户端和服务器之间的“网络流”。
4. 播放/发送，传输音视频数据。

1.握手

RTMP握手过程中，服务器和客户端都需要发送大小固定的3个数据块。其中，客户端要发送C0,C1,C2三个块；服务器要发送S0,S1,S2三个块。
三个块的发送要符合以下规则：
（1）客户端要收到S之后，才能发送C2.
（2）客户端要收到S2之后才能发送其它信息。
（3）服务器要等到收到C0之后发送S1.
（4）服务器必须等到收到C1之后才能发送S2.
（5）服务器必须收到C2之后才能发送其它信息。
常见的一种满足规则的发送方式如下：

这种通信方式可以使得通信次数最小。

2.建立连接

• 客户端发送“connect”，请求与一个服务应用实例建立连接。
• 服务器接收到连接命令后，将确认窗口大小协议发送到客户端，同时连接到connect命令中提到的应用程序。
• 服务器将设置带宽协议消息发送到客户端。
• 客户端处理设置带宽协议消息后，将确认窗口大小协议消息发送到服务器端。
• 服务器将用户控制消息中的“流开始”消息发送到客户端。
• 服务器端发送命令消息中的“结果”（_result），通知客户端连接状态。

3.建立流

（1）客户端将命令消息中的“创建流”命令发送到服务器端。
（2）服务器端接收到“创建流”命令后，发送命令消息中的“结果”，通知客户端。

4.RTMP播放

RTMP建立流一般如下：
（1）客户端将命令消息中的“播放”命令发送到服务器端。
（2）接收到播放命令后，服务器端发送设置块大小协议消息。
（3）服务器端发送用户控制消息中的Stream Begin，告知客户端流ID。
（4）播放命令成功，服务器端发送命令消息中的“响应状态”，告知客户端“播放”命令执行成功。
（5）在此之后服务器端发送客户端要播放的音视频数据。

三、RTMP相关名词解析

（1）Packet，即数据包，一个数据包由一个固定头和有效载荷构成。
（2）Payload，即有效载荷，是存储在一个数据包中的数据，例如声频采样或者压缩的视频数据。
（3）Port，即端口，传输协议用来指定端口号。
（4）Transport Address，即传输地址，标识传输层端点的网地址和端口的组合，例如一个IP地址和一个TCP端口。
（5）Message Stream，即消息流，是指通信中消息流通的一个逻辑通道。
（6）Message Stream ID，即消息流ID，每条消息流有一个关联的ID，使用ID标识流通道中的消息流。
（7）Chunk，即块，是指消息在发送之前被拆开分为很多小的块，以确保端到端交付所有消息有序。
（8）Chunk Stream，即块流，指通信中允许块流向一个特定方向的逻辑通道。块流可从客户端流向服务器端，也可以从服务器端流向客户端。
（9）Chunk ID，即块流ID，每个块有一个关联的ID，使用ID标识流通道中的块流。
（10）Metadata，即元数据，关于数据的描述，例如一部电影的Metadata包括电影的标题、持续时间、创建时间等。

四、直播推流与拉流

直播推流，指的是把采集阶段封包好的内容传输到服务器的过程。拉流则相反，从服务器把数据拉回到客户端观看的过程。

• 推流常用的协议是RTMP，因为RTMP的延时很低。
• RTMP协议将推流端的数据发送到服务器后，再通过一定的QoS算法将音视频流数据推送到网络端，最后进行CDN分发。

直播推流

以下是参考的步骤：
（1）经过采集设备得到原始的采集数据，包括视频数据（YUV）和声频数据（PCM）。
（2）使用硬编码或软编码（FFmpeg）来编码压缩音视频数据。
（3）分别得到已编码的H.264视频数据和AAC声频数据。
（4）采取不同的封装格式，如 FLV、TS、MPEG-TS等。
（5）HLS分段生成策略及m3u8索引文件（在使用HLS协议时，附加的一步）。
（6）通过流上传到服务器。
（7）服务器进行相关的协议的分发。
优化方案：

• QoS策略。推流端会根据当前上行网络情况控制音视频数据发包和编码，在网络较差的情况下，音视频数据发送不出去，会造成数据滞留在本地，此时会停掉编码器，防止发送数据进一步滞留，同时会根据网络情况选择合适的策略控制音视频的发送。例如在网络很差的情况下，推流端会优先发送声频数据，保证用户能听到声音，并在一定间隔内发送关键帧数据，保证用户在一定时间间隔之后能看到一些画面的变化。
• 合理的关键帧配置。合理控制关键帧发送间隔（建议2s或者1s发送一个），这样可以减少后端处理过程，为将后端的缓冲区设置得更小创造条件。

整个推流过程如下：

直播拉流

一般来讲，直播拉流的步骤如下：
（1）根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据。
（2）解析二进制数据，从中找到相关流信息。
（3）根据不同的封装格式（如FLV、TS）解复用（demux）。
（4）分别得到已编码的H.264视频数据和AAC声频数据。
（5）使用硬解码（对应系统的API）或软解码（FFmpeg）来解压音视频数据。
（6）经过解码后得到原始的视频数据（YUV），和声频数据（PCM）。
（7）因为声频和视频解码是分开的，所以需要把它同步起来，否则会出现音视频不同步的问题。
（8）最后把同步的声频数据发送到耳机或外放，将视频数据发送到屏幕上。

首频优化：

• 通过预设解码器类型，省去探测文件类型的时间。
• 缩小视频数据探测范围，同时也意味着减少了需要下载的数据量，特别是在网络不好时，减少下载的数据量能为启动播放节省大量短时间，当检测到I帧数据后就立即返回并进入解码环节。
  

五、RTMP消息

RTMP消息在传输过程中，会被划分成块，这样可以避免内容较大的消息阻塞后面内容较小，但是优先级更高的消息，如声频或者控制数据。
RTMP消息包含两部分，及消息头（Message Header）和 消息负载（Message Payload）。

• 消息头
  消息类型（1字节）、负载长度（3字节）、时间戳（4字节）、流ID（3字节）等字段。

未完。。。

望诸位不忘三连支持一下~