rtmp实现音频频点播之服务篇
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 基本头的长度（字节） >=2 cs_id 1 0 【第二字节的值】 + 64 2 1 【第三字节的值】*256+【第二字节的值】+64 3
2.2 rtmp message header
rtmp 消息头一般包括：时间戳（3Bytes），消息长度（3Bytes)，消息类型（1Byte），消息流Id（4Bytes）。
但是并不总是会包含这些信息。但是可以根据块基本头的fmt,来判断消息头中包含了哪些信息（如表格所示）。
0 1 2 30 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) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
fmt timestamp message length message type id msg stream id 消息头长度 0 Y
Y
Y
Y
11 1 Y
Y
Y
x
7 2 Y
x
x
x
3 3 x
x
x
x
0
注意：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 packet format timestamp message length packet size #1 fmt0 1000 320 320+1+11 #2 fmt2 40 x 320+1+3 #3 fmt3 x x 320+1 #4 fmt3 x x 320+1 注：上例我们也可以每个包都用fmt0来发送，这样的话，每个包都要指定准确的时间戳和长度。
b. 发送视频包，时间间隔为40ms,假设块大小设定为1000，几个视频包的时间戳依次为1000、1040.....，大小依次为2500，1600，....则可能的发送格式如下所示:
rtmp packet format timestamp message length packet size #1 fmt0 1000 2500 1000+1+11 #2 fmt3 x x 1000+1 #3 fmt3 x x 500+1 #4 fmt0 1040 1500 1000+1+11 #5 fmt3 x x 600+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）：
| rtmp header | FLV video tag header | nalu size | nalu data(不包含start code) |
如果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-------------------------------------|
| ... |