RTMP协议详解
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
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的组成如下图所示
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,如图所示
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++