rtmp实现音频频点播之服务篇

来源：互联网发布：sql 日志回滚编辑：程序博客网时间：2024/06/05 00:15

1 握手

adobe修改了握手部分的协议，但是没有公开。根据rtmp specification 1.0里面的握手过程，flash player是播不了h264编码的视频。修正后的握手协议可以参照:http://blog.csdn.net/winlinvip/article/details/7714493

2 rtmp 包格式

rtmp 使用块（chunk)的概念来发送数据，默认的块大小是128（不包括头部数据大小），如果要发送的数据超过了设定的块大小，就要分为多块进行发送。rtmp chunk的总体格式如下所示，rtmp chunk头部信息包括三部分：基本头，消息头，扩展时间戳。

+----------------+--------------------+-------------------------+----------------+
| Basic Header | Message Header | Extended Timestamp | Chunk Data |
+----------------+--------------------+-------------------------+----------------+
| |
|<------------------- Chunk Header ------------------------->|

2.1 rtmp chunk basic header

rtmp 块的基本头包手两个信息：块格式（chunk format) 和块流ID（chuck stream id)

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| fmt | cs id |
+-+-+-+-+-+-+-+-+

fmt: rtmp块头的格式，有4种类型

cs_id:

cs_id块流ID基本头的长度（字节）>=2cs_id10【第二字节的值】 + 6421【第三字节的值】*256+【第二字节的值】+643

2.2 rtmp message header

rtmp 消息头一般包括：时间戳（3Bytes），消息长度（3Bytes)，消息类型（1Byte），消息流Id（4Bytes）。

但是并不总是会包含这些信息。但是可以根据块基本头的fmt,来判断消息头中包含了哪些信息（如表格所示）。

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 length (cont) | message type id | msg stream id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           message stream id (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

fmttimestampmessage lengthmessage type idmsg stream id消息头长度0YYYY111YYYx72Yxxx33xxxx0

注意：a.发包的原则是同一个块流ID,第一个包一般使用fmt0,然后再根据情况选择使用fmt1,fmt2,fmt3.

b.timestamp,只有当是fmt0时，才表示一个绝对时间戳，其它格式都是一个时间差值，即相对于上一个包的时间增量。

c.对于fmt1,fmt2,fmt3;缺失的信息，使用最近收到的的同一个块流id的fmt0格式的包。

d.所以有信息使用大端编码，除了消息流id是使用小端编码。

2.3 extended timestamp

扩展时间戳，4字节，当timestamp > 0xffffff,使用扩展时间戳，否则不使用

2.4 example

a. 发送alaw音频包，编码器的打包大小为320字节，时间间隔为40ms,假设块大小设定为1000，几个音频包的时间戳依次为1000、1040、1080、1120.....，则可能的发送格式如下所示:

rtmp packetformattimestampmessage lengthpacket size#1fmt01000320320+1+11#2fmt240x320+1+3#3fmt3xx320+1#4fmt3xx320+1
注：上例我们也可以每个包都用fmt0来发送，这样的话，每个包都要指定准确的时间戳和长度。

b. 发送视频包，时间间隔为40ms,假设块大小设定为1000，几个视频包的时间戳依次为1000、1040.....，大小依次为2500，1600，....则可能的发送格式如下所示:

rtmp packetformattimestampmessage lengthpacket size#1fmt0100025001000+1+11#2fmt3xx1000+1#3fmt3xx500+1#4fmt0104015001000+1+11#5fmt3xx600+1

注：上例中如果每帧的视频间隔是相等，第二帧的第一个包（#4），我们也可以用fmt1来发送，将消息头中的timestamp指定为时间差。并指定帧长。

3 rtmp control message

rtmp中各类消息的区分是通过消息头中的消息类型id(message type id）来区分。控制消息（control message)包括设置块大小（1），中止消息（2），应答消息（3），设定窗口应答大小（5），设置对方带宽（6），用户控制消息（4）。

控制消息发送时，消息流id（message stream id)必须为0，块Id必须为2.

3.1 set chunk size（消息类型：1）

设置块大小，默认块大小为128字节。直接在包头部后面跟4字节的要设定的块大小。

3.2 abort message（消息类型：2）

用于中止消息。接在包头部后面跟4字节的要中止的块流大小。

3.3 Acknowledge（消息类型：3）

应答消息，用于接收端（flash player）报告，总共接收到的字节数。直接在包头部后面跟4字节的收到的字节数。

3.4 window acknowledgement size（消息类型：5）

指定应答的间隔，即距离上一次应答后收到的字节数。

3. 5 set peer bandwidth（消息类型：6）

用于限定对方发送带宽

4 rtmp command message (命令消息）

命令消息包括音频消息（8），视频消息（9），集成控制（22），共享对象消息（19【amf0】，16【amf3】），数据消息（18【amf0】，15【amf3】），命令（远程调用）消息（20【amf0】，17【amf3】）。以后会针对性讲解三类主要的消息（远程调用，音频，视频消息）。

4.1 command message (命令/远程调用消息）

远程调用消息，这类消息在我看来就是flash player的一个远程方法调用。故称之为远程调用消息。flash 的实现的两个基本类:NetConnection和NetStream，分别负责创建连接和进行网络流的点播控制。远程调用消息主要是这两个类的公有方法在服务端的远程调用。这两个类的具体介绍参见adobe的官网。其中有详细的介绍有哪些公有方法，以及相关的参数和可能的返回值。所有的参数和返回值都是通过AMF0或AMF3来表示。

http://livedocs.adobe.com/flash/9.0_cn/ActionScriptLangRefV3/flash/net/NetConnection.html

http://livedocs.adobe.com/flash/9.0_cn/ActionScriptLangRefV3/flash/net/NetStream.html

4.1.1 NetConnection.connect

连接请求：

返回连接失败：

连接可用的返回值如下表所示，详见:http://livedocs.adobe.com/flash/9.0_cn/ActionScriptLangRefV3/flash/events/NetStatusEvent.html#info

"NetConnection.Connect.Failed""error"连接尝试失败。"NetConnection.Connect.Success""status"连接尝试成功。"NetConnection.Connect.Rejected""error"连接尝试没有访问应用程序的权限。"NetConnection.Connect.InvalidApp""error"连接时指定的应用程序名无效。

4.1.2 NetConnection.close (略）

4.1.3 NetStream.receiveVideo

告知对方是否需要视频数据。由boolean类型的参数指定是否需要视频数据。该命令无需返回（应答）。

4.1.4 NetStream.receiveAudio

告知对方是否需要音频数据。由boolean类型的参数指定是否需要音频数据。该命令无需返回（应答）。格式类似NetStream.receiveVideo。

4.1.5 NetStream.play

告知对方需要点播的文件。请求格式见下图：

返回消息：

可用的返回值见下表：

"NetStream.Play.Start""status"播放已开始。"NetStream.Play.Failed""error"出于此表中列出的原因之外的某一原因（例如订阅者没有读取权限），播放发生了错误。"NetStream.Play.StreamNotFound""error"无法找到传递给 play() 方法的 FLV。"NetStream.Play.Reset""status"由播放列表重置导致。"NetStream.Play.InsufficientBW""warning"仅限 Flash Media Server。客户端没有足够的带宽，无法以正常速度播放数据。

在正式播放之前，必须发送stream begin（event type为0）的用户控制消息告知flash player为播放做好准备。

4.2 Video message

视频消息，消息id为9。h264基本的封装格式如下所示（关于flv的格式详见adobe flash video file format specification version 10.1）：

如果nalu的大小超出了设定的chunk大小，就要进行分块发送。分块的方式见2.4例子

4.3 Audio message

音频消息，消息id为8。基本的封装格式如下所示（关于flv的格式详见adobe flash video file format specification version 10.1）：

| rtmp header | FLV audio tag header | audio data |

4.4 User control message

用户控制消息。可用的用户控制事件包括：stream begin(0),stream EOF(1),stream dry(2),SetBufferLength(3),StreamIsRecorded(4),PingRequest(6),PingResponse(7)

5. 基本的服务端播放流程：

基本的播放流程：收到连接请求-》应答连接成功-》收到播放请求-》检测点播的流是否存在-》发送stream begin消息-》发送paly.start消息—-》连续发送音视数据-》。。。-》直接收到关闭连接请求或播放到文件末尾。

【client】 | | 【server】

|-----------1: connect------------------------------------------------>|

|<-----2: NetConnection.Connect.Success ------------|

|---------3: play------------------------------------------------------->|

|<-------4: stream begin -------------------------------------------|

|<-------5: NetStream.Play.Start---------------------------|

|<-------6: SetChunksize-------------------------------------------|

|<--------------video message-------------------------------------|

|<-------------audio message-------------------------------------|

| ... |