深入理解rtmp(四)之协议实现分析

本文涉及的产品
图片翻译,图片翻译 100张
云解析 DNS,旗舰版 1个月
文本翻译,文本翻译 100万字符
简介: 接下来要实现connect,createStream,play,..,为了效率和篇幅,我们直接分析srs-librtmp的实现.srs-librtmp是从srs作者为srs服务实现的客户端库(The client library srs-librtmp of SRS),其实不止客户端,也实现了一个简单的server功能.

image.png


前面的三篇文章已经从开发环境搭建实现到了握手协议:


image.png


接下来要实现connect,createStream,play,..,为了效率和篇幅,我们直接分析srs-librtmp的实现.srs-librtmp是从srs作者为srs服务实现的客户端库(The client library srs-librtmp of SRS),其实不止客户端,也实现了一个简单的server功能.


为了方便我们后续的分析,先了解两个概念:


1.准备知识


1.1大小端


举个🌰说明:


假设某段内存中存放以下这样的数据 低地址 高地址


------------------------------------>
+--------+--------+--------+--------+
|   11   |   66   |    85  |   27   |
+--------+--------+--------+--------+


  • 大端模式下值为 0x11668527,数据高位存放在低地址中,数据低位存放高地址中
  • 小端模式下值为 0x27856611,数据高位存放在高地址中,数据低位存放低地址中 所以在对数据处理的时候需要注意当前是在什么模式下,一般32位环境是小端模式,64位环境是大端模式.RTMP都是大端模式,所以发送数据,包头,交互消息都要填写大端模式的,但是只有streamID小端模式


1.2AMF


Action Message Format: A compact binary format that is used to serialize ActionScript object graphs. 有两个版本:AMF0和AMF3.AMF3用作Flash Playe 9的ActionScript 3.0的默认序列化格式,而AMF0则用作旧版的ActionScript 1.0和2.0的序列化格式。 在网络传输数据方面,AMF3比AMF0更有效率。AMF3能将int和uint对象作为整数(integer)传输,并且能序列化ActionScript 3.0才支持的数据类型, 比如ByteArray,XML和Iexternalizable。


对应类型有:


类型 枚举值 说明
Number 0×00 double类型
Boolean 0×01
String 0×02 string类型
Object 0×03 object类型
MovieClip 0×04 Not available in Remoting
Null 0×05 null类型,空
Undefined 0×06
Reference 0×07
MixedArray 0×08
EndOfObject 0×09 See Object ,表示object结束
Array 0x0a
Date 0x0b
LongString 0x0c
Unsupported 0x0d
Recordset 0x0e Remoting, server-to-client only
XML 0x0f
TypedObject (Class instance) 0×10
AMF3 data 0×11 Sent by Flash player 9+


rtmp协议中数据都是大端的,所以在放数据前都要将数据转成大端的形式。


1.2.1 number类型


其实就是double,占8bytes。 比如:00 00 00 00 00 00 00 00,第一个byte为amf类型,其后8bytes为double值0.0。


image.png


1.2.2 boolean


就是布尔类型,占用1byte 比如:01 00,第一个byte为amf类型,其后1byte是值,false。


1.2.3 string


就是字符类型,一个byte的amf类型,两个bytes的字符长度,和N个bytes的数据。比如:02 00 02 33 22,第一个byte为amf类型,其后两个bytes为长度,注意这里的00 02是大端模式,33 22是字符数据。


image.png


1.2.4 null


是空,只有一个byte,0x05。


1.2.5 object类型


object要复杂点,第一个byte是03表示object,其后跟的是N个(key+value)。最后以00 00 09表示object结束。


image.png


  1. key是一个字符串组成:2bytes的长度,N bytes的数据,就是表示value的作用,相当于value的名字。
  2. value可以使amf任意一种类型,包括object。格式和单独的amf type一样,如果是object的话,相当于在里面再嵌套一个object。
  3. level(key)后面的status就是value,此value是string类型,所以格式是上面提到的string类型(0x02)。


image.png


1.2.6 ECMA_ARRAY(0x08)


实际上和object差不多,只是在0x08类型后面多了4个bytes的记录总共多少items的东西,目测全部填00也可以,也是以00 00 09结束。


0x11类型是amf3的类型,amf3实际上外层是封了一层amf0,为了与amf0兼容


1.3 rtmp url 说明


下面四种都是合法的rtmp url:


  • url_schema_normal: rtmp://vhost:port/app/stream, the vhost put in host field, using DNS to resolve the server ip.
  • url_schema_via : rtmp://ip:port/vhost/app/stream, VIA(vhost in app), the vhost put in app field.
  • url_schema_vis : rtmp://ip:port/app/stream?vhost=xxx, VIS(vhost in stream), the vhost put in query string, keyword use vhost=xxx.
  • url_schema_vis2 : rtmp://ip:port/app/stream?domain=xxx, keyword use domain=xxx.


在进行握手前,要对rtmp url进行解析,解析出host, vhost,app, stream,param等字段.


我们之前深入理解rtmp(三)之手把手实现握手协议介绍到,握手是发送一定"格式"的固定字节,我们接下来的connect,createStream以及音视频数据的内容也都是要有"格式"的,这个"格式"我们在RTMP里面是以"消息"出现的.


2.RTMP消息


我们先看一下rtmp消息格式:


0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Message Type |               Payload length                   |
 |   (1 byte)   |                   (3 bytes)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Timestamp                            |
 |                          (4 bytes)                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Stream ID            |
 |                          (3 bytes)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Message Header


其中:


  • 1字节消息类型
  • 3字节负载消息长度
  • 4字节时间戳
  • 3字节Stream ID,区分消息流


Message Header第一个字节Message Type(消息类型)很重要,它代表了这个消息是什么类型,当写程序的时候需要根据不同的消息,做不同的处理.我们接下来先了解下RTMP有哪些消息类型.


2.1 RTMP消息分类


消息类型Message Type下面都简写为MT


2.1.1 协议控制消息


协议控制消息是用来与对端协调控制的


MT的范围1~7:


  • 1~2 用于chunk协议
  • 3~6 用于rtmp协议本身,协议控制消息必须要求


Message Stream ID=0 和 Chunk Stream ID=2


  • MT=1, Set Chunk Size 设置块的大小,通知对端用使用新的块大小,共4 bytes。默认大小是128字节
  • MT=2, Abort Message 取消消息,用于通知正在等待接收块以完成消息的对等端,丢弃一个块流中已经接收的部分并且取消对该消息的处理,共4 bytes。
  • MT=3, Acknowledgement 确认消息,客户端或服务端在接收到数量与窗口大小相等的字节后发送确认消息到对方。窗口大小是在没有接收到接收者发送的确认消息之前发送的字节数的最大值。服务端在建立连接之后发送窗口大小。本消息指定序列号。序列号,是到当前时间为止已经接收到的字节数。共4 bytes。
  • MT=4, User Control Message 用户控制消息,客户端或服务端发送本消息通知对方用户的控制事件。本消息承载事件类型和事件数据。消息数据的头两个字节用于标识事件类型。事件类型之后是事件数据。事件数据字段是可变长的。
  • MT=5, Window Acknowledgement Size 确认窗口大小,客户端或服务端发送本消息来通知对方发送确认消息的窗口大小,共4 bytes.
  • MT=6, Set Peer Bandwidth 设置对等端带宽,客户端或服务端发送本消息更新对等端的输出带宽。发送者可以在限制类型字段(1 bytes)把消息标记为硬(0),软(1),或者动态(2)。如果是硬限制对等端必须按提供的带宽发送数据。如果是软限制,对等端可以灵活决定带宽,发送端可以限制带宽?。如果是动态限制,带宽既可以是硬限制也可以是软限制。


2.1.2 音频数据消息


  • MT=8, Audio message, 客户端或服务端发送本消息用于发送音频数据。消息类型 8 ,保留为音频消息


2.1.3 视频数据消息


  • MT=9, Video message, 客户端或服务端使用本消息向对方发送视频数据。消息类型值 9 ,保留为视频消息。


2.1.4 元数据消息


  • MT=15或18, Data message, 客户端或服务端通过本消息向对方发送元数据和用户数据。元数据包括数据的创建时间、时长、主题等细节。消息类型为 18 的用 AMF0 编码,消息类型为 15 的用AMF3 编码。


2.1.5 共享对象消息


  • MT=16或19, Shared object message, 共享对象是跨多个客户端,实例同步的 FLASH 对象(名值对的集合)。


2.1.6 命令消息


  • MT=17或20, Command message, 命令消息都是用AMF编码的,AMF有两种,为AMF0和AMF3。命令消息有命令名,传输ID,和命名对象组成。而命名对象是由一系列参数组成的。


命令消息的类型有:


2.1.6.1 NetConnection Commands(连接层的命令)


代表服务端和客户端之间连接的更高层的对象。包含4个命令类型。


  1. connect:该命令是client先发送给server,意思是我要连接,能建立连接吗?server返回含“_result”或者“_error”命令名, 返回“_result”,表示server能提供服务,client可以进行下一步。“_error”,很明显server端不能提供服务。
  2. call:NetConnection 对象的调用方法在接收端运行远程过程调用。远程方法的名作为调用命令的参数。
  3. close:不知道为何协议里没写这个命令的内容,我猜应该是close connect。
  4. createStream:客户端发送本命令到服务端创建一个消息通讯的逻辑通道。音频,视频和元数据的发布是由创建流命令建立的流通道承载的。


RTMP握手之后先发送一个connect 命令消息,命令里面包含什么东西,协议中没有具体规定,实际通信中要指定一些编解码的信息,并以AMF格式发送, 下面是用wireshake抓取connect命令需要包含的参数信息:


image.png


这些信息协议中并没有特别详细说明, 在librtmp,srs-librtmp这些源码中,以及用wireshark 抓包的时候可以看到。


服务器返回的是一个_result命令类型消息,这个消息的payload length一般不会大于128字节,但是在最新的nginx-rtmp中返回的消息长度会大于128字节。


消息的transactionID是用来标识command类型的消息的,服务器返回的_result消息可以通过 transactionID来区分是对哪个命令的回应,connect 命令发完之后还要发送其他命令消息,要保证他们的transactionID不相同。


发送完connect命令之后一般会发一个 set chunk size消息来设置chunk size 的大小,也可以不发。


Window Acknowledgement Size 是设置接收端消息窗口大小,一般是2500000字节,即告诉对端在收到设置的窗口大小长度的数据之后要返回一个ACK消息。在实际做推流的时候推流端要接收很少的服务器数据,远远到达不了窗口大小,所以这个消息可以不发。而对于服务器返回的ACK消息一般也不做处理,默认服务器都已经收到了所有消息了。


之后要等待服务器对于connect消息的回应的,一般是把服务器返回的chunk都读完,组包成完整的RTMP消息,没有错误就可以进行下一步了。


connect消息结构如下:


字段 类型 说明
CommandName(命令名字) String 命令的名字,如”connect”
TransactionID(事务ID) Number 恒为1
CommandObject(命令包含的参数对象) Object 键值对集合表示的命令参数
OptionalUserArguments(额外的用户参数) Object 用户自定义的额外信息


call消息结构如下:


字段 类型 说明
ProcedureName(进程名) String 要调用的进程名称
TransactionID Number 如果想要对端响应的话置为非0值,否则置为0
CommandObject Object 命令参数
OptionalArguents Object 用户自定义参数

call消息中的TransactionID不为0的话,对端需要对该命令做出响应,响应的消息结构如下:

字段 类型 说明
CommandName(命令名) String 命令的名称
TransactionID Number 上面接收到的命令消息中的TransactionID
CommandObject Object 命令参数
OptionalArguents Object 用户自定义参数


创建完RTMP连接之后就可以创建RTMP流,客户端要想服务器发送一个releaseStream命令消息,之后是FCPublish命令消息,在之后是createStream命令消息。当发送完createStream消息之后,解析服务器返回的消息会得到一个stream ID。这个ID也就是以后和服务器通信的 message stream ID, 一般返回的是1,不固定。


image.png


createStream消息结构如下:


字段 类型 说明
CommandName(命令名) String “createStream”
TransactionID Number 上面接收到的命令消息中的TransactionID
CommandObject Object 命令参数
OptionalArguents Object 用户自定义参数


NetConnection 本身是默认的流通道,具有流ID 0。协议和一少部分命令消息,包括创建流,就使用默认的通讯通道。


2.1.6.2 NetStream Commands(流连接上的命令)


Netstream建立在NetConnection之上,通过NetConnection的createStream命令创建,用于传输具体的音频、视频等信息。 在传输层协议之上只能连接一个NetConnection,但一个NetConnection可以建立多个NetStream来建立不同的流通道传输数据。 以下会列出一些常用的NetStream Commands,服务端收到命令后会通过onStatus的命令来响应客户端,表示当前NetStream的状态。 onStatus命令的消息结构如下:


字段 类型 说明
CommandName(命令名) String “onStatus”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
InfoObject Object AMF类型的Object,至少包含以下三个属性:1、“level”,String类型,可以为“warning”、”status”、”error”中的一种;2、”code”,String类型,代表具体状态的关键字,比如”NetStream.Play.Start”表示开始播流;3、”description”,String类型,代表对当前状态的描述,提供对当前状态可读性更好的解释,除了这三种必要信息,用户还可以自己增加自定义的键值对


NetStream Commands1:play(播放)


+-------------+                                     +----------+    
         | Play Client |                  |                  |  Server  |
         +-------------+                  |                  +----------+
                |          |Handshaking and Application|          |
                |          |         connect done      |          |
                |                         |                       |
       ---+---- |---------Command Message(createStream) --------->|
       Create   |                                                 |
       Stream   |                                                 |
       ---+---- |<-------------- Command Message -----------------|
                |       (_result- createStream response)          |
                |                                                 |
       ---+---- |------------ Command Message (play) ------------>|
         play   |                                                 |
          |     |<---------------- SetChunkSize ------------------|
          |     |                                                 |
          |     |<----- User Control (StreamIsRecorded) ----------|
          |     |                                                 |
          |     |<-------- UserControl (StreamBegin) -------------|
          |     |                                                 |
          |     |<---- Command Message(onStatus-play reset) ------|
          |     |                                                 |
          |     |<---- Command Message(onStatus-play start) ------|
          |     |                                                 |
          |     |------------------ Audio Message---------------->|
          |     |                                                 |
          |     |------------------ Video Message---------------->|
          |     |                                                 |
                                          |
                                          |
                 Keep receiving audio and video stream till finishes


  1. 客户端从服务端接收到流创建成功消息,发送播放命令到服务端。
  2. 接收到播放命令后,服务端发送协议消息设置块大小。
  3. 服务端发送另一个协议消息(用户控制消息),并且在消息中指定事件” streamisrecorded” 和流 ID 。消息承载的头 2 个字,为事件类型,后4 个字节为流 ID 。
  4. 服务端发送事件” streambegin” 的协议消息(用户控制),告知客户端流 ID 。
  5. 服务端发送响应状态命令消息NetStream.Play.Start&NetStream.Play.reset , 如果客户端发送的播放命令成功的话。只有当客户端发送的播放命令设置了 reset命令的条件下,服务端才发送NetStream.Play.reset消息。如果要发送的流 没有找的话,服务端发送NetStream.Play.StreamNotFound消息。在此之后服务端发送客户端要播放的音频和视频数据。


play命令的结构如下:


字段 类型 说明
CommandName(命令名) String “play”
TransactionID Number 恒为0
CommandObject NULL 不需要此字段,设为空
StreamName String 要播放的流的名称
开始位置 Number 可选参数,表示从何时开始播流,以秒为单位。默认为-2,代表选取对应该流名称的直播流,即当前正在推送的流开始播放,如果对应该名称的直播流不存在,就选取该名称的流的录播版本,如果这也没有,当前播流端要等待直到对端开始该名称的流的直播。如果传值-1,那么只会选取直播流进行播放,即使有录播流也不会播放;如果传值或者正数,就代表从该流的该时间点开始播放,如果流不存在的话就会自动播放播放列表中的下一个流
周期 Number 可选参数,表示回退的最小间隔单位,以秒为单位计数。默认值为-1,代表直到直播流不再可用或者录播流停止后才能回退播放;如果传值为0,代表从当前帧开始播放
重置 Boolean 可选参数,true代表清除之前的流,重新开始一路播放,false代表保留原来的流,向本地的播放列表中再添加一条播放流


NetStream Commands2:play2(播放)


和播放命令不同,play2命令可以切换到不同的码率,而不用改变已经播放的内容的时间线。 服务端对播放 2 命令可以请求的多个码率维护多个文件。


字段 类型 说明
CommandName(命令名) String “play2”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
parameters Object AMF编码的Flash对象,包括了一些用于描述flash.net.NetstreamPlayOptions ActionScript obejct的参数


NetStream Commands3:deleteStream(删除流)


当 NetStream 对象销毁的时候发送删除流命令。


字段 类型 说明
CommandName(命令名) String “deleteStream”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
StreamID(流ID) Number 本地已删除,不再需要服务器传输的流的ID


NetStream Commands4:closeStream

NetStream Commands5:receiveAudio(接收音频)

NetStream 对象发送接收音频消息通知服务端发送还是不发送音频到客户端。


字段 类型 说明
CommandName(命令名) String “receiveAudio”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
BoolFlag Boolean true表示发送音频,如果该值为false,服务器端不做响应,如果为true的话,服务器端就会准备接受音频数据,会向客户端回复NetStream.Seek.Notify和NetStream.Play.Start的Onstatus命令告知客户端当前流的状态


NetStream Commands6:receiveVideo(接收视频)

NetStream 对象发送 receiveVideo 消息通知服务端是否发送视频到客户端。


字段 类型 说明
CommandName(命令名) String “receiveVideo”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
BoolFlag Boolean true表示发送视频,如果该值为false,服务器端不做响应,如果为true的话,服务器端就会准备接受视频数据,会向客户端回复NetStream.Seek.Notify和NetStream.Play.Start的Onstatus命令告知客户端当前流的状态


NetStream Commands7:publish(推送数据)


推流准备工作的最后一步是 Publish Stream,即向服务器发一个publish命令消息,这个命令的message stream ID 就是上面 create stream 之后服务器返回的stream ID,发完这个命令一般不用等待服务器返回的回应,直接发送音视频类型的RTMP数据包即可。有些rtmp库还会发setMetaData消息,这个消息可以发也可以不发,里面包含了一些音视频meta data的信息,如视频的分辨率等等。


+-------------+                                     +----------+    
         |  Client     |                  |                  |  Server  |
         +-------------+                  |                  +----------+
                |          |      Handshaking  Done    |          |
                |                         |                       |
                |                         |                       |
       ---+---- |---------   Command Message(connect)   --------->|
          |     |                                                 |
       Connect  |<---------- Window Acknowledge Size -------------|
          |     |                                                 |
          |     |<------------- Set Peer BandWidth ---------------|
          |     |                                                 |
          |     |----------- Window Acknowledge Size ------------>|
          |     |                                                 |
          |     |<--------- User Control(StreamBegin) ------------|
          |     |                                                 |
       ---+---- |--------------- Command Message ---------------->|
                |          (_result- connect response)            |
                |                                                 |
       ---+---- |---------Command Message(createStream) --------->|
       Create   |                                                 |
       Stream   |                                                 |
       ---+---- |<-------------- Command Message -----------------|
                |       (_result- createStream response)          |
                |                                                 |
       ---+---- |--------- Command Message (publish) ------------>|
          |     |                                                 |
       publish  |<-------- UserControl (StreamBegin) -------------|
          |     |                                                 |
          |     |---------- Data Message (Metadata) ------------->|
          |     |                                                 |
          |     |------------------ Audio Message---------------->|
          |     |                                                 |
          |     |----------------- SetChunkSize ----------------->|
          |     |                                                 |
          |     |<--------------- Command Message ----------------|
          |     |            (_result- publish result)            |
          |     |------------------ Video Message---------------->|
                                         |
                                         |
                           Until the stream is complete


publish命令结构如下:


字段 类型 说明
CommandName(命令名) String “publish”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
PublishingName(推流的名称) String 流名称
PublishingType(推流类型) String “live”、”record”、”append”中的一种。live表示该推流文件不会在服务器端存储;record表示该推流的文件会在服务器应用程序下的子目录下保存以便后续播放,如果文件已经存在的话删除原来所有的内容重新写入;append也会将推流数据保存在服务器端,如果文件不存在的话就会建立一个新文件写入,如果对应该流的文件已经存在的话保存原来的数据,在文件末尾接着写入


NetStream Commands8:seek(定位流的位置)


定位到视频或音频的某个位置,以毫秒为单位。 客户端发送搜寻命令在一个媒体文件中或播放列表中搜寻偏移。 seek命令的结构如下:


字段 类型 说明
CommandName(命令名) String “seek”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
milliSeconds Number 定位到该文件的xx毫秒处


NetStream Commands9:pause(暂停)


客户端告知服务端停止或恢复播放, 客户端发送暂停命令告诉服务端暂停或开始一个命令。 pause命令的结构如下:


字段 类型 说明
CommandName(命令名) String “pause”
TransactionID Number 恒为0
CommandObject NULL 对onSatus命令来说不需要这个字段
Pause/Unpause Flag Boolean true表示暂停,false表示恢复
milliSeconds Number 暂停或者恢复的时间,以毫秒为单位


2.1.7 聚合消息


  • MT=22, Aggregate message, 聚合消息是含有一个消息列表的一种消息。消息类型值 22 ,保留用于聚合消息。


+---------+-------------------------+  
  | Header  | Aggregate Message body  |  
  +---------+-------------------------+  
          聚合消息的格式
  +--------+--------------+--------------+--------+-------------+---------------+ - - - -
  |Header 0|Message Data 0|Back Pointer 0|Header 1|Message Data 1|Back Pointer 1|
  +--------+--------------+--------------+--------+--------------+--------------+ - - - -
            聚合消息的body  


Back Pointer包含了前面消息的大小(包括Header的大小)。这个设置匹配了 flv 文件格式,可用于后向搜索。


2.2 接收命令消息反馈结果 ResponseCommand


通过块消息携带的数据,拼接成消息内容,通过AMF解读消息内容


#define RTMPConnectSuccess      @"NetConnection.Connect.Success"
#define RTMPPublishStart        @"NetStream.Publish.Start"
#define RTMPPublishBadName      @"NetStream.Publish.BadName"
#define RTMPPlayStart           @"NetStream.Play.Start"
#define RTMPPlayReset           @"NetStream.Play.Reset"
#define RTMPPlayStreamNotFound  @"NetStream.Play.StreamNotFound"
typedef enum : char {
    RTMPResponseCommand_Result       = 0x1, //_Result命令
    RTMPResponseCommandOnBWDone      = 0x2, //OnBWDone命令
    RTMPResponseCommandOnFCPublish   = 0x3, //OnFCPublish命令
    RTMPResponseCommandOnStatus      = 0x4, //OnStatus命令
    RTMPResponseCommandOnFCUnpublish = 0x5, //OnFCUnpublish命令
    RTMPResponseCommandOnMetaData    = 0x6, //OnMetaData命令
    RTMPResponseCommandUnkonwn       = 0x7f,//未知类型
} RTMPResponseCommandType;


上面分析完了rtmp消息类型,但实际RTMP通信中并未按照上述格式去发送RTMP消息,而是将RTMP 消息分块发送,而且必须在一个Chunk发送完成之后才能开始发送下一个Chunk。每个Chunk中带有MessageID代表属于哪个Message,接收端也会按照这个id来将chunk组装成Message。为什么RTMP要将Message拆分成不同的Chunk呢?通过拆分,数据量较大的Message可以被拆分成较小的“Message”,这样就可以避免优先级低的消息持续发送阻塞优先级高的数据,比如在视频的传输过程中,会包括视频帧,音频帧和RTMP控制信息,如果持续发送音频数据或者控制数据的话可能就会造成视频帧的阻塞,然后就会造成看视频时最烦人的卡顿现象。同时对于数据量较小的Message,可以通过对Chunk Header的字段来压缩信息,从而减少信息的传输量。


下面了解下RTMP消息分块


2.3 RTMP消息分块


每个Chunk都由 Chunk Header + Chunk Data 组成:


+-------+     +--------------+----------------+  
  | Chunk |  =  | Chunk Header |   Chunk Data   |  
  +-------+     +--------------+----------------+


2.3.1 Chunk Header


Chunk Header 由 Basic Header + Message Header + ExtendedTimestamp(不一定存在)组成:


+--------------+     +-------------+----------------+-------------------+ 
  | Chunk Header |  =  | Basic header| Message Header |Extended Timestamp |  
  +--------------+     +-------------+----------------+-------------------+


2.3.1.1 Basic Header(基本的头信息) (1~3 byte)


+-+-+-+-+-+-+-+-+
  |fmt|   cs id   |
  +-+-+-+-+-+-+-+-+


chuck stream = cs


  • fmt: 表示块类型,决定了Chunk Msg Header的格式,它占第一个字节的0~1bit两位,
  • csid:表示块流id 占2~7bit属于csid。 ①csid在64~319的范围内时, csidTS=0,csid =(第二个字节的值)+64


&emsp;&emsp;&emsp; 0                   1            
&emsp;&emsp;&emsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |fmt|0 0 0 0 0 0|the second byte|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


②csid在64~65599的范围内时(①与②存在交集,原则上交集部分选择①), csidTS=0x3f,bit位全为1时,csid=(第二个字节的值×256)+(第三个字节的值)+64


&emsp;&emsp;&emsp; 0                   1                   2       
&emsp;&emsp;&emsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
&emsp;&emsp;&emsp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |fmt|1 1 1 1 1 1|the second byte| the third byte|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


③csid在3~63的范围内时, csidTS=1~0x3e,即6位bit非全0也非全1时,csid=csidTS


&emsp;&emsp;&emsp; 0               
&emsp;&emsp;&emsp; 0 1 2 3 4 5 6 7 
&emsp;&emsp;&emsp;+-+-+-+-+-+-+-+-+
     |fmt|0<csid<0x3f|
     +-+-+-+-+-+-+-+-+


注意:这里第一个字节的2~7bit的值暂时称之为csidTS 由此可见:Basic Header的长度范围为1~3 byte,具体多少byte是csidTS决定的,csid的值范围3~65599,0~2作为保留。


2.3.1.2 Chuck Message Header(块消息的消息头信息)(0、3、7、11 byte)


包含了要发送的实际信息(可能是完整的,也可能是一部分)的描述信息。Message Header的格式和长度取决于Basic Header的chunk type,共有4种不同的格式,由上面所提到的Basic Header中的fmt字段控制。 其中第一种格式可以表示其他三种表示的所有数据,但由于其他三种格式是基于对之前chunk的差量化的表示,因此可以更简洁地表示相同的数据,实际使用的时候还是应该采用尽量少的字节表示相同意义的数据。以下按照字节数从多到少的顺序分别介绍这4种格式的Chuck Message Header


0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
  |                     timestamp                 | message length:           
  +-------------------------------+---------------+---------------+  
  :                               |message type id|               : 
  +-------------------------------+---------------+---------------+ 
  :                  message stream id            |  
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  • timestamp(时间戳): 占 3 byte 最大表示16777215=0xFFFFFF=2^24-1,超出这个值,这3个字节置为1,将实际数据转存到Extended Timestamp字段中。
  • message length(长度): 占 3 byte 表示实际发送的消息的数据如音频帧、视频帧等数据的长度,单位是字节。注意这里是Message的长度,也就是chunk属于的Message的总数据长度,而不是chunk本身Data的数据的长度。
  • message type id(消息的类型id): 占 1 byte 表示实际发送的数据的类型,如8代表音频数据、9代表视频数据。
  • message stream id(消息的流id): 占 4byte 表示该chunk所在的流的ID,和Basic Header的CSID一样,它采用小端存储的方式。


  1. fmt=0:长度11 byte,其他三种能表示的数据它都能表示 , 在一个块流的开始和时间戳返回的时候必须有这种块: Chuck Message Header = timestamp + message length + message type id + message stream id
  2. fmt=1:长度为7 byte,与fmt=0时,相比,该类型少了Message Stream Id,具有可变大小消息的流,在第一个消息之后的每个消息的第一个块应该使用这个格式:Chuck Message Header = timestamp + message length + message type id
  3. fmt=2:长度3 byte,不包含Message Stream Id和Message Length 、Message type Id,具有固定大小消息的流,在第一个消息之后的每个消息的第一个块应该使用这个格式:Chuck Message Header = timestamp
  4. fmt=3:长度为0 byte,当一个消息被分成多个块,除了第一块以外,所有的块都应使用这种类型 : Chuck Message Header = 0 byte


注意: message type id 发送音视频数据的时候


  • 如果包头MessageTypeID为0x8或0x9,数据(chunk data)是flv的tag data(没有tag header),flv格式封装请见FLV格式解析
  • 也可以用新类型MessageTypeID为0x16,数据(chunk data)是一个完整flv的tag(tag header + tag data)
  • message stream id 采用小端存储
  • RTMP都是大端模式,所以发送数据,包头,交互消息都要填写大端模式的,但是只有streamID是小端模式


2.3.1.3 ExtendedTimestamp(扩展时间) (0、4 byte)


0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  |                           timestamp                           |   
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  • 只有当块消息头中的普通时间戳设置为 0xffffff 时,本字段才被传送。
  • 如果普通时间戳的值小于 0x00ffffff ,那么本字段一定不能出现。
  • 如果块消息头中时间戳字段不出现本字段也一定不能出现。
  • 类型 3 的块一定不能含有本字段。
  • 本字段在块消息头之后,块数据之前。


2.3.2 Chunk Data


+-----------+
  |Chunk Data |
  +-----------+


用户层面上真正想要发送的与协议无关的数据,长度在(0,chunkSize]之间, chunk size默认为128字节。


2.3.3 RTMP消息分块注意事项


  • Chunk Size: RTMP是按照chunk size进行分块,chunk size 指的是 chunk的payload部分的大小,不包括chunk basic header 和 chunk message header长度。客户端和服务器端各自维护了两个chunk size, 分别是自身分块的chunk size 和 对端 的chunk size, 默认的这两个chunk size都是128字节。通过向对端发送set chunk size 消息可以告知对方更改了 chunk size的大小。
  • Chunk Type: RTMP消息分成的Chunk有4种类型,可以通过 chunk basic header的高两位(fmt)指定,一般在拆包的时候会把一个RTMP消息拆成以格式0开始的chunk,之后的包拆成格式3 类型的chunk,我查看了有不少代码也是这样实现的,这样也是最简单的实现。


如果第二个message和第一个message的message stream ID 相同,并且第二个message的长度也大于了chunk size,那么该如何拆包?当时查了很多资料,都没有介绍。后来看了一些源码,如 SRS,FFMPEG中的实现,发现第二个message可以拆成Type_1类型一个chunk, message剩余的部分拆成Type_3类型的chunk。FFMPEG中就是这么做的。


srs-librtmp分块结构封装:


class SrsChunkStream
{
public:
    // Represents the basic header fmt,
    // which used to identify the variant message header type.
    char fmt;
    // Represents the basic header cid,
    // which is the chunk stream id.
    int cid;
    // Cached message header
    SrsMessageHeader header;
    // Whether the chunk message header has extended timestamp.
    bool extended_timestamp;
    // The partially read message.
    SrsCommonMessage* msg;
    // Decoded msg count, to identify whether the chunk stream is fresh.
    int64_t msg_count;
public:
    SrsChunkStream(int _cid);
    virtual ~SrsChunkStream();
};


3.代码分析


我们先看几个srs-librtmp封装的结构: runtime context, 我们初始化配置及传入的url以及url解析结果等:


struct Context
{
    // The original RTMP url.
    std::string url;
    // Parse from url.
    std::string tcUrl;
    std::string host;
    std::string vhost;
    std::string app;
    std::string stream;
    std::string param;
    // Parse ip:port from host.
    std::string ip;
    int port;
    // The URL schema, about vhost/app/stream?param
    srs_url_schema schema;
    // The server information, response by connect app.
    SrsServerInfo si;
    // The extra request object for connect to server, NULL to ignore.
    SrsRequest* req;
    // the message received cache,
    // for example, when got aggregate message,
    // the context will parse to videos/audios,
    // and return one by one.
    std::vector<SrsCommonMessage*> msgs;
    SrsRtmpClient* rtmp;
    SimpleSocketStream* skt;
    int stream_id;
    // the remux raw codec.
    SrsRawH264Stream avc_raw;
    SrsRawAacStream aac_raw;
    // about SPS, @see: 7.3.2.1.1, ISO_IEC_14496-10-AVC-2012.pdf, page 62
    std::string h264_sps;
    std::string h264_pps;
    // whether the sps and pps sent,
    // @see https://github.com/ossrs/srs/issues/203
    bool h264_sps_pps_sent;
    // only send the ssp and pps when both changed.
    // @see https://github.com/ossrs/srs/issues/204
    bool h264_sps_changed;
    bool h264_pps_changed;
    // the aac sequence header.
    std::string aac_specific_config;
    // user set timeout, in ms.
    int64_t stimeout;
    int64_t rtimeout;
    // The RTMP handler level buffer, can used to format packet.
    char buffer[1024];
    Context() : port(0) {
        rtmp = NULL;
        skt = NULL;
        req = NULL;
        stream_id = 0;
        h264_sps_pps_sent = false;
        h264_sps_changed = false;
        h264_pps_changed = false;
        rtimeout = stimeout = SRS_UTIME_NO_TIMEOUT;
        schema = srs_url_schema_normal;
    }
    virtual ~Context() {
        srs_freep(req);
        srs_freep(rtmp);
        srs_freep(skt);
        std::vector<SrsCommonMessage*>::iterator it;
        for (it = msgs.begin(); it != msgs.end(); ++it) {
            SrsCommonMessage* msg = *it;
            srs_freep(msg);
        }
        msgs.clear();
    }
};


里面又涉及到了四个重要结构:


  • SrsServerInfo:The server information, response by connect app.
  • SrsRequest:The extra request object for connect to server, NULL to ignore.
  • SrsRtmpClient:rtmp客户端相关信息
  • SimpleSocketStream: 真正的socket封装,跟我们之前文章深入理解rtmp(二)之脚手架搭建中的SimpleSocketStream一样


SrsServerInfo结构,里面信息对于我们客户端用处不是特别大:


struct SrsServerInfo
{
    std::string ip;
    std::string sig;
    int pid;
    int cid;
    int major;
    int minor;
    int revision;
    int build;
    SrsServerInfo();
};


SrsRequest结构:


class SrsRequest
{
public:
    // The client ip.
    std::string ip;
public:
    // The tcUrl: rtmp://request_vhost:port/app/stream
    // support pass vhost in query string, such as:
    //    rtmp://ip:port/app?vhost=request_vhost/stream
    //    rtmp://ip:port/app...vhost...request_vhost/stream
    std::string tcUrl;
    std::string pageUrl;
    std::string swfUrl;
    double objectEncoding;
// The data discovery from request.
public:
    // Discovery from tcUrl and play/publish.
    std::string schema;
    // The vhost in tcUrl.
    std::string vhost;
    // The host in tcUrl.
    std::string host;
    // The port in tcUrl.
    int port;
    // The app in tcUrl, without param.
    std::string app;
    // The param in tcUrl(app).
    std::string param;
    // The stream in play/publish
    std::string stream;
    // For play live stream,
    // used to specified the stop when exceed the duration.
    // @see https://github.com/ossrs/srs/issues/45
    // in srs_utime_t.
    srs_utime_t duration;
    // The token in the connect request,
    // used for edge traverse to origin authentication,
    // @see https://github.com/ossrs/srs/issues/104
    SrsAmf0Object* args;
public:
    SrsRequest();
    virtual ~SrsRequest();
public:
    // Deep copy the request, for source to use it to support reload,
    // For when initialize the source, the request is valid,
    // When reload it, the request maybe invalid, so need to copy it.
    virtual SrsRequest* copy();
    // update the auth info of request,
    // To keep the current request ptr is ok,
    // For many components use the ptr of request.
    virtual void update_auth(SrsRequest* req);
    // Get the stream identify, vhost/app/stream.
    virtual std::string get_stream_url();
    // To strip url, user must strip when update the url.
    virtual void strip();
public:
    // Transform it as HTTP request.
    virtual SrsRequest* as_http();
};


SrsRtmpClient:


// implements the client role protocol.
class SrsRtmpClient
{
private:
    SrsHandshakeBytes* hs_bytes;//跟我们之前封装的握手接口类似
protected:
    SrsProtocol* protocol;//rtmp协议封装,就是封装了我们的connect, createStream,publish等接口
    ISrsProtocolReadWriter* io;//就是SimpleSocketStream
public:
    SrsRtmpClient(ISrsProtocolReadWriter* skt);
    virtual ~SrsRtmpClient();
// Protocol methods proxy
public:
    virtual void set_recv_timeout(srs_utime_t tm);
    virtual void set_send_timeout(srs_utime_t tm);
    virtual int64_t get_recv_bytes();
    virtual int64_t get_send_bytes();
    virtual srs_error_t recv_message(SrsCommonMessage** pmsg);
    virtual srs_error_t decode_message(SrsCommonMessage* msg, SrsPacket** ppacket);
    virtual srs_error_t send_and_free_message(SrsSharedPtrMessage* msg, int stream_id);
    virtual srs_error_t send_and_free_messages(SrsSharedPtrMessage** msgs, int nb_msgs, int stream_id);
    virtual srs_error_t send_and_free_packet(SrsPacket* packet, int stream_id);
public:
    // handshake with server, try complex, then simple handshake.
    virtual srs_error_t handshake();
    // only use simple handshake
    virtual srs_error_t simple_handshake();
    // only use complex handshake
    virtual srs_error_t complex_handshake();
    // Connect to RTMP tcUrl and app, get the server info.
    //
    // @param app, The app to connect at, for example, live.
    // @param tcUrl, The tcUrl to connect at, for example, rtmp://ossrs.net/live.
    // @param req, the optional req object, use the swfUrl/pageUrl if specified. NULL to ignore.
    // @param dsu, Whether debug SRS upnode. For edge, set to true to send its info to upnode.
    // @param si, The server information, retrieve from response of connect app request. NULL to ignore.
    virtual srs_error_t connect_app(std::string app, std::string tcUrl, SrsRequest* r, bool dsu, SrsServerInfo* si);
    // Create a stream, then play/publish data over this stream.
    virtual srs_error_t create_stream(int& stream_id);
    // start play stream.
    virtual srs_error_t play(std::string stream, int stream_id, int chunk_size);
    // start publish stream. use flash publish workflow:
    //       connect-app => create-stream => flash-publish
    virtual srs_error_t publish(std::string stream, int stream_id, int chunk_size);
    // start publish stream. use FMLE publish workflow:
    //       connect-app => FMLE publish
    virtual srs_error_t fmle_publish(std::string stream, int& stream_id);
public:
    template<class T>
    srs_error_t expect_message(SrsCommonMessage** pmsg, T** ppacket)
    {
        return protocol->expect_message<T>(pmsg, ppacket);
    }
};


SimpleSocketStream和我们之前的类似,只是srs作者做了一层接口抽象:


/**
 * The system io reader/writer architecture:
 *                                         +---------------+  +---------------+
 *                                         | IStreamWriter |  | IVectorWriter |
 *                                         +---------------+  +---------------+
 *                                         | + write()     |  | + writev()    |
 *                                         +-------------+-+  ++--------------+
 * +----------+     +--------------------+               /\   /\
 * | IReader  |     |    IStatistic      |                 \ /
 * +----------+     +--------------------+                  V
 * | + read() |     | + get_recv_bytes() |           +------+----+
 * +------+---+     | + get_send_bytes() |           |  IWriter  |
 *       / \        +---+--------------+-+           +-------+---+
 *        |            / \            / \                   / \
 *        |             |              |                     |
 * +------+-------------+------+      ++---------------------+--+
 * | IProtocolReader           |      | IProtocolWriter         |
 * +---------------------------+      +-------------------------+
 * | + readfully()             |      | + set_send_timeout()    |
 * | + set_recv_timeout()      |      +-------+-----------------+
 * +------------+--------------+             / \
 *             / \                            |
 *              |                             |
 *           +--+-----------------------------+-+
 *           |       IProtocolReadWriter        |
 *           +----------------------------------+
 */


我们再看一下SrsProtocol:


// The protocol provides the rtmp-message-protocol services,
// To recv RTMP message from RTMP chunk stream,
// and to send out RTMP message over RTMP chunk stream.
class SrsProtocol
{
private:
    class AckWindowSize
    {
    public:
        uint32_t window;
        // number of received bytes.
        int64_t nb_recv_bytes;
        // previous responsed sequence number.
        uint32_t sequence_number;
        AckWindowSize();
    };
// For peer in/out
private:
    // The underlayer socket object, send/recv bytes.
    ISrsProtocolReadWriter* skt;
    // The requests sent out, used to build the response.
    // key: transactionId
    // value: the request command name
    std::map<double, std::string> requests;
// For peer in
private:
    // The chunk stream to decode RTMP messages.
    std::map<int, SrsChunkStream*> chunk_streams;
    // Cache some frequently used chunk header.
    // cs_cache, the chunk stream cache.
    SrsChunkStream** cs_cache;
    // The bytes buffer cache, recv from skt, provide services for stream.
    SrsFastStream* in_buffer;
    // The input chunk size, default to 128, set by peer packet.
    int32_t in_chunk_size;
    // The input ack window, to response acknowledge to peer,
    // For example, to respose the encoder, for server got lots of packets.
    AckWindowSize in_ack_size;
    // The output ack window, to require peer to response the ack.
    AckWindowSize out_ack_size;
    // The buffer length set by peer.
    int32_t in_buffer_length;
    // Whether print the protocol level debug info.
    // Generally we print the debug info when got or send first A/V packet.
    bool show_debug_info;
    // Whether auto response when recv messages.
    bool auto_response_when_recv;
    // When not auto response message, manual flush the messages in queue.
    std::vector<SrsPacket*> manual_response_queue;
// For peer out
private:
    iovec* out_iovs;
    int nb_out_iovs;
    char* out_c0c3_caches;
    // Whether warned user to increase the c0c3 header cache.
    bool warned_c0c3_cache_dry;
    // The output chunk size, default to 128, set by config.
    int32_t out_chunk_size;
public:
    SrsProtocol(ISrsProtocolReadWriter* io);
    virtual ~SrsProtocol();
public:
    // Set the auto response message when recv for protocol stack.
    virtual void set_auto_response(bool v);
    virtual srs_error_t manual_response_flush();
public:
public:
    virtual void set_recv_timeout(srs_utime_t tm);
    virtual srs_utime_t get_recv_timeout();
    virtual void set_send_timeout(srs_utime_t tm);
    virtual srs_utime_t get_send_timeout();
    // Get recv/send bytes.
    virtual int64_t get_recv_bytes();
    virtual int64_t get_send_bytes();
public:
    virtual srs_error_t set_in_window_ack_size(int ack_size);
public:
    virtual srs_error_t recv_message(SrsCommonMessage** pmsg);
    virtual srs_error_t decode_message(SrsCommonMessage* msg, SrsPacket** ppacket);
    virtual srs_error_t send_and_free_message(SrsSharedPtrMessage* msg, int stream_id);
    virtual srs_error_t send_and_free_messages(SrsSharedPtrMessage** msgs, int nb_msgs, int stream_id);
    virtual srs_error_t send_and_free_packet(SrsPacket* packet, int stream_id);
private:
    virtual srs_error_t do_send_messages(SrsSharedPtrMessage** msgs, int nb_msgs);
    virtual srs_error_t do_iovs_send(iovec* iovs, int size);
    virtual srs_error_t do_send_and_free_packet(SrsPacket* packet, int stream_id);
    virtual srs_error_t do_decode_message(SrsMessageHeader& header, SrsBuffer* stream, SrsPacket** ppacket);
    virtual srs_error_t recv_interlaced_message(SrsCommonMessage** pmsg);
    virtual srs_error_t read_basic_header(char& fmt, int& cid);
    virtual srs_error_t read_message_header(SrsChunkStream* chunk, char fmt);
    virtual srs_error_t read_message_payload(SrsChunkStream* chunk, SrsCommonMessage** pmsg);
    virtual srs_error_t on_recv_message(SrsCommonMessage* msg);
    virtual srs_error_t on_send_packet(SrsMessageHeader* mh, SrsPacket* packet);
private:
    virtual srs_error_t response_acknowledgement_message();
    virtual srs_error_t response_ping_message(int32_t timestamp);
private:
    virtual void print_debug_info();
};


了解完主要的结构,继续看connect app:


connect


最终调用到了SrsRtmpClient里面的connect_app:


context->rtmp->connect_app(c->app, tcUrl, c->req, true, &c->si))


tcUrl格式:rtmp://host或vhost:port/app,req可以调用srs_rtmp_set_connect_args创建,默认为空,&c->si是要存储服务端返回的SrsServerInfo


在connect_app中首先构造了SrsConnectAppPacket:


SrsConnectAppPacket* pkt = new SrsConnectAppPacket();
        pkt->command_object->set("app", SrsAmf0Any::str(app.c_str()));
        pkt->command_object->set("flashVer", SrsAmf0Any::str("WIN 15,0,0,239"));
        if (r) {
            pkt->command_object->set("swfUrl", SrsAmf0Any::str(r->swfUrl.c_str()));
        } else {
            pkt->command_object->set("swfUrl", SrsAmf0Any::str());
        }
        if (r && r->tcUrl != "") {
            pkt->command_object->set("tcUrl", SrsAmf0Any::str(r->tcUrl.c_str()));
        } else {
            pkt->command_object->set("tcUrl", SrsAmf0Any::str(tcUrl.c_str()));
        }
        pkt->command_object->set("fpad", SrsAmf0Any::boolean(false));
        pkt->command_object->set("capabilities", SrsAmf0Any::number(239));
        pkt->command_object->set("audioCodecs", SrsAmf0Any::number(3575));
        pkt->command_object->set("videoCodecs", SrsAmf0Any::number(252));
        pkt->command_object->set("videoFunction", SrsAmf0Any::number(1));
        if (r) {
            pkt->command_object->set("pageUrl", SrsAmf0Any::str(r->pageUrl.c_str()));
        } else {
            pkt->command_object->set("pageUrl", SrsAmf0Any::str());
        }
        pkt->command_object->set("objectEncoding", SrsAmf0Any::number(0));
        if (dsu && r && r->args) {
            srs_freep(pkt->args);
            pkt->args = r->args->copy()->to_object();
        }
        if ((err = protocol->send_and_free_packet(pkt, 0)) != srs_success) {//发送packet
            return srs_error_wrap(err, "send packet");
        }


SrsConnectAppPacket结构:


class SrsConnectAppPacket : public SrsPacket
{
public:
    // Name of the command. Set to "connect".
    std::string command_name;
    // Always set to 1.
    double transaction_id;
    SrsAmf0Object* command_object;
    SrsAmf0Object* args;
public:
    SrsConnectAppPacket();
    virtual ~SrsConnectAppPacket();
// Decode functions for concrete packet to override.
public:
    virtual srs_error_t decode(SrsBuffer* stream);
// Encode functions for concrete packet to override.
public:
    virtual int get_prefer_cid();
    virtual int get_message_type();
protected:
    virtual int get_size();
    virtual srs_error_t encode_packet(SrsBuffer* stream);
};


对应我们前面connect消息结构封装,command_name固定为"connect",transaction_id固定为1 发送packet调用SrsProtocol的send_and_free_packet,最终调用到:


srs_error_t SrsProtocol::do_send_and_free_packet(SrsPacket* packet, int stream_id)
{
    srs_error_t err = srs_success;
    srs_assert(packet);
    SrsAutoFree(SrsPacket, packet);
    SrsCommonMessage* msg = new SrsCommonMessage();
    SrsAutoFree(SrsCommonMessage, msg);
    if ((err = packet->to_msg(msg, stream_id)) != srs_success) {
        return srs_error_wrap(err, "to message");
    }
    SrsSharedPtrMessage* shared_msg = new SrsSharedPtrMessage();
    if ((err = shared_msg->create(msg)) != srs_success) {
        srs_freep(shared_msg);
        return srs_error_wrap(err, "create message");
    }
    if ((err = send_and_free_message(shared_msg, stream_id)) != srs_success) {
        return srs_error_wrap(err, "send packet");
    }
    if ((err = on_send_packet(&msg->header, packet)) != srs_success) {
        return srs_error_wrap(err, "on send packet");
    }
    return err;
}


先将packet转换为message,主要是构造MessageHeader,最终在do_send_messages将消息拆分成块,再通过socket将块发送出去


srs_error_t SrsProtocol::do_send_messages(SrsSharedPtrMessage** msgs, int nb_msgs)
{
    srs_error_t err = srs_success;
#ifdef SRS_PERF_COMPLEX_SEND
    int iov_index = 0;
    iovec* iovs = out_iovs + iov_index;
    int c0c3_cache_index = 0;
    char* c0c3_cache = out_c0c3_caches + c0c3_cache_index;
    // try to send use the c0c3 header cache,
    // if cache is consumed, try another loop.
    for (int i = 0; i < nb_msgs; i++) {
        SrsSharedPtrMessage* msg = msgs[i];
        if (!msg) {
            continue;
        }
        // ignore empty message.
        if (!msg->payload || msg->size <= 0) {
            continue;
        }
        // p set to current write position,
        char* p = msg->payload;
        char* pend = msg->payload + msg->size;
        // always write the header event payload is empty.
        while (p < pend) {
            // always has header
            int nb_cache = SRS_CONSTS_C0C3_HEADERS_MAX - c0c3_cache_index;
            int nbh = msg->chunk_header(c0c3_cache, nb_cache, p == msg->payload);
            srs_assert(nbh > 0);
            // header iov
            iovs[0].iov_base = c0c3_cache;
            iovs[0].iov_len = nbh;
            // payload iov
            int payload_size = srs_min(out_chunk_size, (int)(pend - p));
            iovs[1].iov_base = p;
            iovs[1].iov_len = payload_size;
            // consume sendout bytes.
            p += payload_size;
            if (iov_index >= nb_out_iovs - 2) {
                int ov = nb_out_iovs;
                nb_out_iovs = 2 * nb_out_iovs;
                int realloc_size = sizeof(iovec) * nb_out_iovs;
                out_iovs = (iovec*)realloc(out_iovs, realloc_size);
                srs_warn("resize iovs %d => %d, max_msgs=%d", ov, nb_out_iovs, SRS_PERF_MW_MSGS);
            }
            // to next pair of iovs
            iov_index += 2;
            iovs = out_iovs + iov_index;
            // to next c0c3 header cache
            c0c3_cache_index += nbh;
            c0c3_cache = out_c0c3_caches + c0c3_cache_index;
            // the cache header should never be realloc again,
            // for the ptr is set to iovs, so we just warn user to set larger
            // and use another loop to send again.
            int c0c3_left = SRS_CONSTS_C0C3_HEADERS_MAX - c0c3_cache_index;
            if (c0c3_left < SRS_CONSTS_RTMP_MAX_FMT0_HEADER_SIZE) {
                // only warn once for a connection.
                if (!warned_c0c3_cache_dry) {
                    srs_warn("c0c3 cache header too small, recoment to %d", SRS_CONSTS_C0C3_HEADERS_MAX + SRS_CONSTS_RTMP_MAX_FMT0_HEADER_SIZE);
                    warned_c0c3_cache_dry = true;
                }
                // when c0c3 cache dry,
                // sendout all messages and reset the cache, then send again.
                if ((err = do_iovs_send(out_iovs, iov_index)) != srs_success) {
                    return srs_error_wrap(err, "send iovs");
                }
                // reset caches, while these cache ensure
                // atleast we can sendout a chunk.
                iov_index = 0;
                iovs = out_iovs + iov_index;
                c0c3_cache_index = 0;
                c0c3_cache = out_c0c3_caches + c0c3_cache_index;
            }
        }
    }
    // maybe the iovs already sendout when c0c3 cache dry,
    // so just ignore when no iovs to send.
    if (iov_index <= 0) {
        return err;
    }
    return do_iovs_send(out_iovs, iov_index);
#else
    // try to send use the c0c3 header cache,
    // if cache is consumed, try another loop.
    for (int i = 0; i < nb_msgs; i++) {
        SrsSharedPtrMessage* msg = msgs[i];
        if (!msg) {
            continue;
        }
        // ignore empty message.
        if (!msg->payload || msg->size <= 0) {
            continue;
        }
        // p set to current write position,
        char* p = msg->payload;
        char* pend = msg->payload + msg->size;
        // always write the header event payload is empty.
        while (p < pend) {
            // for simple send, send each chunk one by one
            iovec* iovs = out_iovs;
            char* c0c3_cache = out_c0c3_caches;
            int nb_cache = SRS_CONSTS_C0C3_HEADERS_MAX;
            // always has header
            int nbh = msg->chunk_header(c0c3_cache, nb_cache, p == msg->payload);
            srs_assert(nbh > 0);
            // header iov
            iovs[0].iov_base = c0c3_cache;
            iovs[0].iov_len = nbh;
            // payload iov
            int payload_size = srs_min(out_chunk_size, pend - p);
            iovs[1].iov_base = p;
            iovs[1].iov_len = payload_size;
            // consume sendout bytes.
            p += payload_size;
            if ((er = skt->writev(iovs, 2, NULL)) != srs_success) {
                return srs_error_wrap(err, "writev");
            }
        }
    }
    return err;
#endif
}


connect后设置SrsSetWindowAckSizePacket,然后从服务端读取SrsConnectAppResPacket并解析.


贴的代码有点多,篇幅太长了,这篇先分析到这里面,后面再写续一篇代码分析,分析一下音视频收发以及srs-librtmp的一些优化.


image.png

目录
相关文章
|
7月前
|
网络协议 Linux iOS开发
推荐:实现RTSP/RTMP/HLS/HTTP协议的轻量级流媒体框架,支持大并发连接请求
推荐:实现RTSP/RTMP/HLS/HTTP协议的轻量级流媒体框架,支持大并发连接请求
296 1
|
4月前
|
网络协议 开发工具 C#
RTSP协议探究和RTSP播放器技术实现
RTSP播放器可广泛应用于对延迟要求比较高的场景下,比如协同操控相关的智能机器人或无人机、实时视频监控、远程视频会议、网络电视等。通过控制信令实现对流媒体数据的远程控制和传输管理。
151 0
|
1月前
|
编解码 索引
RTMP 和 HLS 协议的优缺点
【10月更文挑战第26天】RTMP和HLS协议各有优缺点,在选择使用哪种协议时,需要根据具体的直播场景、观众群体、设备兼容性、服务器性能等因素进行综合考虑,以选择最适合的直播协议。
|
7月前
|
监控 网络协议 网络安全
【专栏】RTMP和RTSP是流媒体传输常用的协议:秒懂
【4月更文挑战第28天】RTMP和RTSP是流媒体传输常用的协议。RTMP由Adobe开发,适合低延迟的实时通信,常用于网络直播和在线游戏;而RTSP是IETF定义的协议,侧重于流媒体播放控制,适用于视频监控和VoD服务。RTMP在业界普及度高,RTSP则在专业领域更常见。选择时需考虑延迟、应用场景和安全性等因素。
884 1
|
网络协议 网络安全 流计算
【流媒体】RTMP、RTSP、HLS、HTTP协议的介绍与对比
【流媒体】RTMP、RTSP、HLS、HTTP协议的介绍与对比
457 0
|
7月前
|
编解码 网络协议 流计算
RTSP协议介绍
RTSP协议介绍
372 0
|
7月前
|
Linux C语言
RTSP协议的实现
RTSP协议的实现
89 0
|
编解码 应用服务中间件 nginx
如何实现rtsp h265 转 rtmp (rtsp hevc 转 rtmp)并转发到CDN或自建服务器
rtsp h265 转 rtmp,首先要对rtmp协议做扩展,目前国内已有相应扩展标准,国内开发者基本上都按这个扩展协议做的。协议层问题已解决。剩下关键问题是要实现rtmp h265推送模块, 支持rtmp h265 的server, rtmp h265播放模块。
240 1
[笔记]音视频学习之RTSP篇《一》rtsp协议简介
[笔记]音视频学习之RTSP篇《一》rtsp协议简介
|
编解码 应用服务中间件 nginx
RTSP协议转换RTMP直播协议
RTSP协议转换RTMP直播协议
561 1