欢迎诸位来阅读在下的博文~
在这里,在下会不定期发表一些浅薄的知识和经验,望诸位能与在下多多交流,共同努力!
江山如画,客心如若,欢迎到访,一展风采
文章目录
- 前期博客
- 参考书籍
- 一、PTMP简介
- 二、RTMP的交互流程
- 1.握手
- 2.建立连接
- 3.建立流
- 4.RTMP播放
- 三、RTMP相关名词解析
- 四、直播推流与拉流
- 直播推流
- 直播拉流
- 五、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个步骤:
- 握手,类似于TCP握手
- 建立连接,建立客户端和服务器之间的“网络连接”。
- 建立流,建立客户端和服务器之间的“网络流”。
- 播放/发送,传输音视频数据。
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字节)等字段。
未完。。。
望诸位不忘三连支持一下~