rtmp规范中文版10.docx
- 文档编号:23985988
- 上传时间:2023-05-23
- 格式:DOCX
- 页数:54
- 大小:581.83KB
rtmp规范中文版10.docx
《rtmp规范中文版10.docx》由会员分享,可在线阅读,更多相关《rtmp规范中文版10.docx(54页珍藏版)》请在冰豆网上搜索。
rtmp规范中文版10
实时消息协议---流的分块
版权声明:
版权(c)2009Adobe系统有限公司。
全权所有。
摘要:
本备忘录描述实时消息协议块流。
块流是一种应用层协议,主要用于通过一种合适的传输层协议(例如TCP)复用、打包多媒体数据流(音频,视频和交互数据)。
目录:
1.简介
1.1术语
2.定义
3.字节序、对齐和时间格式
4.消息格式
5.握手
5.1握手序列
5.2C0和S0格式
5.3C1和S1格式
5.4C2和S2格式
5.5握手示意图
6.块
6.1块格式
6.1.1块基本头
6.1.2块消息头
6.1.2.1类型0
6.1.2.2类型1
6.1.2.3类型2
6.1.2.4类型3
6.1.3扩展时间格式
6.2示例
6.2.1示例1
6.2.2示例2
7.协议控制消息
7.1设置块的大小
7.2关于消息
8.参考
8.1规范参考
8.2信息参考
9.致谢
1.简介
本文档规定实时消息协议块流(RTMP块流)。
分块为更高层的多媒体流协议提供复用和分组服务。
虽然RTMP块流是为协同RTMP协议工作而设计的,但是它任然可以处理任何发送消息流的协议。
每个消息包含时间戳和负载类型标志。
RTMP块流和RTMP共同适用于各种形式的音视频应用,从点到点和点到多的实时直播,到vod服务,到交互式视频会议。
当配合像[TCP]这样的可靠传输协议使用时,RTMP块流保证跨流的所有消息按时间戳序列一个接一个地传输。
RTMP块流不提供优先级或类似的控制,但是可以通过更高层的协议提供类似的服务。
例如,视频直播服务可以基于每个消息的发送时间和答复时间选择丢弃视频消息,使慢的客户端能及时接受到音频消息。
RTM块流包含自己的带内协议控制消息,并且提供了让更高层的协议嵌入用户控制消息的机制。
1.1术语
本文档中的关键词”必须”、”一定不”、”要求”、”可以”、”不可以”、”应该”、”不应该”、”建议”、”可能”和”可选”的解释参考文档[BCP14][RFC2119]。
2.定义
负载:
分组中所包含的数据。
例如音频样本和压缩视频数据。
负载格式和解释不在本文档的描述范围之内。
分组:
一个数据分组由固定的头和负载数据组成。
一些底层协议可能需要定义分组的封装。
端口:
在一个给定计算机中区分不同目标的抽象。
在TCP/IP协议中用一个小的整数来表示端口。
OSI中的传输选择器等同于端口的概念。
传输地址:
用于表示一个传输层终端的网络地址和端口的组合。
例如IP地址和TCP端口。
分组从源地址传输到目标地址。
消息流:
允许消息流动的逻辑上的通讯通道。
消息流ID:
每个消息所关联的ID,用于区分其所在的消息流。
块:
一个消息片段。
消息通常在被放到网络上传输之前被分成小的部分并且被交错存取。
分块确保跨流的所有消息按时间戳顺序被不断的传输。
块流:
允许块按照某一方向流动的逻辑上的通讯通道。
块流可以从客户端流向服务端,也可以从服务端流向客户端。
块流ID:
每个块所关联的用于区分其所在块流的ID。
复用:
把分开的音视频数据整合到一个数据流,让多个音视频流可以同步地传输的过程。
解复用:
复用的反向过程。
交互的音视频数据被收集成原始的音频数据和视频数据。
3.字节序、对齐和时间格式
所有完整的字段都是按网络字节序被承载的,即,零字节是第一个字节,零位是一个字或字段中最显著的位。
这种字节序就是所谓的”big-endian”。
这种传输顺序的详细描述见[STD5]。
除非另行说明,本文档中的数字都是十进制数。
在没有特别说明的情况下RTMP块流中的所有数据都是按字节对齐的。
例如,一个16位字段可能在奇数字节偏移的位置。
在标有延拓的地方,延拓字节应赋予零值。
RTMP块流中的时间戳是用整数表示的,以毫秒为单位的相对时间,相对于一个未规定的起始时间。
一般,每个块流的时间戳都从0开始,但是只要通讯的双方用统一的起始时间,可以不使用这种方法。
要注意的是,这样跨多个块流(特别是不同主机之间)的同步需要用另外的机制来实现。
时间戳必须是单调递增的,并且是线性增长的。
这样可以使应用程序处理同步,测量带宽,注入检测和进行流控制。
因为时间戳只有32位长,所以只能在50天以内循环。
但是,因为流是可以不断的运行的,潜在地可以多年才结束?
,所以RTMP块流应用程序必须对减法和比较使用模运算,并且能够处理这种回绕。
只要通讯双方一致,任何合理的方法都可使用。
例如,一个应用程序可以假设,相邻的时间戳是2^31毫秒,那么1000在4000000000之后,3000000000在4000000000之前。
时间戳增量也是以毫秒为单位的无符号整数。
时间戳增量可以是24位或32位长。
4.消息格式(可以参考消息格式文档的第4节)
消息格式依赖于上层协议,可以被分成多个块以支持复用。
但是消息格式必须包含下面这些创建块所必须的字段。
时间戳:
消息时间戳,占4个字节。
长度:
消息负载的长度,如果消息头无法被消减的话,应该包含在长度里,这个字段在块头中占3个字节。
类型ID:
一些类型ID是为消息控制协议保留的。
这些ID繁衍供RTMP块流协议和高层协议使用的信息。
所有其他的ID都用于更高层协议。
RTMP块流协议对这些ID做不透明处理。
事实上,RTMP块流协议不需要用本字段的值来区分类型;所有消息可以是同类型的,或者应用可以使用本字段来区分同步轨道而不是区分类型。
本字段占一个字节。
消息流ID:
消息流ID可以是任何的值。
被复用到相同的块流的消息流依靠其消息ID来解复用。
除此之外,对于RTMP块流协议来说,这个值是不透明的。
这个值在块头中占4个字节,并且使用小字节序。
5.握手
一个RTMP连接以握手开始。
这里的握手和其他协议的握手不一样。
这里的握手由三个固定大小的块组成,而不是可变大小的块加上头。
客户端(发起连接的一方)和服务端各自发送三个相同的块。
这些块如果是客户端发送的话记为C0,C1和C2,如果是服务端发送的话记为S0,S1和S2。
5.1握手队列
握手开始于客户端发送C0,C1块。
在发送C2之前客户端必须等待接收S1。
在发送任何数据之前客户端必须等待接收S2。
服务端在发送S0和S1之前必须等待接收C0,也可以等待接收C1。
服务端在发送S2之前必须等待接收C1。
服务端在发送任何数据之前必须等待接收C2。
5.2C0和S0消息格式
C0和S0是单独的一个字节。
下面是C0和S0包的字段说明。
版本:
8位
在C0中这个字段表示客户端要求的RTMP版本。
在S0中这个字段表示服务器选择的RTMP版本。
本规范所定义的版本是3;0-2是早期产品所用的,已被丢弃;4-31保留在未来使用;32-255不允许使用(为了区分其他以某一字符开始的文本协议)。
如果服务无法识别客户端请求的版本,应该返回3。
客户端可以选择减到版本3或选择取消握手。
5.3C1和S1消息格式
C1和S1消息有1536字节长,由下列字段组成。
时间:
4字节
本字段包含时间戳。
该时间戳应该是发送这个数据块的端点的后续块的时间起始点。
可以是0,或其他的任何值。
为了同步多个流,端点可能发送其块流的当前值。
零:
4字节
本字段必须是全零。
随机数据:
1528字节。
本字段可以包含任何值。
因为每个端点必须用自己初始化的握手和对端初始化的握手来区分身份,所以这个数据应有充分的随机性。
但是并不需要加密安全的随机值,或者动态值。
5.4C2和S2消息格式
C2和S2消息有1536字节长。
只是S1和C1的回复。
本消息由下列字段组成。
时间:
4字节
本字段必须包含对等段发送的时间(对C2来说是S1,对S2来说是C1)。
时间2:
4字节
本字段必须包含先前发送的并被对端读取的包的时间戳。
随机回复:
1528字节
本字段必须包含对端发送的随机数据字段(对C2来说是S1,对S2来说是C1)。
每个对等端可以用时间和时间2字段中的时间戳来快速地估计带宽和延迟。
但这样做可能并不实用。
5.5握手示意图
Figure4PictorialRepresentationofHandshake
下表描述握手中的状态机。
状态
描述
未初始化
在这个状态中发送双方的版本。
此时客户端和服务端都未初始化。
客户端在C0包中发送版本号。
如果服务端支持那个版本,则发送S0和S1作为响应,否则,服务端采用适当的行为作为响应。
在RTMP规范中应终止连接。
版本已发送
在未初始化状态之后客户端和服务端都进入版本已发送状态。
客户端等待S1包,服务端等待C1包。
在接收到所等待的包后客户端发送C2包,服务端发送S2包。
进入发送确认状态。
确认发送
客户端和服务端依次等待S2和C2。
握手完成
客户端和服务端发送消息。
6.分块
握手之后,连接开始复用一个或多个块流。
每个块流承载来自一个消息流的一类消息。
每个被创建的块都关联到一个唯一的块流ID。
所有的块都通过网络传输。
在传输过程中,必须一个块发送完之后再发送下一个块。
在接收端,每个块都根据块ID被收集成消息。
分块使高层协议的大消息分割成小的消息,保证大的低优先级消息不阻塞小的高优先级消息。
分块把原本应该消息中包含的信息压缩在块头中减少了小块消息发送的开销。
块大小是可配置的。
这个可以在7.1节中描述的块消息中完成。
最大块是65535字节,最小块是128字节。
块越大CPU使用率越低,但是也导致大的写入,在低带宽下产生其他内容的延迟。
块大小对每个方向都保持独立。
6.1块格式
块由头和数据组成。
块头由三部分组成:
块基本头:
1到3字节
本字段包含块流ID和块类型。
块类型决定编码的消息头的格式。
长度取决于块流ID。
块流ID是可变长字段。
块消息头:
0,3,7或11字节。
本字段编码要发送的消息的信息。
本字段的长度,取决于块头中指定的块类型。
扩展时间戳:
0个或4字节
本字段必须在发送普通时间戳(普通时间戳是指块消息头中的时间戳)设置为0xffffff时发送,正常时间戳为其他值时都不应发送本值。
当普通时间戳的值小于0xffffff时,本字段不用出现,而应当使用正常时间戳字段。
6.1.1块基本头
块基本头编码块流ID和块类型(在下图中用fmt表示)。
块类型决定编码消息头的
格式。
块基本头字段可能是1,2或3个字节。
这取决于块流ID。
一个实现应该用最少的数据来表示ID?
。
本协议支持65597种流,ID从3-65599。
ID0、1、2作为保留。
0,表示ID的范围是64-319(第二个字节+64);1,表示ID范围是64-65599(第三个字节*256+第二个字节+64);2表示低层协议消息。
没有其他的字节来表示流ID。
3-63表示完整的流ID。
3-63之间的值表示完整的流ID。
没有其他的字节表示流ID。
0-5(不显著的)位表示块流ID。
块流ID2-63可以用1字节的字段表示
块流ID64-319可以用2-字节表示。
ID计算是(第二个字节+64)
块流ID64-65599可以表示为3个字节。
ID计算为第三个字节*255+第二个字节+64
Csid:
6位
本字段表示范围在2-63的块流ID。
值0和1表示本字段的2或3字节版本
Fmt:
2位
本字段标识块消息头的4种格式。
每种流类型的块消息头在下一节中表示。
Csid-64:
8-16位
本字段包含块流ID减去64的值。
例如365,应在csid中表示1,而用这里的16位表示301。
块流ID在64-319范围之内,可以用2个字节版本表示,也可以用3字节版本表示。
6.1.2块消息头
有四种格式的块消息ID,供块流基本头中的fmt字段选择。
一个实现应该使用最紧致的方式来表示块消息头。
6.1.2.1类型0
0类型的块长度为11字节。
在一个块流的开始和时间戳返回的时候必须有这种块。
时间戳:
3字节
对于0类型的块。
消息的绝对时间戳在这里发送。
如果时间戳大于或等于16777215(16进制0x00ffffff),该值必须为16777215,并且扩展时间戳必须出现。
否则该值就是整个的时间戳。
6.1.2.2.类型1
类型1的块占7个字节长。
消息流ID不包含在本块中。
块的消息流ID与先前的块相同。
具有可变大小消息的流,在第一个消息之后的每个消息的第一个块应该使用这个格式。
6.1.2.3.类型2
类型2的块占3个字节。
既不包含流ID也不包含消息长度。
本块使用的流ID和消息长度与先前的块相同。
具有固定大小消息的流,在第一个消息之后的每个消息的第一个块应该使用这个格式。
6.1.2.4类型3
类型3的块没有头。
流ID,消息长度,时间戳都不出现。
这种类型的块使用与先前块相同的数据。
当一个消息被分成多个块,除了第一块以外,所有的块都应使用这种类型。
示例可参考6.2.2节中的例2。
由相同大小,流ID,和时间间隔的流在类型2的块之后应使用这种块。
示例可参考6.2.1节中的例1。
如果第一个消息和第二个消息的时间增量与第一个消息的时间戳相同,那么0类型的块之后必须是3类型的块而,不需要类型2的块来注册时间增量。
如果类型3的块在类型0的块之后,那么类型3的时间戳增量与0类型的块的时间戳相同。
时间戳增量:
3字节
对于类型1的块和类型2的块,本字段表示先前块的时间戳与当前块的时间戳的差值。
如果增量大于等于1677215(16进制0x00ffffff),这个值必须是16777215,并且扩展时间戳必须出现。
否则这个值就是整个的增量。
消息长度:
3字节
对于类型0或类型1的块本字段表示消息的长度。
注意,这个值通常与负载长度是不相同的。
Thechunkpayloadlengthisthemaximumchunksizeforallbutthelastchunk,andtheremainder(whichmaybetheentirelength,forsmallmessages)forthelastchunk.
消息类型ID:
1字节
对于0类型和1类型的块,本字段发送消息类型。
消息流ID:
4字节
对于0类型的块,本字段存储消息流ID。
通常,在一个块流中的消息来自于同一个消息流。
虽然,由于不同的消息可能复用到一个块流中而使头压缩无法有效实施。
但是,如果一个消息流关闭而另一个消息流才打开,那么通过发送一个新的0类型的块重复使用一个存在的块流也不是不可以。
6.1.3.扩展时间戳
只有当块消息头中的普通时间戳设置为0x00ffffff时,本字段才被传送。
如果普通时间戳的值小于0x00ffffff,那么本字段一定不能出现。
如果时间戳字段不出现本字段也一定不能出现。
类型3的块一定不能含有本字段。
本字段在块消息头之后,块时间之前。
6.2示例
6.2.1.例1
例1展示一个简单的音频消息流。
这个例子显示了信息的冗余。
MessageStreamID
MessageTypeID
Time
Length
Msg#1
12345
8
1000
32
Msg#2
12345
8
1020
32
Msg#3
12345
8
1040
32
Msg#4
12345
8
1060
32
Figure13SampleAudiomessagestobemadeintochunks
下表显示了这个流产生的块。
从消息3开始,数据传输开始优化。
在消息3之后,每个消息只有一个字节的开销。
ChunkStreamID
ChunkType
HeaderData
No.ofBytesAfterHeader
TotalNo.of
BytesintheChunk
Chunk#1
3
0
delta:
1000
length:
32
type:
8
streamID:
1234
(11bytes)
32
44
Chunk#2
3
2
20(3bytes)
32
36
Chunk#3
3
3
none(0bytes)
32
33
Chunk#4
3
3
none(0bytes)
32
33
Figure14Formatofeachofthechunksofaudiomessagesabove
6.2.2例2
例2演示一个消息由于太长,而被分割成128字节的块。
MessageStreamID
MessageTYpeID
Time
Length
Msg#1
12346
9(video)
1000
307
Figure15SampleMessagetobebrokentochunks
下面是产生的块。
ChunkStreamID
ChunkType
HeaderData
No.ofBytesafterHeader
TotalNo.ofbytesinthechunk
Chunk#1
4
0
delta:
1000
length:
307
type:
9
streamID:
12346
(11bytes)
128
140
Chunk#2
4
3
none(0bytes)
128
129
Chunk#3
4
3
none(0bytes)
51
52
Figure16Formatofeachofthebrokenchunk.
7.协议控制消息
RTMP块流支持一些协议控制消息。
这些消息包含rtmp块流协议需要的信息,并且不能传播到更高层的协议。
当前有两种消息用于RTMP块流。
一个协议消息用于设置块大小,另一个用于由于余下的块不可得而取消一个消息。
协议控制消息应该含有消息流ID0(称为控制流)和块流ID2,并且应有最高的发送优先级。
每个协议控制消息有一个固定大小的负载,并且作为一个独立的块发送。
7.1设置块大小
协议控制消息1,设置块大小,用于通知对端新的最大块大小。
块大小可以设置默认值,但是客户端或服务端可以改变和更新这个值。
例如,假设一个客户端想发送131字节的音频数据,而块大小是128。
那么,客户端可以向服务端发送一个协议消息通知对方块大小设置为131字节。
然后,客户端就可以在一个块中发送音频数据。
最大块大小是65535字节。
块大小在每个方向上保持独立。
7.2取消消息
本协议控制消息用于通知对等端,不用再等待接收块来完成消息,而可以丢弃以前通过块流接收到的消息了。
这个协议消息的负载是对等端接收到的块流ID。
一个应用程序在关闭的时候发送这个消息,以告诉对方不需要继续处理消息了。
8.参考文献
8.1.标准参考
[1]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.
[2]Crocker,D.andOverell,P.(Editors),"AugmentedBNFforSyntax
Specifications:
ABNF",RFC2234,InternetMailConsortiumand
DemonInternetLtd.,November1997.
[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[RFC2234]Crocker,D.andOverell,P.(Editors),"AugmentedBNFfor
SyntaxSpecifications:
ABNF",RFC2234,InternetMail
ConsortiumandDemonInternetLtd.,November1997.
8.2.资料参考
[3]Faber,T.,Touch,J.andW.Yue,"TheTIME-WAITstateinTCP
andItsEffectonBusyServers",Proc.Infocom1999pp.1573-
1583.
[Fab1999]Faber,T.,Touch,J.andW.Yue,"TheTIME-WAITstatein
TCPandItsEffectonBusyServers",Proc.Infocom1999pp.1573-1583.
9.感谢
地址:
AdobeSystemsIncorporated
345ParkAvenue
SanJose,CA95110-2704
RTMP消息格式
------------------------实时消息协议消息格式
版权声明
版权(c)2009Adobe系统有限公司。
全权所有。
摘要
本备忘录描述实时消息协议。
实时消息协议是一种应用层协议,主要用于通过一种合适的传输层协议复用、打包多媒体数据流(音频,视频和交互数据)。
目录
1.简介
1.1术语
2.定义
3.字节序、对齐和时间格式
4.RTMP消息格式
4.1消息头
4.2消息负载
5.协议控制消息
5.1设置块大小
5.2取消消息
5.3致谢
5.4用户控制消息
5.5WindowAcknowledgementSize
5.6设置对等端带宽
6.参考
6.1标准参考
6.2资料参考
1.简介
本文档规定实时消息协议。
实时消息协议规定通过传输层传输的消息的格式。
虽然RTMP被设计与实时消息块流协议一起工作,但是仍然可以用任何其他的传输协议来发送消息。
RTMP块流和RTMP一起适用于广泛的音视频应用。
从点到点和点到多的实时直播,到vod服务,到交互式视频会议。
1.1术语
本文档中的关键词”必须”、”一定不”、”要求”、”可以”、”不可以”、”应该”、”不应该”、”建议”、”可能”和”可选”的解释参考文档[BCP14][RFC2119]。
2.定义
消息流:
允许消息流动的逻辑上的通讯通道。
消息流ID:
每个消息所关联的ID,用于区分其所在的消息流。
负载:
包中所包含的数据。
例如音频样本和压缩视频数据。
负载格式和解释不在本文档的描述范围之内。
分组:
一个数据分组包含固定的头和负载数据。
一些
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- rtmp 规范 中文版 10