rtmp详解

文件下载地址:

 中文:https://files.cnblogs.com/files/bugutian/rtmp_specification_1.0_cn.zip

英文:http://www.adobe.com/cn/devnet/rtmp.html 

本文直接从中文的PDF上复制而来,无配图,请下载中文的zip解压成pdf之后查看。 

RTMP 协议 Adobe 官 方规范
By, Defonds
Blog, http://blog.csdn.net/defonds
Email, defonds@163.com

1. 简介
Adobe 的实时消息传输协议 (RTMP) 通过一个靠地流传输供了一个向多通 道消息服,比如 TCP [RFC0793],意图在通信端之间传递有时间信息的视频音频和
数据消息流实通常对不类型的消息配不的优先级,当载能力有限时,会影响
等流传输的消息的次序 本文档将对实时流传输协议 (Real Time Messaging Protocol) 的语法和操作行述

2. 贡献者
Rajesh Mallipeddi,Adobe Systems 原员,起草了本文档原始规范,并供大部的 原始内容 Mohit Srivastava,Adobe Systems 员,促了本规范的开发

3. 词解释
Payload (有效载荷)包于一个数据包中的数据,例如音频采样或者压缩的视频数据 payload 的格式和解释,超出了本文档的范围

Packet (数据包)一个数据包由一个固定头和有效载荷数据构一些个层协议能 会要求对数据包定封装

Port (端口)"传输协议用开指定一机的不目的地的一个抽象TCP/IP 使 用小的整数对端口行标识" OSI 传输层使用的输选择器 (TSEL) 相当于端口

Transport address (传输地址)用识传输层端点的网地址和端口的组合,例如一个 IP 地址和一个 TCP 端口数据包由一个源传输地址传到一个目的传输地址

Message stream (消息流)通信中消息流通的一个逻辑通道

Message stream ID (消息流 ID)每个消息有一个关联的 ID,使用 ID 识出流通 中的消息流

Chunk (块)消息的一段消息在网发之前被拆很多小的部块确保端 到端交付所有消息有序 timestamp,即使有很多不的流

Chunk stream (块流)通信中允许块流向一个特定方向的逻辑通道块流从客户端 流向服器,也从服器流向客户端

Chunk stream ID (块流 ID)每个块有一个关联的 ID,使用 ID 识出流通中的块 流

Multiplexing (合)将独立的音频/视频数据合一个续的音频/视频流的工, 样时发几个视频和音频

DeMultiplexing (解)Multiplexing 的逆向处理,将交的音频和视频数据原原始 音频和视频数据的格式

Remote Procedure Call (RPC 程方法调用)允许客户端或服器调用对端的一个子程 序或者程序的求

Metadata (元数据)关于数据的一个述一个电影的 metadata 包括电影标题持续 时间创建时间等等

Application Instance (用实例)服器用的实例,客户端接个实例并发 接求

Action Message Format (AMF 动作消息格式协议)一个用于序列化 ActionScript 对象 图的紧凑的制格式AMF 有两个版本AMF 0 [AMF0] 和 AMF 3 [AMF3]

4. 节序对齐和时间格式
所有整数型属性网节序传输,节 0 表第一个节,零是一个单词或 段最常用的有效节序通常是大端排序关于传输序的更多细节述参考 IP 协议 [RFC0791]除非另外注明,本文档中的数值常量都是十制的 ( 10 基础)

除非另有规定,RTMP 中的所有数据都是节对准的例如,一个十的属性能 会在一个奇节偏移填充,填充节有零值

RTMP 中的 Timestamps 一个整数形式给出,表示一个未指明的时间点型地,每 个流会一个 0 的 timestamp 起始,但不是必的,要端能够就时间点达一 注意意味着任意不流 (尤是来自不机的) 的需要 RTMP 之外的机制

因 timestamp 的长度 32 ,每隔 49 17 小时 2 钟和 47.296 秒就要来 一次因允许流续传输,有能要多年,RTMP 用在处理 timestamp 时使用序 列码算法 [RFC1982],并且能够处理无限循例如,一个用假定所有相邻的 timestamp 都在 2^31 - 1 毫秒之内,因 10000 在 4000000000 之,而 3000000000 在 4000000000 之前

timestamp 也使用无符整数定,相对于前面的 timestamptimestamp 的长度能 会是 24 或者 32

5. RTMP 块流
本节介绍实时消息传输协议的块流 (RTMP 块流) 它层多媒体流协议供合并和 打包的服

当设 RTMP 块流使用实时消息传输协议时,它处理任何发消息流的协议每 个消息包 timestamp 和 payload 类型标识RTMP 块流和 RTMP 一起合各种音频-视 频用,从一对一和一对多直播到点播服,到互动会议用

当使用靠传输协议时,比如 TCP [RFC0793],RTMP 块流能够对于多流供所有消 息靠的 timestamp 有序端对端传输RTMP 块流并不供任何优先权或类似形式的控制,
但是被层协议用来供种优先级例如,一个直播视频服器能会基于发时间
或者每个消息的确认时间丢一个传输缓慢的客户端的视频消息确保时获音频消


RTMP 块流包括自身的内协议控制信息,并且供机制层协议植入用户控制 消息

5.1 消息格式

被割块支持组合的消息的格式决于层协议消息格式必包创建
块所需的段

Timestamp消息的 timestamp个段传输四个节

Length消息的有效负载长度如果不能省略掉消息头,那它也被包括个长度 个段占用了块头的个节

Type Id一些类型 ID 保留给协议控制消息使用些传播信息的消息由 RTMP 块流 协议和层协议共处理他的所有类型 ID 用于层协议,它们被 RTMP 块流处理 不透明值实,RTMP 块流中没有任何地方要把些值当做类型使用所有消息必
是一类型,或者用使用一段来跟踪,而不是类型一段占用了块头
的一个节

Message Stream IDmessage stream (消息流) ID 使任意值合并到一个块流的不 的消息流是根据各自的消息流 ID 行解除之外,对 RTMP 块流而言,是一个 不透明的值个段小端格式占用了块头的四个节

5.2 握手

一个 RTMP 接握手开始RTMP 的握手不于他协议RTMP 握手由个固定 长度的块组,而不是像他协议一样的有头的长度的块

客户端 (发起接求的终端) 和服器端各自发相的块便于演示,当发自 客户端时些块被指定 C0C1 和 C2当发自服器端时些块被指定 S0 S1 和 S2

5.2.1. 握手序

握手客户端发 C0 和 C1 块开始

客户端必等接收到 S1 才能发 C2

客户端必等接收到 S2 才能发任何他数据

服器端必等接收到 C0 才能发 S0 和 S1,也等接收到 C1 发 S0 和 S1服器端必等接收到 C1 才能发 S2服器端必等接收到 C2 才能发 任何他数据

5.2.2. C0 和 S0 的格式

C0 和 S0 包都是一个单一的节,一个单独的整型域行处理

是 C0/S0 包中的段

版本 ()在 C0 中,一段指示出客户端要求的 RTMP 版本在 S0 中, 一段指示出服器端选择的 RTMP 版本本文档中规范的版本 3012 个值是由早期他产品使用的,是废值4 - 31 被保留 RTMP 协议的未来实版本使 用32 - 255 不允许使用 (开 RTMP 和他常一个打印符开始的文本协议) 无法识客户端所求版本的服器版本 3 响,(收到响的) 客户端选择 降到版本 3,或者放握手

5.2.3. C1 和 S1 的格式

C1 和 S1 数据包的长度都是 1536 节,包段

Time (四个节)个段包一个 timestamp,用于本终端发的所有续块的时间 起点个值是 0,或者一些任意值要多个块流,终端发他块流当前的 timestamp 的值

Zero (四个节)个段必都是 0

Random data (1528 个节)个段包任意值终端需要出响来自它发
起的握手是对端发起的握手,个数据发一些足够随机的数个不需要对随机数
行密保,也不需要动态值

5.2.4. C2 和 S2 的格式

C2 和 S2 数据包长度都是 1536 节,基本就是 S1 和 C1 的副本 (),包有 段 


Time (四 个 节) 个 段 必 包 终 端 在 S1 (给 C2) 或 者 C1 (给 S2) 发 的 timestamp

Time2 (四个节)个段必包终端先前发出数据包 (s1 或者 c1) timestamp

Random echo (1528 个节)个段必包终端发的 S1 (给 C2) 或者 S2 (给 C1) 的随机数两端都一起使用 time 和 time2 段当前 timestamp 快速估算宽 和/或者接延,但不能是有多大用处


5.2.5. 握手示意图


面述了握手示意图中到的状态

Uninitialized (未 初 始 化) 协 议 的 版 本 在 个 阶 段 被 发 客 户 端 和 服 器 都 是 uninitialized (未初始化) 状态之客户端在数据包 C0 中将协议版本发出如果服器 支持个版本,它将在回中发 S0 和 S1如果不支持呢,服器会才去当的行 行响在 RTMP 协议中,个行就是终接

Version Sent (版本已发)在未初始化状态之,客户端和服器都入 Version Sent (版本已发) 状态客户端会等接收数据包 S1 而服器在等 C1一旦拿到期的包, 客户端会发数据包 C2 而服器发数据包 S2(客户端和服器各自的)状态随即 Ack Sent (确认已发)

Ack Sent (确认已发)客户端和服器等 S2 和 C2

Handshake Done (握手结束)客户端和服器开始交换消息了


5.3 块

握手之,接开始对一个或多个块流行合并创建的每个块都有一个唯一 ID 对 行关联,个 ID 做 chunk stream ID (块流 ID)些块通过网行传输传递时, 每个块必被完全发才发一块在接收端,些块被根据块流 ID 被组装消 息

块允许层协议将大的消息解更小的消息,例如,防体积大的但优先级小的消
息 (比如视频) 阻碍体积较小但优先级高的消息 (比如音频或者控制命)

块也让们能够使用较小开销发小消息,因块头包包在消息内部的信息压缩


块 的 大 小 是 配 置 的 它 使 用 一 个 设 置 块 大 小 的 控 制 消 息 行 设 置 (参 考 5.4.1)更大的块大小降 CPU 开销,但在宽接时因它的大量的写入也会延
他内容的传递更小的块不利于高比特率的流化所块的大小设置决于体情况


5.3.1. 块格式

每个块包一个头和数据体块头包个部

Basic Header (基本头,1 到 3 个节)个段对块流 ID 和块类型行编码块类 型决定了消息头的编码格式(一段的) 长度完全决于块流 ID,因块流 ID 是一个 长度的段

Message Header (消息头,0,3,7,或者 11 个节)一段对在发的消息 (不 管是整个消息,是是一小部) 的信息行编码一段的长度使用块头中定
的块类型行决定

Extended Timestamp (扩展 timestamp,0 或 4 节)一段是否出决于块消息 头中的 timestamp 或者 timestamp delta 段更多信息参考 5.3.1.3 节

Chunk Data (有效大小)当前块的有效负载,相当于定的最大块大小

5.3.1.1. 块基本头

块基本头对块流 ID 和块类型 (由图中的 fmt 段表示) 行编码块基本头段 能会有 1,2 或者 3 个节,决于块流 ID

一个 (RTMP) 实使用能够容纳个 ID 的最小的容量行表示

RTMP 协议最多支持 65597 个流,流 ID 范围 3 - 65599ID 012 被保留0 值 表示节形式,并且 ID 范围 64 - 319 (第个节 + 64)1 值表示节形式,并且 ID 范围 64 - 65599 ((第个节) * 256 + 第个节 + 64)3 - 63 范围内的值表示整个流 ID有 2 值的块流 ID 被保留,用于层协议控制消息和命

块基本头中的 0 - 5 (最有效) 表块流 ID

块流 ID 2 - 63 编一段的一节版本中

块流 ID 64 - 319 节的形式编码在头中ID 算 (第个节 + 64) 

块流 ID 64 - 65599 编码在个段的节版本中ID 算 ((第个节) * 256 + (第个节) + 64)

cs id ()一段包有块流 ID,值的范围是 2 - 63值 0 和 1 用于指示一 段是 2- 或者 3- 节版本

fmt (两个节)一段指示 'chunk message header' 使用的四种格式之一没中块类 型的 'chunk message header' 会在一小节解释

cs id - 64 (8 或者 16 )一段包了块流 ID 减掉 64 的值例如,ID 365 在 cs id 中会一个 1 行表示,和的一个 16 的 301 (cs id - 64)

块流 ID 64 - 319 使用 2-byte 或者 3-byte 的形式在头中表示

5.3.1.2. 块消息头

块消息头四种不的格式,由块基本头中的 "fmt" 段行选择

一个 (RTMP) 实每个块消息头使用最紧凑的表示

5.3.1.2.1. 类型 0

类型 0 块头的长度是 11 个节一类型必用在块流的起始置,和流 timestamp 来的时候 (比如,置)


timestamp (个节)对于 type-0 块,当前消息的对 timestamp 在发如果 timestamp 大于或者等于 16777215 (十制 0xFFFFFF),一段必是 16777215,表 明有扩展 timestamp 段来补充完整的 32 timestamp否则的话,一段必是整个 的 timestamp

5.3.1.2.2. 类型 1

类型 1 块头长 7 个节不包消息流 ID一块使用前一块一样的流 ID 长度消息的流 (例如,一些视频格式) 在第一块之使用一格式表示之的每个新 消息



5.3.1.2.3. 类型 2

类型 2 块头长度 3 个节既不包流 ID 也不包消息长度一块有和前 一块相的流 ID 和消息长度有不长度的消息 (例如,一些音频和数据格式) 在 第一块之使用一格式表示之的每个新消息

5.3.1.2.4. 类型 3

类型 3 的块没有消息头流 ID消息长度 timestamp delta 等段都不在 种类型的块使用前面块一样的块流 ID当单一一个消息被割多块时,除了第一块的 他块都使用种类型参考例 2 (5.3.2.2 小节)组流的消息有样的大小,流 ID 和时间间隔在类型 2 之的所有块都使用一类型参考例 1 (5.3.2.1 小节)如果第 一个消息和第个消息之间的 delta 和第一个消息的 timestamp 一样的话,那在类型 0 的块之要紧跟一个类型 3 的块,因无需来一个类型 2 的块来注 delta 了如果一 个类型 3 的块跟着一个类型 0 的块,那个类型 3 块的 timestamp delta 和类型 0 块 的 timestamp 是一样的

5.3.1.2.5. 通用头段

块消息头中各段的述如

timestamp delta (个节)对于一个类型 1 或者类型 2 的块,前一块的 timestamp 和 当前块的 timestamp 的在发如果 delta 大于或者等于 16777215 (十制 0xFFFFFF),那一段必是 16777215,表示有扩展 timestamp 段来对整个 32 delta 行编码否则的话,一段是体 delta

message length (个节)对于一个类型 0 或者类型 1 的块,消息长度在行
发注意通常不于块的有效载荷的长度块的有效载荷表所有的除了最一块的最
大块大小,剩余的 (也能是小消息的整个长度) 最一块

message type id (消息类型 id,一个节)对于类型 0 或者类型 1 的块,消息的类型 在发

message stream id (四个节)对于一个类型 0 的块,保消息流 ID消息流 ID
小端格式保所有一个块流的消息都来自一个消息流当将不的消息流组合
一个块流时,种方法比头压缩的做法要好但是,当一个消息流被关闭而他的随
另一个是打开着的,就没有理由将有块流发一个新的类型 0 的块行复用了

5.3.1.3. 扩展 timestamp

扩展 timestamp 段用于对大于 16777215 (0xFFFFFF) 的 timestamp 或者 timestamp delta 行编码也就是,对于不合于在 24 的类型 01 和 2 的块的 timestamp 和 timestamp delta 编码一段包了整个 32 的 timestamp 或者 timestamp delta 编码 通过设置类型 0 块的 timestamp 段类型 1 或者 2 块的 timestamp delta 段 16777215 (0xFFFFFF) 来启用一段当最的有一块流的类型 01 或 2 块指示 扩展 timestamp 段出时,一段才会在类型 3 的块中出



5.3.2. 例子

5.3.2.1. 例子 1

个例子演示了一个简单地音频消息流个例子演示了信息的冗余



一个表格演示了个流所产生的块从消息 3 起,数据传输得到了最佳化利用每 条消息的开销在一点之都有一个节



5.3.2.2. 例子 2

一例子阐述了一条消息大,无法装在一个 128 节的块,被割若干块



是传输的块

块 1 的数据头说明了整个消息长度是 307 个节

由俩例子得知,块类型 3 被用于两种不的方式第一种是用于定一 条消息的配置第种是定一个从有状态数据中派生出来的新消息的起点


5.4 协议控制消息

RTMP 块流使用消息类型 ID 1235 和 6 用于协议控制消息些消息包 有 RTMP 块流协议所需要的信息

些协议控制消息必使用消息流 ID 0 (作已知控制流) 并流 ID 2 的块发 协议控制消息一旦被接收到就立即生效协议控制消息的 timestamp 被忽略


5.4.1. 设置块类型 (1)

协议控制消息 1,设置块大小,通知对端一个新的最大块大小

默认的最大块大小是 128 节,但是客户端或者服器改个大小,并使用 一消息对对端行更新例如,假定一个客户端想要发一个 131 节的音频数据,当 前块大小是默认的 128在种情况,客户端发种消息到服器通知它块大小 在是 131 节了样客户端就在单一块中发整个音频数据了

最大块大小设置的话最少 128 节,包内容最少要一个节最大块大小由每个 方面 (服器或者客户端) 自行维



0个必 0

chunk size (块大小,31 )一段保新的最大块大小值,节单,将用 于 之 发 者 发 的 块 , 直 到 有 更 多 (关 于 最 大 块 大 小 的 ) 通 知 有 效 值 1 到 2147483647 (0x7FFFFFFF,1 和 2147483647 都) 但是所有大于 16777215 (0xFFFFFF) 的大小值是等的,因没有一个块比一整个消息大,并且没有一个消息大于 16777215 节

5.4.2. 终消息

协议控制消息 2,终消息,用于通知对端,如果对端在等去完一个消息的块的话, 然抛一个块流中已接到的部消息对端接收到块流 ID 作当前协议消息的有效
负载一些程序能会在关闭的时候使用个消息指示不需要一对个消息的处理


chunk stream ID (块流 ID,32 )一段保块流 ID,流的当前消息会被丢


5.4.3. 确认 (3)

客户端或者服器在接收到等于窗口大小的节之必要发给对端一个确认窗
口大小是指发者在没有收到接收者确认之前发的最大数量的节个消息定了序列
,也就是目前接收到的节数

sequence number (序列,32 )一段保有目前接收到的节数

5.4.4. 窗口确认大小 (5)

客户端或者服器端发条消息来通知对端发和答之间的窗口大小发者在发
完窗口大小节之期对端的确认接收端在次确认发接收到的指示数值,或
者会话建立之尚未发确认,必发一个确认 (5.4.3 小节)


5.4.5. 设置对端宽 (6)

客户端或者服器端发一消息来限制对端的输出宽对端接收到一消息,
将通过限制一消息中窗口大小指出的已发但未被答复的数据的数量限制输出宽
接收到一消息的对端回复一个窗口确认大小消息,如果个窗口大小不于发给 (设置对端宽) 发者的最一条消息

限制类型值之一

0 - Hard对端限制输出宽到指示的窗口大小

1 - Soft对端限制输出宽到知识的窗口大小,或者已经有限制在作用的话就 两者之间的较小值

2 - Dynamic如果先前的限制类型 Hard,处理个消息就好像它被标记 Hard,否 则的话忽略个消息

6. RTMP 消息格式

一节定了使用层传输层 (比如 RTMP 块流协议) 传输的 RTMP 消息的格式 RTMP 协议设使用 RTMP 块流,使用他任意传输协议对消息行发RTMP 块流和 RTMP 一起用于多种音频 - 视频用,从一对一和一对多直播到点播服,到 互动会议用


6.1. RTMP 消息格式

服器端和客户端通过网发 RTMP 消息来行彼通信消息包音频视 频数据,或者他消息

RTMP 消息有两部头和它的有效载荷


6.1.1. 消息头

消息头包

Message Type (消息类型)一个节的段来表示消息类型类型 ID 1 - 6 被保留用于 协议控制消息

Length (长度)个节的段来表示有效负载的节数大端格式保

Timestamp四个节的段包了当前消息的 timestamp四个节也大端格式保

Message Stream Id (消息流 ID)个节的段指示出当前消息的流个节 大端格式保




6.1.2. 消息有效载荷


消息的另一个部就是有效负载,是个消息所包的实际内容例如,它是一
些音频样本或者压缩的视频数据有效载荷格式和解释不在本文档范围之内



6.2. 用户控制消息 (4)

RTMP 使用消息类型 ID 4 表示用户控制消息些消息包 RTMP 流传输层所使用 的信息RTMP 块流协议使用 ID 1235 和 6 (5.4 节介绍)

用户控制消息使用消息流 ID 0 (被认是控制流),并且 RTMP 块流发时 块流 ID 2用户控制消息一旦被接收立马生效它们的 timestamp 是被忽略的

客户端或者服器端发个消息来通知对端用户操作一消息携有类型
和数据

消息数据的前两个节用于指示类型类型被数据紧随数据段的
大小是的但是,如果消息必通过 RTMP 块流层传输时,最大块大小 (5.4.1 节) 足够大允许些消息填充在一个单一块中

类型和数据格式将在 7.1.7 小节列出

7. RTMP 命消息

一节述了在服器端和客户端彼通信交换的消息和命的不的类型

服器端和客户端交换的不消息类型包括用于发音频数据的音频消息用于发视
频数据的视频消息用于发任意用户数据的数据消息共享对象消息命消息共享
对象消息供了一个通用的方法来管理多用户和一服器之间的布式数据命消息在
客户端和服器端传输 AMF 编码的命客户端或者服器端通过使用命消息和 对端通信的流求程方法调用 (RPC)


7.1. 消息的类型

服器端和客户端通过在网中发消息来行彼通信消息是任何类型,包
音频消息,视频消息,命消息,共享对象消息,数据消息,用户控制消息

7.1.1. 命消息 (20, 17)

命消息在客户端和服器端传递 AMF 编码的命些消息被配消息类型值 20 行 AMF0 编码,消息类型值 17 行 AMF3 编码些消息发行 一些操作,比如,接,创建流,发布,播放,对端暂停命消息,像 onstatusresult 等 等,用于通知发者求的命的状态一个命消息由命 ID 和包相关参
数的命对象组一个客户端或者一个服器端通过和对端通信的流使用些命消
息求程调用 (RPC)

7.1.2. 数据消息 (18, 15)

客户端或者服器端通过发些消息发元数据或者任何用户数据到对端元数据
包括数据 (音频,视频等等) 的细信息,比如创建时间,时长,题等等些消息被
配消息类型 18 行 AMF0 编码和消息类型 15 行 AMF3 编码

7.1.3. 共享对象消息 (19, 16)

所谓共享对象实是一个 Flash 对象 (一个值对的集合),个对象在多个不客户 端用实例中保持消息类型 19 用于 AMF0 编码16 用于 AMF3 编码都被共 享对象保留每个消息包有不

支持类型

述 Use(=1) 客户端发一通知服器端一个已 命的共享对象已创建 Release(=2) 当共享对象在客户端被删除时客户端发 一到服器端 Request Change (=3) 客户端发给服器端一求共享 对象的已命的参数所关联到的值的改 Change (=4) 服器端发一已通知发起一求
之外的所有客户端,一个已命参数的值的
改 Success (=5) 如果求被接,服器端发一给 求的客户端,作 RequestChange 的响 SendMessage (=6) 客户端发一到服器端广播一条
消息一旦接收到一,服器端将会
给所有的客户端广播一消息,包括一消
息的发起者 Status (=7) 服器端发一通知客户端常情 况 Clear (=8) 服器端发一消息到客户端清理一个 共享对象服器端也会对客户端发的 Use 使用一行响 Remove (=9) 服器端发一有客户端删除一个 slot
Request Remove (=10) 客户端发一有客户端删除一个 slot Use Success (=11) 服器端发给客户端一表示接


7.1.4. 音频消息 (8)

客户端或者服器端发一消息发音频数据到对端消息类型 8 音频消息保 留

7.1.5. 视频消息 (9)

客户端或者服器发一消息发视频数据到对端消息类型 9 视频消息保留


7.1.6. 统消息 (22)

统消息是一个单一的包一系列的使用 6.1 节述的 RTMP 子消息的消息消息类 型 22 用于统消息

统消息的消息流 ID 覆盖了统中子消息的消息流 ID

统 消 息 的 timestamp 和 第 一 个 子 消 息 的 timestamp 的 不 点 在 于 子 消 息 的 timestamp 被相对流时间标调整了偏移每个子消息的 timestamp 被入偏移达到一个统 一流时间第一个子消息的 timestamp 和统消息的 timestamp 一样,所个偏移 量 0

向指针包有前一个消息的大小 (包前一个消息的头)样子配了 FLV 文的 格式,用于向查找

使用统消息有性能优势

块流在一个块中多一个单一完整的消息发因,增块大小并使用统 消息减少了发块的数量 子消息在内中续储在网中系统调用发些数据时更高效

7.1.7. 用户控制消息

客户端或者服器端发一消息来通知对端用户控制关于个的消息格式参考 6.2 节

支持用户控制类型

述 Stream Begin (=0) 服器发个来通知客户端一个流已
就绪并用来通信默认情况,一
在接收到客户端的用接命之
ID 0 发一数据 4 节, 表了已就绪流的流 ID Stream EOF (=1) 服器端发一来通知客户端求的
流的回放数据已经结束在发额外的命
之前不发任何数据客户端将丢接收
到的个流的消息一数据 4 节,表了回放已结束的流的流 ID StreamDry (=2) 服器端发一来通知客户端当前流
中已没有数据当服器端在一段时间内没
有检测到任何消息,它通知相关客户端
当前流已经没数据了一数据 4 节,表了已没数据的流的流 ID SetBuffer Length (=3) 客户端发一来通知服器端用于缓 流 中 任 何 数 据 的 缓 大 小 ( 毫 秒 单 )一在服器端开始处理流之前就 发一数据的前 4 个节表了流 ID 4 个节表了毫秒单的缓 的长度 StreamIs Recorded (=4) 服器端发一来通知客户端当前流
是一个录制流一数据 4 节, 表了录制流的流 ID PingRequest (=6) 服器端发一用于测试是否能够 达 客 户 端 时 间 数 据 是 一 个 4 节 的 timestamp,表了服器端发一命时
的服器本地时间客户端在接收到一消
息会立即发 PingResponse 回复 PingResponse (=7) 客户端作对 ping 求的回复发一 到服器端一数据是一个 4 节的 timestamp,就是接收自 PingRequest 那 个


7.2. 命类型

客户端和服器端交换 AMF 编码的命服器端发一个命消息,个命消 息由命 ID 包有相关参数的命对象组例如,包有 'app' 参数的
接命,个命说明了客户端接到的服器端的用接收者处理一命并回发一
个样 ID 的响回复符串是 _result_error 或者 一个方法的任意一个, 比如,verifyClient 或者 contactExternalServer

命符串 _result 或者 _error 是响信 ID 指示出响所指向的命 和 AMAP 和他一些协议的标签一样命符串中的方法表示发者试图执行接收者 一端的一个方法

类的对象用于发不的命

NetConnection 表层的服器端和客户端之间接的一个对象

NetStream 一个表发音频流视频流和他相关数据的通道的对象当然,们也 会发控制数据流的命,如 playpause 等等

7.2.1. NetConnection 命


NetConnection 管理着一个客户端用和服器端之间的相接外,它供 程方法的调用

NetConnection 发命

connect

call

close

createStream

7.2.1.1. connect 命

客户端发 connect 命到服器端来求接到一个服器用的实例

由客户端发到服器端的 connect 命结构如

段 类型 述 Command Name 符串 命 的 设 置 给 "connect" Transaction ID 数 总是设置 1 Command Object 对象 有值对的命信息对象
Optional User Arguments 对象 任意选信息


是 connect 命中使用的值对对象的述

属性 类 型
述 范例
app


客户端接到的服器端用的 testapp
flashver


Flash Player 版 本 和 ApplicationScript getversion() 方法返回 的是一个符串
FMSc/1.0
swfUrl


行当前接的 SWF 文源地址 file://C:/FlvPlayer.swf
tcUrl


服 器 URL 有 格 式 protocol://servername:port/appName/appI nstance
rtmp://localhost:1935/testapp/ins tance1
fpad 布 尔
如果使用了理就是 true true 或者 false
audioCodecs 数
表明客户端所支持的音频编码 SUPPORT_SND_MP3
videoCodecs 数
表明支持的视频编码 SUPPORT_VID_SORENSON
videoFunctio 数 表明所支持的特殊视频方法 SUPPORT_VID_CLIENT_SEE
n K pageUrl


SWF 文所载的网页 URL http://somehost/sample.html
objectEncodi ng


AMF 编码方法 AMF3

audioCodecs 属性的标识值

videoCodecs 属性的标识值 


videoFunction 属性的标识值


encoding 属性值



服器端到客户端的命的结构如

命执行时消息流动如

1. 客户端发 connect 命到服器端求对服器端用实例的接

2. 收到 connect 命,服器端发协议消息 '窗口确认大小' 到客户端服 器端也会接到 connect 命中到的用

3. 服器端发协议消息 '设置对端宽' 到客户端

4. 在处理完协议消息 '设置对端宽' 之客户端发协议消息 '窗口确认大小' 到服器端

5. 服器端发另一个用户控制消息 (StreamBegin) 类型的协议消息到客户端

6. 服器端发结果命消息告知客户端接状态 (success/fail)一命定了 ID (常常 connect 命设置 1)一消息也定了一些属性,比如 FMS 服器 版本 (符串)外,它定了他接关联到的信息,比如 level (符串)code (符 串)description (符串)objectencoding (数) 等等


7.2.1.2. call 方法

NetConnection 对象的 call 方法执行接收端程方法的调用 (PRC)被调用的 PRC 作一个参数传给调用命

发端发给接收端的命结构如

段 类型 述 Procedure Name 符串 调用的程方法的 Transaction ID 数 如果期望回复们要给一个 ID否则们传 0 值 即 Command Object 对象 如果在一些命信息要设 置个对象,否则置空 Optional Arguments 对象 任意要供的选参数


回复的命结构如

段 类型 述 Command Name 符串 命的 Transaction ID 数 响所属的命的 ID Command Object 对象 如果在一些命信息要设 置个对象,否则置空 Response 对象 调用方法的回复


7.2.1.3. createStream 命

客户端发一命到服器端消息接创建一个逻辑通道音频视频和元数据
使用 createStream 命创建的流通道传输

NetConnection 是 默 认 的 通 信 通 道 , 流 ID 0 协 议 和 一 些 命 消 息 , 包 括 createStream,使用默认的通信通道

客户端发给服器端的命结构如

段 类型 述 Command Name 符串 命 设 置 给 "createStream" Transaction ID 数 命的 ID Command Object 对象 如果在一些命信息要设 置个对象,否则置空


服器端发给客户端的命结构如

段 类型 述 Command Name 符串 _result 或者 _error表明回 复是一个结果是错误 Transaction ID 数 响所属的命的 ID Command Object 对象 如果在一些命信息要设 置个对象,否则置空 Stream ID 数 返回值要是一个流 ID 要 是一个错误信息对象


7.2.2. NetStream 命

NetStream 定了传输通道,通过个通道,音频流视频流数据消息流通过 接客户端到服端的 NetConnection 传输

命由客户端使用 NetStream 往服器端发

play

play2

deleteStream

closeStream

receiveAudio

receiveVideo

publish

seek

pause


服器端使用 "onStatus" 命向客户端发 NetStream 状态

段 类型 述 Command Name 符串 命 "onStatus" Transaction ID 数 ID 设置 0 Command Object Null onStatus 消息没有命对象
Info Object 对象 一个 AMF 对象少要有 个 属 性 "level" ( 符 串 ) 一 消 息 的 等 级 , "warning""status""error" 中 的某个值"code" (符串) 消 息 码 , 例 如 "NetStream.Play.Start" "description" (符串)关于 个消息人类读述


7.2.2.1. play 命

客户端发一命到服器端播放流也多次使用一命创建一个播放列


如果你想要创建一个动态的播放列表一在不的直播流或者录制流之间行
换播放的话,多次调用 play 方法,并在每次调用时传递置 false相的,如果你想 要立即播放指定流,将他等播放的流清空,并置设 true

客户端发到服器端的命结构如

段 类型 述 Command Name 符串 命设 "play" Transaction ID 数 ID 设 0 Command Object Null 命信息不在设 null 类型 Stream Name 符串 要播放流的要播放视频 (FLV) 文,使用没有文扩 展的对流行定 ( 例 如 , "sample") 要 播 MP3 或者 ID3,你必在流 前 mp3 例 如 , "mp3:sample" 要 播 放 H.264/AAC 文,你必在 流前 mp4并指定文 扩 展 例 如 , 要 播 放 sample.m4v 文 , 定 "mp4:sample.m4v" Start 数 一个选的参数,秒单 定开始时间默认值 -2,
表示用户首先尝试播放流段中定的直播流如果那个的直播流没有找到,它将播放的录制流如果没有那个的录制流,客户端将等一个新的那个的直播流,并当有效时行播放如果你在 Start 段中传 递 -1,那就播放流中定的那个的直播流如果 你 在 Start 段中 传递 0 或一个整数,那将从 Start 段定的时间开始播放流中定的那个录制流如果没有找到录制流,那将播放播放列表中的一 Duration 数 一个选的参数,秒单定了回放的持续时间默认值 -1-1 值意味着一个直播流会一直播放直到它不用或者一个录制流一直播放直到结束如果你传递 0 值,它将播放单一一,因播放时间已经在录制流的开始的 Start 段指定了假 定 定 在 Start 段 中 的 值 大于或者等于 0如果你传递 一个数,将播放 Duration
段定的一段直播流之,播放状态,或者播放 Duration 段 定 的 一 段 录 制 流 ( 如 果 流 在 Duration 段 定 的时间段内结束,那流结束时回放结束)如果你在 Duration 段 中 传 递 一 个 -1 外 的 负数 的话,它将把你给的值当做 -1 处理 Reset 布尔 一个选的布尔值或者数定了是否对前的播放列表行 flush

命执行时的消息流动是

1. 当客户端从服器端接收到 createStream 命的结果是 success 时,发 play 命

2. 一旦接收到 play 命,服器端发一个协议消息来设置块大小

3. 服 器 端 发 另 一 个 协 议 消 息 ( 用 户 控 制 ) , 个 消 息 中 定 了 'StreamIsRecorded' 和流 ID消息在前两个节中保类型,在四个节中保 流 ID

4. 服器端发另一个协议消息 (用户控制),一消息包 'StreamBegin' , 来指示发给客户端的流的起点

5. 如 果 客 户 端 发 的 play 命 , 服 器 端 发 一 个 onStatus 命 消 息 NetStream.Play.Start & NetStream.Play.Reset有当客户端发的 play 命设置了 reset 时 服器端才会发 NetStream.Play.Reset如果要播放的流没有找到,服器端发 onStatus 消息 NetStream.Play.StreamNotFound

之,服器端发视频和音频数据,客户端对行播放


7.2.2.2. play2

不于 play 命的是,play2 在不改播放内容时间轴的情况换到不的比 特率服器端客户端在 play2 中求所有支持的码率维了不的段

客户端发给服器端的命结构如

段 类型 述 Command Name 符串 命,设置 "play2" Transaction ID 数 ID 设置 0 Command Object Null 命信息不在,设置 null 类型 Parameters 对象 一个 AMF 编码的对象,对 象 的 属 性 是 开 的 flash.net.NetStreamPlayOptions ActionScript 对象所述的属 性


NetStreamPlayOptions 对象的开属性在 ActionScript 3 语言指南中 [AS3] 有所述


命执行时的消息流动如图所示




7.2.2.3. deleteStream 命

当 NetStream 对象消亡时 NetStream 发 deleteStream 命

客户端发给服器端的命结构如




段 类型 述 Command Name 符串 命 , 设 置 "deleteStream" Transaction ID 数 ID 设置 0 Command Object Null 命信息对象不在,设 null 类型 Stream ID 数 服器端消亡的流 ID


服器端不发任何回复

7.2.2.4. receiveAudio 命

NetStream 通过发 receiveAudio 消息来通知服器端是否发音频到客户端

客户端发给服器端的命结构如

段 类型 述 Command Name 符串 命 , 设 置 "receiveAudio" Transaction ID 数 ID 设置 0 Command Object Null 命信息对象不在,设置 null 类型 Bool Flag 布尔 true 或 者 false 表 明 是 否 接音频


如果发来的 receiveAudio 命布尔段被设 false 时服器端不发任何回复 如 果 一 标 识 被 设 true , 服 器 端 状 态 消 息 NetStream.Seek.Notify 和 NetStream.Play.Start 行回复

7.2.2.5. receiveVideo 命

NetStream 通过发 receiveVideo 消息来通知服器端是否发视频到客户端

客户端发给服器端的命结构如




段 类型 述 Command Name 符串 命 , 设 置 "receiveVideo" Transaction ID 数 ID 设置 0 Command Object Null 命信息对象不在,设置 null 类型 Bool Flag 布尔 true 或 者 false 表 明 是 否 接视频


如果发来的 receiveVideo 命布尔段被设 false 时服器端不发任何回复 如 果 一 标 识 被 设 true , 服 器 端 状 态 消 息 NetStream.Seek.Notify 和 NetStream.Play.Start 行回复

7.2.2.6. publish 命

客户端发给服器端一命发布一个已命的流使用个,任意客户端都
播放个流,并接发布的音频视频数据消息

客户端发给服器端的命结构如

段 类型 述 Command Name 符串 命,设置 "publish" Transaction ID 数 ID 设置 0 Command Object Null 命信息对象不在,设置 null 类型 Publishing Name 符串 发布的流的 Publishing Type 符串 发 布 类 型 设 置 "live" "record" 或 者 "append"record流被发布,
数据被录制到一个新的文
新文被储在服器包
服用目录的子路如
果 文 已 在 , 将 写
append流被发布,数据被添
到一个文如果文没
找着,将新建一个live直
播数据被发布,并不对
行录制


服器端回复 onStatus 命标注发布的起始置

7.2.2.7. seek 命

客户端发 seek 命查找一个多媒体文或一个播放列表的偏移量 (毫秒单 )

客户端发到服器端的命结构如

段 类型 述 Command Name 符串 命的,设 "seek" Transaction ID 数 ID 设 0 Command Object Null 没有命信息对象,设置 null 类型 milliSeconds 数 播放列表查找的毫秒数


seek 命执行时服器会发一个状态消息 NetStream.Seek.Notify失败的话, 服器端返回一个 _error 消息


7.2.2.8. pause 命

客户端发 pause 命告知服器端是暂停是开始播放

客户端发给服器端的命结构如

段 类型 述 Command Name 符串 命,设 "pause" Transaction ID 数 没有一命的 ID,设 0 Command Object Null 命信息对象不在,设 null 类型 Pause/Unpause Flag 布尔 true 或者 false,来指示暂停 或者新播放 milliSeconds 数 流暂停或者新开始所在的
毫秒数个是客户端暂停的
当前流时间当回放已恢复
时,服器端值发有比
个值大的 timestamp 消息

当 流 暂 停 时 , 服 器 端 发 一 个 状 态 消 息 NetStream.Pause.Notify NetStream.Unpause.Notify 有针对没有暂停的流行发放失败的话,服器端返回一个 _error 消息

7.3. 消息交换例子

有几个解释使用 RTMP 交换消息的例子

7.3.1. 发布录制视频

个例子说明了一个客户端是如何能够发布一个直播流然传递视频流到服器的然
他客户端对发布的流行阅并播放视频



7.3.2. 广播一个共享对象消息

个例子说明了在一个共享对象的创建和改期间交换消息的化它也说明了共享对
象消息广播的处理过程 

7.3.3. 发布来自录制流的元数据

个例子述了用于发布元数据的消息交换


8. 参考文献

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,RFC 793, September 1981.

[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[AS3] Adobe Systems, Inc., "ActionScript 3.0 Reference for the Adobe Flash Platform", 2011, <http://www.adobe.com/devnet/actionscript/documentation.html>.

[AMF0] Adobe Systems, Inc., "Action Message Format -- AMF 0", December 2007, <http://opensource.adobe.com/wiki/download/attachments/1114283/amf0_spec_121207.pdf>.

[AMF3] Adobe Systems, Inc., "Action Message Format -- AMF 3", May 2008, <http://opensource.adobe.com/wiki/download/attachments/1114283/amf3_spec_05_05_08.pdf>.

原文地址:https://www.cnblogs.com/bugutian/p/10773249.html