视频技术详解:RTMP H5 直播流技术解析

WodehousMurray 发布于1年前

本文聚焦 RTMP 协议的最精华的内容,接进行实际操作 Buffer 的练习和协议的学习。
RTMP 是什么
RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议,来完成对指定直播流的播放和相关的操作。和现行的直播流相比,RTMP 主要的特点就是高效,这里,我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。
RTMP 握手
RTMP 是基于 TCP 三次握手之后的,所以,RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图:

(C 代表 Client,S 代表 Server)
它主要是通过两端的字段内容协商,来完成可信度认证的。基本过程如下:
client: 客户端需要发 3 个包。C0,C1,C2
server: 服务端也需要发同样 3 个包。 S0,S1,S2。
整个过程如上图所述,但实际上有些细节需要注意。
握手开始:
【1】 客户端发送 C0,C1 包
此时,客户端处于等待状态。客户端有两个限制:
客户端在未接受到 S1 之前不能发送 C2 包
客户端在未接收到 S2 之前不能发送任何实际数据包
【2】 服务端在接受到 C0,发送 S0,S1 包。也可以等到接受到 C1 之后再一起发送,C1 包的等待不是必须的。
此时,服务端处于等待状态。服务端有两个限制:
服务端在未接受到 C1 之前不能发送 S2.
服务端在未接收到 C2 之前不能发送任何实际数据包
【3】客户端接受到 S1/S0 包后,发送 C2 包。
【4】服务端接受到 C2 包后,返回 S2 包,并且此时握手已经完成。
不过,在实际应用中,并不是严格按照上面的来。因为 RTMP 并不是强安全性的协议,所以,S2/C2 包只需要 C1/S1 中的内容,就可以完成内容的拼接。

这么多限制,说白了,其实就是一种通用模式:
C0+C1
S0+S1+S2
C2
接下来,我们来具体看看 C/S 012 包分别代表什么。
C0 && S0
C0 和 S0 其实区别不大,我这里主要讲解一下 C0,就差不多了。首先,C0 的长度为 1B。它的主要工作是确定 RTMP 的版本号。
C0:客户端发送其所支持的 RTMP 版本号:3~31。一般都是写 3。
S1:服务端返回其所支持的版本号。如果没有客户端的版本号,默认返回 3。
C1 && S1
C1/S1 长度为 1536B。主要目的是确保握手的唯一性。格式为:

time: 发送时间戳,这个其实不是很重要,不过需要记住,不要超出 4B 的范围即可。
zero: 保留值 0.
random: 该字段长尾 1528B。主要内容就是随机值,不管你用什么产生都可以。它主要是为了保证此次握手的唯一性,和确定握手的对象。
C2 && S2
C2/S2 的长度也是 1536B。相当于就是 S1/C1 的响应值。上图也简单说明了就是,对应 C1/S1 的 Copy 值,不过第二个字段有区别。基本格式为:

time: 时间戳,同上,也不是很重要
time2: C1/S1 发送的时间戳。
random: S1/C1 发送的随机数。长度为 1528B。
这里需要提及的是,RTMP 默认都是使用 Big-Endian 进行写入和读取,除非强调对某个字段使用 Little-Endian 字节序。
上面握手协议的顺序也是根据其中相关的字段来进行制定的。这样,看起来很容易啊哈,但是,我们并不仅仅停留在了解,而是要真正的了解,接下来,我们来实现一下,如果通过 Buffer 来进行 3 次握手。这里,我们作为 Client 端来进行请求的发起,假设 Server 端是按照标准进行发送即可。
Buffer 实操握手
我们使用 Buffer 实操主要涉及两块,一个块是 request server 的搭建,还有一块是 Buffer 的拼接。
Request Server 搭建
这里的 Server 是直接使用底层的 TCP 连接。
如下,一个简易的模板:
const client = new net.Socket();

client.connect({

port: 1935,
host: "6721.myqcloud.com"},
()=>{
    console.log("connected");
});

client.on('data',(data)=>{

client.write('hello');

});
不过,为了更好的进行实际演练,我们通过 EventEmitter 的方式,来做一个筛选器。这里,我们使用 mitt 模块来做代理。
const Emitter = require('mitt')();
然后,我们只要分析的就是将要接受到的 S0/1/2 包。根据上面的字节包图,可以清楚的知道包里面的详细内容。这里,为了简单起见,我们排除其他协议的包头,只是针对 RTMP 里面的包。而且,我们针对的只有 3 种包,S0/1/2。为了达到这种目的,我们需要在 data 时间中,加上相应的钩子才行。
这里,我们借用 Now 直播的 RTMP 流来进行相关的 RTMP 直播讲解。
Buffer 操作
Server 的搭建其实上网搜一搜,应该都可以搜索出来。关键点在于,如何针对 RTMP 的实操握手进行 encode/decode。所以,这里,我们针对上述操作,来主要讲解一下。
我们主要的工作量在于如何构造出 C0/1/2。根据上面格式的描述,大家应该可以清楚的知道 C0/1/2 里面的格式分别有啥。
比如,C1 中的 time 和 random,其实并不是必须字段,所以,为了简单起见,我们可以默认设为 0。具体代码如下:
class C {

constructor() {
    this.time;
    this.random;
}
C0() {
    let buf = Buffer.alloc(1);
    buf[0] = 3;
    return buf;
}
C1() {
    let buf = Buffer.alloc(1536);
    return buf;
}
/**
 * write C2 package
 * @param {Number} time the 4B Number of time
 * @param {Buffer} random 1528 byte
 */
produceC2(){
    let buf = Buffer.alloc(1536);
    // leave empty value as origin time
    buf.writeUInt32BE(this.time, 4);
    this.random.copy(buf,8,0,1528);

    return buf;
}
get getC01(){
    return Buffer.concat([this.C0(),this.C1()]);
}
get C2(){
    return this.produceC2();
}

}
接下来,我们来看一下,结合 server 完成的 RTMP 客户端服务。
const Client = new net.Socket();
const RTMP_C = new C();

Client.connect({

port: 1935,
host: "6721.liveplay.myqcloud.com"

}, () => {

console.log('connected')
Client.write(RTMP_C.getC01);

});

Client.on('data',res=>{

if(!res){
    console.warn('received empty Buffer ' + res);
    return;
}
// start to decode res package
if(!RTMP_C.S0 && res.length>0){
    RTMP_C.S0 = res.readUInt8(0);
    res = res.slice(1);
}

if(!RTMP_C.S1 && res.length>=1536){
    RTMP_C.time = res.readUInt32BE(0);
    RTMP_C.random = res.slice(8,1536);
    RTMP_C.S1 = true;
    res = res.slice(1536);
    console.log('send C2');
    Client.write(RTMP_C.C2);
}

if(!RTMP_C.S2 && res.length >= 1536){
    RTMP_C.S2 = true;
    res = res.slice(1536);
}

})
详细代码可以参考 gist。
RTMP 基本架构
RTMP 整个内容,除了握手,其实剩下的就是一些列围绕 type id 的 message。为了让大家更清楚的看到整个架构,这里简单陈列了一份框架:

在 Message 下的 3 个一级子 Item 就是我们现在将要大致讲解的内容。
可以看到上面所有的 item 都有一个共同的父 Item–Message。它的基本结构为:
Header: header 部分用来标识不同的 typeID,告诉客户端相应的 Message 类型。另外,还有个功效就是多路分发。
Body: Body 内容就是相应发送的数据。这个根据不同的 typeID 来说,格式就完全不一样了。
下面,我们先了解一下 Header 和不同 typeID 的内容:
Header
RTMP 中的 Header 分为 Basic Header 和 Message Header。需要注意,他们两者并不是独立的,而是相互联系。Message Header 的结构由 Basic Header 的内容来决定。

接下来,先分开来讲解:
Basic Header
BH(基础头部)主要是定义了该 chunk stream ID 和 chunk type。需要注意的是,BH 是变长度的,即,它的长度范围是 1-3B。怎么讲呢?就是根据不同的 chunk stream ID 来决定具体的长度。CS ID(Chunk Stream ID)本身的支持的范围为 <= 65597 ,差不多为 22bit。当然,为了节省这 3B 的内容。 Adobe 搞了一个比较绕的理论,即,通过如下格式中的 CS ID 来确定:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|fmt| cs id |
+-+-+-+-+-+-+-+-+
即,通过 2-7 bit 位来确定整个 BH 的长度。怎么确定呢?
RTMP 规定,CS ID 的 0,1,2 为保留字,你在设置 CS ID 的时候只能从 3 开始。
CS ID: 0 ==> 整个 BH 长为 2B,其中可以表示的 Stream ID 数量为 64-319。例如:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fmt| 0 | cs id - 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注意上面的 cs id - 64。这个代表的就是,你通过切割第二个 byte 时,是将得到的值加上 64。即:2th byte + 64 = CS ID
CS ID: 1 ==> 整个 BH 长为 3B。可以存储的 Stream ID 数量为 64-65599。例如:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fmt| 1 | cs id - 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
当然,后面 CS ID 的计算方法也是最后的结果加上 64。
CS ID >2 ==> 整个 BH 长为 1B。可以存储的 Stream ID 数量为 3-63。例如:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|fmt| cs id |
+-+-+-+-+-+-+-+-+
最后强调一下,因为 RTMP 规定,CS ID 的 0,1,2 为保留字,所以,0,1,2 不作为 CS ID。综上所述,CS ID 的起始位为 3(并不代表它是 3 个 Stream)。
上面我并没有提到 fmt 字段,这其实是用来定义 Message Header 的。
Message Header
根据前面 BH 中 fmt 字段的定义,可以分为 4 种 MH(Message Header)。或者说,就是一种 MH 格式会存在从繁到简 4 种:
fmt: 0
当 fmt 为 0 时,MH 的长度为 11B。该类型的 MH 必须要流的开头部分,这包括当进行快退或者点播时重新获取的流。该结构的整体格式如下:

也就是说,当 fmt 为 0 时,其格式是一个完整的 MH。
timestamp 是绝对时间戳。用来代表当前流编码。
message length: 3B, 发送 message 的长度。
type id: 1B
stream id: 4B, 发送 message stream id 的值。是 little-endian 写入格式!
fmt: 1
当 fmt 为 1 时,MH 的长度为 7B。该类型的 MH 不带 msg stream id。msg stream id 由前面一个 package 决定。该数值主要由前一个 fmt 为 0 的 MH 决定。该类型的 MH 通常放在 fmt 为 0 之后。

fmt: 2
当 fmt 为 2 时,MH 的长度为 3B。该类型的 MH 只包括一个 timestamp delta 字段。其它的信息都是依照前面一个其他类型 MH 决定的。
fmt: 3
当 fmt 为 3时,这其实 RTMP 里面就没有了 MH。官方定义,该类型主要全部都是 payload 的 chunk,其 Header 信息和第一个非 type:3 的头一致。因为这主要用于 chunk 中,这些 chunk 都是从一个包里面切割出来的,所以除了第一个 chunk 外,其它的 chunk 都可以采用这种格式。当 fmt 为 3时,计算它的 timestamp 需要注意几点,如果前面一个 chunk 里面存在 timestrameDelta,那么计算 fmt 为 3 的 chunk 时,就直接相加,如果没有,则是使用前一个 chunk 的 timestamp 来进行相加,用代码表示为:
prevChunk.timeStamp += prevChunk.timeStampDelta || prevChunk.timeStamp;
不过,当 fmt: 3 的情况一般很难遇到。因为,他要求前面几个包必须存在 fmt 为 0/1/2 的情况。
接下来的就是 Message Body 部分。
Message Body
上面说的主要是 Message Header 的公用部分,但是,对于具体的 RTMP Message 来说,里面的 type 会针对不同的业务场景有不同的格式。Message 全部内容如上图所示:

这里,我们根据流程图的一级子 item 来展开讲解。
PCM
PCM 全称为:Protocol Control Messages(协议控制消息)。主要使用来沟通 RTMP 初始状态的相关连接信息,比如,windows size,chunk size 等。
PCM 中一共有 5 种不同的 Message 类型,是根据 Header 中的 type ID 决定的,范围是 1~6 (不包括 4)。另外,PCM 在构造的时候需要注意,它 Heaer 中的 message stream id 和 chunk stream id 需要设置为固定值:
message stream ID 为 0
chunk stream ID 为 2
如图所示:

OK,我们接下来一个一个来介绍一下:
Set Chunk Size(1)
看名字大家应该都能猜到这类信息是用来干啥的。该类型的 PCM 就是用来设置 server 和 client 之间正式传输信息的 chunk 的大小,type ID 为 1。那这有啥用呢?
SCS(Set Chunk Size) 是针对正式发送数据而进行数据大小的发送限制。一般默认为 128B。不过,如果 server 觉得太小了,想发送更大的包给你,比如 132B,那么 server 就需要给你发送一个 SCS,告知你,接下来“我发送给你的数据大小是 132B”。

0: 只能设为 0 ,用来表示当前的 PCM 的类型。
chunk size: 用来表示后面发送正式数据时的大小。范围为 1-16777215。
如下,提供过 wireshark 抓包的结果:

Abort Message(2)
该类 PCM 是用来告诉 client,丢弃指定的 stream 中,已经加载到一半或者还未加载完成的 Chunk Message。它需要指定一个 chunk stream ID。
基本格式为:

chunk stream id: 指定丢弃 chunk message 的 stream
Acknowledgement(3)
该协议信息其实就是一个 ACK 包,在实际使用是并没有用到,它主要是用来作为一个 ACK 包,来表示两次 ACK 间,接收端所能接收的最大字节数。
它基本格式为:

sequence number[4B]: 大小为 4B
不过,该包在实际应用中,没有多高的出现频率。
Window Acknowledgement Size(5)
这是用来协商发送包的大小的。这个和上面的 chunk size 不同,这里主要针对的是客户端可接受的最大数据包的值,而 chunk size 是指每次发送的包的大小。也可以叫做 window size。一般电脑设置的大小都是 500000B。
详细格式为:

通过,wireshark 抓包的结果为:

Set Peer Bandwidth(6)
这是 PCM 中,最后一个包。他做的工作主要是根据网速来改变发送包的大小。它的格式和 WAS 类似,不过后面带上了一个 Type 用来标明当前带宽限制算法。当一方接收到该信息后,如果设置的 window size 和前面的 WAS 不一致,需要返回一个 WAS 来进行显示改变。
基本格式为:

其中 Limit Type 有 3 个取值:
0: Hard,表示当前带宽需要和当前设置的 window size 匹配
1: Soft,将当前宽带设置为该信息定义的 window size,或者已经生效的 window size。主要取决于谁的 window size 更小
2: Dynamic,如果前一个 Limit Type 为 Hard 那么,继续使用 Hard 为基准,否则忽略该次协议信息。
实际抓包情况可以参考:

UCM
全称为:User Control Message(用户控制信息)。它的 Type ID 只能为 4。它主要是发送一些对视频的控制信息。其发送的条件也有一定的限制:
msg stream ID 为 0
chunk stream ID 为 2
它的 Body 部分的基本格式为:

UCM 根据 Event Type 的不同,对流进行不同的设置。它的 Event Type 一共有 6 种格式 Stream Begin(0),Stream EOF(1),StreamDry(2),SetBuffer Length(3),StreamIs Recorded(4),PingRequest(6),PingResponse(7)。
这里,根据重要性划分,只介绍 Begin,EOF,SetBuffer Length 这 3 种。
Stream Begin: Event Type 为 0。它常常出现在,当客户端和服务端成功 connect 后发送。Event Data 为 4B,内容是已经可以正式用来传输数据的 Stream ID(实际没啥用)。

Stream EOF: Event Type 为 1。它常常出现在,当音视频流已经全部传输完时。 Event Data 为 4B,用来表示已经发送完音视频流的 Stream ID(实际没啥用)。
Set Buffer Length: Event Type 为 3。它主要是为了通知服务端,每毫秒用来接收流中 Buffer 的大小。Event Data 的前 4B 表示 stream ID,后面 4B 表示每毫秒 Buffer 的大小。通常为 3000ms
OK 剩下就是 Command Msg 里面的内容了。
Command Msg
Command Msg 里面的内容,其 type id 涵盖了 8~22 之间的值。具体内容,可以参考下表:

需要注意,为什么有些选项里面有两个 id,这主要和 AMF 版本选择有关。第一个 ID 表示 AMF0 的编解码方式,第二个 ID 表示 AMF3 的编解码方式。 其中比较重要的是 command Msg,video,audio 这 3 个 Msg。为了让大家更好的理解 RTMP 流的解析,这里,先讲解一下 video 和 audio 两个 Msg。
Video Msg
因为 RTMP 是 Adobe 开发的。理所当然,内部的使用格式肯定是 FLV 格式。不过,这和没说一样。因为,FLV 格式内部有很多的 tag 和相关的描述信息。那么,RTMP 是怎么解决的呢?是直接传一整个 FLV 文件,还自定义协议来分段传输 FLV Tag 呢?
这个其实很好回答,因为 RTMP 协议是一个长连接,如果是传整个 FLV 文件,根本没必要用到这个,而且,RTMP 最常用在直播当中。直播中的视频都是分段播放的。综上所述,RTMP 是根据自己的自定义协议来分段传输 FLV Tag 的。那具体的协议是啥呢?
这个在 RTMP 官方文档中其实也没有给出。它只是告诉我们 Video Msg 的 type ID 是 9 而已。
因为,RTMP 只是一个传输工具,里面传什么还是由具体的流生成框架来决定的。所以,这里,我选择了一个非常具有代表性的 RTMP 直播流来进行讲解。
通过 wireshark 抓包,可以捕获到以下的 RTMP 包数据:

这里需要提及一点,因为 RTMP 是主动将 Video 和 Audio 分开传输,所以,它需要交叉发布 Video 和 Audio,以保证音视频的同步。那么具体每个 Video Data 里面的数据都是一样的吗?
如果看 Tag 的话,他们传输的都是 VideoData Tag。先看一下 FLV VideoData Tag 的内容:

这是 FLV Video 的协议格式。但,遇到第一个字段 FrameType 的时候,我们就可能懵逼了,这 TM 有 5 种情况,难道 RTMP 会给你 5 种不同的包吗?
答案是,有可能,但是,很大情况下,我们只需要支持 1/2 即可。因为,视频中最重要的是 I 帧,它对应的 FrameType 就是 1。而 B/P 则是剩下的 2。我们只要针对 1/2 进行软解,即可实现视频所有信息的获取。
所以,在 RTMP 中,也主要(或者大部分)都是传输上面两种 FrameType。我们通过实际抓包来讲解一下。
这是 KeyFrame 的包,注意 Buffer 开头的 17 数字。大家可以找到上面的 FrameType 对应找一找,看结果是不是一致的:

这是 Inter-frame 的包。同上,大家也可以对比一下:

Audio Tag
Aduio Tag 也是和 Video Tag 一样的蜜汁数据。通过观察 FLV Audio Tag 的内容:

上面这些字段全是相关的配置值,换句话说,你必须实现知道这些值才行。这里,RTMP 发送 Audio Tag 和 Video Tag 有点不同。因为 Audio Tag 已经不可能再细分为 Config Tag,所以,RTMP 会直接传递 上面的 audio Tag 内容。详细可以参考抓包内容:

这也是所有的 Audio Msg 的内容。
因为 Audio 和 Video 是分开发送的。所以,在后期进行拼接的时候,需要注意两者的同步。说道这里,顺便补充一下,音视频同步的相关知识点。
音视频同步
音视频同步简单来说有三种:
以 Audio 为准,Video 同步 Audio
以 Video 为准,Audio 同步 Video
以外部时间戳为准,AV 同时同步
主要过程变量参考就是 timeStamp 和 duration。因为,这里主要是做直播的,推荐大家采用第二种方法,以 Video 为准。因为,在实际开发中,会遇到 MP4 文件生成时,必须要求第一帧为 keyframe,这就造成了,以 Audio 为参考的,会遇到两个变量的问题。一个是 timeStamp 一个是 keyframe。当然,解决办法也是有的,就是检查最后一个拼接的 Buffer 是不是 Keyframe,然后判断是否移到下一次同步处理。
这里,我简单的说一下,以 Video 为准的同步方法。以 Video 同步,不需要管第一帧是不是 keyframe,也不需要关心 Audio 里面的数据,因为,Audio 数据是非常简单的 AAC 数据。下面我们通过伪代码来说明一下:
// known condition
video.timeStamp && video.perDuration && video.wholeDuration
audio.timeStamp && audio.perDuration

// start
refDuration = video.timeStamp + video.wholeDuration
delta = refDuration - audio.timeStamp
audioCount = Math.round(delta/audio.perDuration);
audDemuxArr = this._tmpArr.splice(0,audioCount);

// begin to demux
this._remuxVideo(vidDemuxArr);
this._remuxAudio(audDemuxArr);
上面算法可以避免判断 Aduio 和 Video timeStamp 的比较,保证 Video 一直在 Audio 前面并相差不远。下面,我们回到 RTMP 内容。来看看 Command Msg 里面的内容。
Command Msg
Command Msg 是 RTMP 里面的一个主要信息传递工具。常常用在 RTMP 前期和后期处理。Command Msg 是通过 AMF 的格式进行传输的(其实就是类似 JSON 的二进制编码规则)。Command Msg 主要分为 net connect 和 net stream 两大块。它的交流方式是双向的,即,你发送一次 net connect 或者 stream 之后,另外一端都必须返回一个 _result 或者 _error 以表示收到信息。详细结构可以参考下图:

后续,我们分为两块进行讲解:
netConnection
netStream
里面的 _result 和 _error 会穿插在每个包中进行讲解。
NetConnection
netConnection 可以分为 4 种 Msg,connect,call,createStream,close。
connect
connect 是客户端向 Server 端发送播放请求的。里面的字段内容有:
Command Name[String]: 默认为 connect。表示信息名称
Transaction ID[Number]: 默认为 1。
Command Object: 键值对的形式存放相关信息。
Optional: 可选值。一般没有
那,Command Object 里面又可以存放些什么内容呢?
app[String]: 服务端连接应用的名字。这个主要根据你的 RTMP 服务器设定来设置。比如:live。
flashver[String]: Flash Player 的版本号。一般根据自己设备上的型号来确定即可。也可以设置为默认值:LNX 9,0,124,2。
tcUrl[String]: 服务端的 URL 地址。简单来说,就是 protocol://host/path。比如:rtmp://6521.liveplay.myqcloud.com/live。
fpad[Boolean]: 表示是否使用代理。一般为 false。
audioCodecs[Number]: 客户端支持的音频解码。后续会介绍。默认可以设置为 4071
videoCodecs[Number]: 客户端支持的视频解码。有自定义的标准。默认可以设置为 252
videoFunction[Number]: 表明在服务端上调用那种特别的视频函数。默认可以设置为 1
简单来说,Command Object 就是起到 RTMP Route 的作用。用来请求特定的资源路径。实际数据,可以参考抓包结果:

上面具体的取值主要是根据 rtmp 官方文档来决定。如果懒得查,可以直接使用上面的取值。上面的内容是兼容性比较高的值。当该包成功发送时,另外一端需要得到一个返回包来响应,具体格式为:
Command Name[String]: 为 _result 或者 _error。
Transaction ID[Number]: 默认为 1。
Command Object: 键值对的形式存放相关信息。
Information[Object]: 键值对的形式,来描述相关的 response 信息。里面存在的字段有:level,code,description
可以参考:

connect 包发送的位置,主要是在 RTMP 握手结束之后。如下:

call
call 包主要作用是用来远程执行接收端的程序(RPC, remote procedure calls)。不过,在我解 RTMP 的过程中,并没有实际用到过。这里简单介绍一下格式。它的内容和 connect 类似:
Procedure Name[String]: 调用处理程序的名字。
Transaction ID[Number]: 如果想要有返回,则我们需要制定一个 id。否则为 0。
Command Object: 键值对的形式存放相关信息。AMF0/3
Optional: 可选值。一般没有
Command Object 里面的内容主要是针对程序,设置相关的调用参数。因为内容不固定,这里就不介绍了。
call 一般是需要有 response 来表明,远端程序是否执行,以及是否执行成功等。返回的格式为:
Command Name[String]: 根据 call 中 Command Object 参数来决定的。
Transaction ID[Number]: 如果想要有返回,则我们需要制定一个 id。否则为 0。
Command Object: 键值对的形式存放相关信息。AMF0/3
Response[Object]: 响应的结果值
createStream
createStream 包只是用来告诉服务端,我们现在要创建一个 channel 开始进行流的交流了。格式和内容都不复杂:
Procedure Name[String]: 调用处理程序的名字。
Transaction ID[Number]: 自己制定一个。一般可以设为 2
Command Object: 键值对的形式存放相关信息。AMF0/3
当成功后,服务端会返回一个 _result 或者 _error 包来说明接收成功,详细内容为:
Command Name[String]: 根据 call 中 Command Object 参数来决定的。
Transaction ID[Number]: 如果想要有返回,则我们需要制定一个 id。否则为 0。
Command Object: 键值对的形式存放相关信息。AMF0/3。一般为 Null
Stream ID: 返回的 stream ID 值。
它的返回值很随意,参考抓包内容:

下面,我们来看一下 RTMP 中第二个比较重要的 command msg – netStream msg。
NetStream Msg
NetStream 里面的 Msg 有很多,但在直播流中,比较重要的只有 play 包。所以,这里我们着重介绍一下 play 包。
play
play 包主要是用来告诉 Server 正式播放音视频流。而且,由于 RTMP 天然是做多流分发的。如果遇到网络出现相应的波动,客户端可以根据网络条件多次调用 play 命令,来切换不同模式的流。
其基本格式为:
Command Name[String]: 根据 call 中 Command Object 参数来决定的。
Transaction ID[Number]: 默认为 0。也可以设置为其他值
Command Object: 不需要该字段,在该命令中,默认设为 Null
Stream Name[String]: 用来指定播放的视频流文件。因为,RTMP 天生是支持 FLV 的,所以针对 FLV 文件来说,并不需要加额外的标识,只需要写明文件名即可。比如:
StreamName: '6721_75994f92ce868a0cd3cc84600a97f75c'
不过,如果想要支持其它的文件,那么则需要额外的表示。当然,音频和视频需要不同的支持:
如果是播放音频文件,比如 mp3,那么则需要额外的前缀标识符-mp3。例如:mp3:6721_75994f9。
如果涉及到视频文件的话,不仅需要前缀,还需要后缀。比如播放的是 MP4 文件,则标识为:mp4:6721_75994f9.mp4。

startNumber: 这个字段其实有点意思。它可以分为 3 类来讲解:-2,-1,>=0。
-2: 如果是该标识符,服务端会首先寻找是否有对应的 liveStream。没有的话,就找 record_stream。如果还没有的,这次请求会暂时挂起,直到获取到下一次 live_stream。
-1: 只有 live_stream 才会播放。
=0: 相当于就是 seek video。它会直接找到 record_stream,并且根据该字段的值来确定播放开始时间。如果没有的话,则播放 list 中的下一个 video。

durationNumber: 用来设置播放时长的。它里面也有几个参数需要讲解一下,-1,0,>0。
-1: 会一直播放到 live_stream 或者 record_stream 结束。
0: 会播放一段一段的 frame。一般不用。
0: 会直接播放指定 duration 之内的流。如果超出,则会播放指定时间段内容的 record_stream。

reset[Boolean]: 该字段没啥用,一般可以忽略。用来表示否是抛弃掉前面的 playlist。
整个 play 包内容就已经介绍完了。我们可以看看实际的 play 抓包结果:

那 play 包是在那个环节发送,发送完之后需不需要对应的 _result 包呢?
play 包比较特殊,它是不需要 _result 回包的。因为,一旦 play 包成功接收后。server 端会直接开始进行 streamBegin 的操作。
整个流程为:

到这里,后续就可以开始正式接收 video 和 audio 的 stream。
转载自https://www.villianhr.com/201... H5 直播流技术解析

想要阅读更多技术干货文章,欢迎关注网易云信博客。
了解网易云信,来自网易核心架构的通信与视频云服务。

网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

查看原文: 视频技术详解:RTMP H5 直播流技术解析

  • bigleopard
  • beautifulduck