本人从事视频编解码研发工作达10年之久，一直使用FFMPEG，directdraw，D3D,SDL进行视频软件开发。P2P设计及开发。希望有需要开发的联系我：电话：13764413903。QQ：1049568282。
附：本人有流媒体服务器方案，各种文件格式相互转化方案，自动更新软件，视频编解库（ffmpeg,directdraw）可转让
Real Time Messaging Protocol（实时消息传送协议协议)是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。
具体使用RTMP的AS代码大概如下：
var videoInstance:Video = your_video_instance;
var nc:NetConnection = new NetConnection();
var connected:Boolean = nc.connect("rtmp://localhost/myapp");
var ns:NetStream = new NetStream(nc);
videoInstance.attachVideo(ns);
ns.play("flvName");
Adobe也在官方网站已经提供了RTMP协议的官方文档说明，为什么要写这个系列文章最大的原因只是对前一段工作的一个总结和回顾，最近两个月，实现了一个RTMP Server的c++版本，把公司的流媒体服务和flash无缝对接起来。希望我的文字能给后来研究这个协议的同学有一定的帮助。
RTMP协议是一个基于TCP的高层协议族，当然这个玩意据说还有UDP协议版本的，不过现在还没有出来，好像Adobe下一版本的FMS会提供支持。下文将要描述的是TCP协议版本的协议。
RTMP协议的概要理解：
RTMP协议是为了和flash之间交换信令以及媒体数据。为了提高使用效率信令和媒体数据都是使用相同的机制。因为是相同的机制Adobe就整出来了一些比较搞人的概念，当然每个协议第一次接触都是比较难理解的。
在RTMP协议中信令和媒体数据都称之为Message，在网络中传输这些Message，为了区分它们肯定是要加一个Message head的，所以RTMP协议也有一个Message head，还有一个问题因为RTMP协议是基于TCP的，由于TCP的包长度是有限制的（一般来说不超过1500个字节），而RTMP的Message长度是有可能很大的，像一个视频帧的包可能会有几十甚至几千K，这个问题就必然有一个分片的问题，在RTMP协议中对应的说法就是chunk，每一个Message + head都是由一个和多个chunk组成的。到这里对RTMP协议的概要理解就算完了。
RTMP的字节序：
RTMP的字节序和大多数网络协议一样是大端序，也有一些字段是小端序的，不过都有特殊的说明。
RTMP的head组成
RTMP的head在协议中的表现形式是chunk head，前面已经说到一个Message + head可以分成一个和多个chunk，为了区分这些chunk，肯定是需要一个chunk head的，具体的实现就把Message head的信息和chunk head的信息合并在一起以chunk head的形式表现。
一个完整的chunk的组成如下图所示
![RTMP <wbr> <wbr>封包详解]( "RTMP <wbr> <wbr>封包详解")
Chunk basic header：
该字段包含chunk的stream ID和 type 。chunk的Type决定了消息头的编码方式。该字段的长度完全依赖于stream ID，该字段是一个可变长的字段。
Chunk Msg Header：0, 3 ,7, 11
该字段包含了将要发送的消息的信息（或者是一部分，一个消息拆成多个chunk的情况下是一部分）该字段的长度由chunk basic header中的type决定。
Extend Timestamp： 0 ,4 bytes
该字段发送的时候必须是正常的时间戳设置成0xffffff时，当正常时间戳不为0xffffff时，该字段不发送。当时间戳比0xffffff小该字段不发送，当时间戳比0xffffff大时该字段必须发送，且正常时间戳设置成0xffffff。
Chunk Data
实际数据（Payload），可以是信令，也可以是媒体数据。
Chunk basic header：
chunk basic head的长度为1~3个字节，具体长度主要是依赖chunk stream ID的长度，所谓chunk stream ID是flash server用来管理连接的客户端的信令交互的标识，在red5的文档中称之为channel ID，协议最大支持65597个streamID 从3~65599。ID 0，1，2为协议保留，0代表ID是64~319（第二个byte + 64）；1代表chunk stream ID为64~65599（（第三个byte）* 256 + 第二个byte + 64）（小端表示）；2代表该消息为低层的协议（在RTMP协议中控制信令的chunk stream ID都是2）。3~63的chunk stream ID就是该byte的值。没有附加的字段来标识chunk stream streamID。在这里要指出的是虽然RTMP的chunk stream ID理论是可以达到65599，但是目前使用的chunk stream ID很少，2~7都是约定的，8是用来传输publish play等命令，其他的chunk stream ID目前好像没有使用，至少我不知道用来干嘛的。
所以目前chunk basic head的长度一般为1个字节。这一个字节由两部分组成
+++++++++++++++++++
+fmt + cs id +
+++++++++++++++++++
fmt占两个bit用来标识紧跟其后的chunk Msg Header的长度，cs id占六个bit。
两位的fmt取值为 0~3，分别代表的意义如下：
case 0：chunk Msg Header长度为11；
case 1：chunk Msg Header长度为7；
case 2：chunk Msg Header长度为3；
case 3：chunk Msg Header长度为0；
所以 只有一个字节的chunk basic header取值为 chunk basic header = (fmt << 6) | (cs id).
Chunk Msg Header：
Chunk Msg Header的长度是可变的，Chunk Msg Header可变的原因是为了压缩传输的字节数，把一些相同类型的chunk的head去掉一些字节，换句话说就是四种类型的包头都可以通过一定的规则还原成11个字节，这个压缩和还原在RTMP协议中称之为复用/解复用。
那我们以11个字节的完整包头来解释Chunk Msg Header，如图所示
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ timestamp + message length + message type id + message stream id +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Timestamp：3bytes
对于type 0的chunk，绝对时间戳在这里表示，如果时间戳值大于等于0xffffff（16777215），该值必须是0xffffff,且时间戳扩展字段必须发送，其他情况没有要求。
message length：3bytes
Message的长度，注意这里的长度并不是跟随chunk head其后的chunk data（Payload）的长度，而是前文提到的一条信令或者一帧视频数据或音频数据的长度。前文提到过信令或者媒体数据都称之为Message，一条Message可以分为一条或者多条chunk。
message type id：1byte
Message的类型ID，具体的值将在后文专门来讨论。
message stream id：4bytes
message stream id的字节序是小端序，这个字段是为了解复用而设计的，RTMP文档上说的相当的模糊，
message stream ID可以使任意值，不同的消息流复用成相同的chunk stream，基于它们的ID能够解复用。于chunk stream 是相关的，这个字段是一个不透明的值没有整明白什么意思，我的理解就是用来标识和服务器连接的flash端的序号。
长度是7 bytes 的chunk head，该类型不包含stream ID，该chunk的streamID和前一个chunk的stream ID是相同的，变长的消息，例如视频流格式，在第一个新的chunk以后使用这种类型，注意其中时间戳部分是相对时间，为何上一个绝对时间之间的差值 如图所示：
++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ timestamp delta + message length + message type id +
++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 bytes的chunk head，该类型既不包含stream ID 也不包含消息长度，这种类型用于stream ID和前一个chunk相同，且有固定长度的信息，例如音频流格式，在第一个新的chunk以后使用该类型。如图所示：
++++++++++++++++++++
+ timestamp delta +
++++++++++++++++++++
0 bytes的chunk head，这种类型的chunk从前一个chunk得到值信息，当一个单个消息拆成多个chunk时，这些chunk除了第一个以外，其他的都应该使用这种类型，
chunk的长度：
chunk的长度初始长度固定为128个字节，但是这个值并不是不可变的，在客户端和服务端建立连接以后，客户端和服务端都可以通过发送信令的方式来通知对端修改chunk的长度，理论上来说可以修改chunk的最长长度为65536。这里chunk的长度是指chunk的数据部分的长度，即chunk data（payload）的长度，如果一条Message的数据长度超过了chunk的长度，就必须把Message分割成多条chunk，即如果一条视频类型Message长度为2000个byte，chunk长度为1500，则该Message将会分割成两条chunk，第一条的chunk data长度为1500，第二条的chunk data长度为500。当然这两条chunk的chunk head肯定是不同的，其中第二条chunk的chunk head就是0字节的。
RTMP协议封包 参考Red5
RTMP协议封包 由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推 。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节.
完整的12字节RTMP包头每个字节的含义:
用途 大小(Byte) 含义
Head_Type 1 包头
TiMMER 3 时间戳
AMFSize 3 数据大小
AMFType 1 数据类型
StreamID 4 流ID
一、Head_Type
第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算:
Head_Type的前两个Bit和长度对应关系：
Bits Header Length
00 12 bytes
01 8 bytes
10 4 bytes
11 1 byte
Head_Type的后面6个Bit和StreamID决定了ChannelID。 StreamID和ChannelID对应关系：StreamID=(ChannelID-4)/5+1 参考red5
ChannelID Use
02 Ping 和ByteRead通道
03 Invoke通道 我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的
04 Audio和Vidio通道
05 06 07 服务器保留,经观察FMS2用这些Channel也用来发送音频或视频数据
例如在rtmp包里面经常看到的0xC2, 就表示一字节的包头,channel=2.
二、TiMMER
TiMMER占3个字节纪录的是时间戳,音视频流的时间戳是统一排的。可分为绝对时间戳和相对时间戳。
fms对于同一个流，发布的时间戳接受的时间戳是有区别的
publish时间戳,采用相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个媒体包的绝对时间戳之间的差距，也就是说音视频时间戳在一个时间轴上面.单位毫秒。
play时间戳，相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包的绝对时间戳之间的差距, 也就是说音视频时间戳分别为单独的时间轴，单位毫秒。
flv格式文件时间戳，绝对时间戳，时间戳长度3个字节。超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。
flv格式文件影片总时间长度保存在onMetaData的duration属性里面，长度为8个字节，是一个翻转的double类型。
三、AMFSize
AMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。如果超过了128字节，那么由多个后续RTMP封包组合，每个后续RTMP封包的头只占一个字节。一般就是以0xC？开头。
四、AMFType
AMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。
AMFType是包的类型
0×01 Chunk Size changes the chunk size for packets
0×02 Unknown
0×03 Bytes Read send every x bytes read by both sides
0×04 Ping ping is a stream control message, has subtypes
0×05 Server BW the servers downstream bw
0×06 Client BW the clients upstream bw
0×07 Unknown
0×08 Audio Data packet containing audio
0×09 Video Data packet containing video data
0x0A-0x0E Unknown
0x0F FLEX_STREAM_SEND TYPE_FLEX_STREAM_SEND
0x10 FLEX_SHARED_OBJECT TYPE_FLEX_SHARED_OBJECT
0x11 FLEX_MESSAGE TYPE_FLEX_MESSAGE
0×12 Notify an invoke which does not expect a reply
0×13 Shared Object has subtypes
0×14 Invoke like remoting call, used for stream actions too.
0×16 StreamData 这是FMS3出来后新增的数据类型,这种类型数据中包含AudioData和VideoData
五、StreamID
StreamID是音视频流的ID,如果AMFType!=0x08 或!=0x09那么 StreamID为0。
ChannelID 和StreamID之间的计算公式：StreamID=(ChannelID-4)/5+1 参考red5
例如当ChannelID为2、3、4时StreamID都为1 当ChannelID为9的时候StreamID为2
六、封包分析
例如有一个RTMP封包的数据03 00 00 00 00 01 02 14 00 00 00 00 02 00 07 63 6F 6E 6E 65 63 74 00 3F F0 00 00 00 00 00 00 08 ，，，
数据依次解析的含义
03表示12字节头，channelid=3
000000表示Timmer=0
000102表示AMFSize=18
14表示AMFType=Invoke 方法调用
00 00 00 00 表示StreamID = 0
//到此,12字节RTMP头结束下面的是AMF数据分析,具体的AMF0数据格式请参考 http://www.cnweblog.com/fly2700/archive/2008/04/09/281432.html
02表示String
0007表示String长度7
63 6F 6E 6E 65 63 74 是String的Ascall值"connect"
00表示Double
3F F0 00 00 00 00 00 00 表示double的0.0
08表示Map数据开始
(2014-08-03 08:17:43)
