rtmp詳解

文件下載地址:html

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

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

 

本文直接從中文的PDF上覆制而來,無配圖,請下載中文的zip解壓成pdf以後查看。 app

 

RTMP 協議 Adobe 官 方規範
By, Defonds
Blog, http://blog.csdn.net/defonds
Email, defonds@163.com dom

1. 簡介
Adobe 的實時消息傳輸協議 (RTMP) 經過一個靠地流傳輸供了一個向多通 道消息服,好比 TCP [RFC0793],意圖在通訊端之間傳遞有時間信息的視頻音頻和
數據消息流實一般對不類型的消息配不的優先級,當載能力有限時,會影響
等流傳輸的消息的次序 本文檔將對實時流傳輸協議 (Real Time Messaging Protocol) 的語法和操做行述

2. 貢獻者
Rajesh Mallipeddi,Adobe Systems 原員,起草了本文檔原始規範,並供大部的 原始內容 Mohit Srivastava,Adobe Systems 員,促了本規範的開發

3. 詞解釋
Payload (有效載荷)包於一個數據包中的數據,例如音頻採樣或者壓縮的視頻數據 payload 的格式和解釋,超出了本文檔的範圍
ide

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,或者放握手

ui

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>.

相關文章
相關標籤/搜索