RTMP協議分析及H.264打包原理
RTMP協議是一個網際網路五層體系結構中應用層的協議。RTMP協議中基本的資料單元稱為訊息（Message）。當RTMP協議在網際網路中傳輸資料的時候，訊息會被拆分成更小的單元，稱為塊（Chunk）。
一.定義
Payload(載荷)：包含於一個數據包中的資料，例如音訊取樣或者視訊壓縮資料。
Packet(資料包)：一個數據包由固定頭和載荷資料構成。一些底層協議可能會要求對資料包進行封裝。
Port(埠)：TCP/IP使用小的正整數對埠進行標識。OSI傳輸層使用的運輸選擇器 (TSEL) 相當於埠。
Transport address(傳輸地址)：用以識別傳輸層端點的網路地址和埠的組合，例如一個IP地址和一個TCP埠。
Message stream(訊息流)：通訊中訊息流通的一個邏輯通道。
Message stream ID(訊息流ID)：每個訊息有一個關聯的ID，使用ID可以識別出該訊息屬於哪個訊息流。
Chunk(塊)：訊息的一段。訊息在網路傳送之前被拆分成很多小的部分。塊按照時間戳的順序進行端到端的傳輸。
Chunk stream(塊流)：通訊中允許塊流向一個特定方向的邏輯通道。塊流可以從客戶端流向伺服器，也可以從伺服器流向客戶端。
Chunk stream ID(塊流 ID)：每個塊有一個關聯的ID，使用ID可以識別出該塊屬於哪個塊流。
Multiplexing(合成)：將獨立的音訊/視訊資料合成為一個連續的音訊/視訊流，這樣就可以同時傳送視訊和音訊了。
DeMultiplexing(分解)：Multiplexing 的逆向處理，將交叉的音訊和視訊資料還原成原始音訊和視訊資料的格式。
Remote Procedure Call(RPC 遠端方法呼叫)：允許客戶端或伺服器呼叫對端的一個子程式或者程式的請求。
Metadata(元資料)：關於資料的描述。比如電影的 metadata 包括電影標題、持續時間、建立時間等等。
Application Instance (應用例項)：應用例項運行於伺服器上，客戶端可連線這個例項併發送連線請求，連線伺服器。
Action Message Format (AMF，操作訊息格式)：AMF是Adobe獨家開發出來的通訊協議，它採用二進位制壓縮，序列化、反序列化、傳輸資料，從而為Flash 播放器與Flash Remoting閘道器通訊提供了一種輕量級的、高效能的通訊方式。如下圖所示。
AMF的初衷只是為了支援Flash ActionScript的資料型別，目前有兩個版本：AMF0和AMF3。AMF從Flash MX時代的AMF0發展到現在的AMF3。AMF3用作Flash Playe 9的ActionScript 3.0的預設序列化格式，而AMF0則用作舊版的ActionScript 1.0和2.0的序列化格式。在網路傳輸資料方面，AMF3比AMF0更有效率。AMF3能將int和uint物件作為整數（integer）傳輸，並且能序列化 ActionScript 3.0才支援的資料型別, 比如ByteArray，XML和Iexternalizable。
二.握手
握手以客戶端傳送C0和C1塊開始。
客戶端必須等待接收到S1才能傳送C2。
客戶端必須等待接收到S2才能傳送任何其他資料。
伺服器端必須等待接收到C0才能傳送S0和S1，也可以等待接收到C1再發送S0和S1。伺服器端必須等待接收到C1才能傳送S2。伺服器端必須等待接收到C2才能傳送任何其他資料。
1.C0和S0格式
C0和S0都是八位，即一個位元組，如下所示：
Version（8bits）：在C0中，它表示客戶端的RTMP版本；在S0中，它表示伺服器端的RTMP版本。RTMP規範目前將它定義為3。0—2用於早期的產品，已經被廢棄。4—31保留，用於RTMP未來版本。32—255禁止使用。
2.C1和S1格式
C1和S1都是1536個位元組，如下所示：
time（4位元組）：包含時間戳，該時間戳應該被用做本終端傳送的塊的起點。該欄位可以為0或者其他任意值。
zero（4位元組）：該欄位必須為0。
random data（1528位元組）：該欄位可以包含任意值。終端需要區分出是它發起的握手還是對端發起的握手，所以這該欄位應該傳送一些足夠隨機的數。
3.C2和S2格式
C2和S2也都是1536個位元組，幾乎是C1和S1的副本，如下所示：
time（4位元組）：包含時間戳，必須與C1或S1中的時間戳相同。
time2（4位元組）：包含時間戳，必須與前一個C1或S1中的時間戳相同。
random echo（1528位元組）：該欄位必須與S1或者S2中的隨機數相同。
4.握手示意圖
三.塊
握手之後，連線開始對一個或多個塊流進行合併。每個塊都有一個唯一ID對其進行關聯，這個ID叫做chunk stream ID(塊流ID)。這些塊通過網路進行傳輸，在傳送端，每個塊必須被完全傳送才可以傳送下一塊。在接收端，這些塊根據塊流ID被組裝成訊息。
每個塊都是由塊頭和塊資料體組成，而塊頭自身也是由三部分組成，塊格式如下所示：
Basic Header（基本頭，1—3位元組）：該欄位編碼了塊流ID和塊型別。塊型別決定了Message Header（訊息頭）的編碼格式。該欄位長度完全取決於塊流ID，因為塊流ID是一個可變長度的欄位。
Message Header（訊息頭，0、3、7或11位元組）：該欄位編碼了訊息的相關資訊，標識了塊資料所屬的訊息。該欄位的長度由塊型別決定。
Extended Timestamp（擴充套件時間戳，0或4位元組）：該欄位只在特定情況下出現。
Chunk Data（塊資料，可變大小）：塊的載荷部分，取決於配置的最大塊尺寸，一般為128位元組。
1.Basic Header
塊基本頭對塊型別(用fmt 欄位表示，參見下圖) 和塊流ID（chunk stream ID）進行編碼。fmt欄位佔2bits，取值範圍時0—3。RTMP協議最多支援65597個流，流的ID範圍是3—65599。ID值0、1和2被保留，0表示兩位元組形式，1表示三位元組形式，2的塊流ID被保留，用於下層協議控制訊息和命令。
☆一位元組形式
ID取值範圍2—63，0和1用於標識多位元組形式。
☆兩位元組形式
第一個位元組中cs id為0，表示有兩個位元組
ID取值範圍64—319，即第二個位元組+64。
☆三位元組形式
第一個位元組中cs id為1，表示有三個位元組
ID取值範圍64—65599，即第三個位元組*256+第二個位元組+64。
2.Message Header
有四種類型的塊訊息頭，由塊基本頭中的“fmt”欄位決定。
☆型別0
由11個位元組組成，必須用於塊流的起始塊或者流時間戳重置的時候。
timestamp（3位元組）：訊息的絕對時間戳，如果大於等於16777215（0xFFFFFF），該欄位仍為16777215，此時Extend Timestamp（擴充套件時間戳）欄位存在，用於對溢位值進行擴充套件。否則，該欄位標識整個時間戳，不需要擴充套件。
message length（3位元組）：通常與塊載荷的長度不同，塊載荷長度通常表示塊的最大長度128位元組（除了最後一個塊）和最後一個塊的剩餘空間。
message type id（1位元組）：訊息型別。
message stream id（4位元組）：該欄位用小端模式儲存。
☆型別1
由7個位元組組成，不包括message stream ID（訊息流ID），此時塊與之前的塊取相同的訊息流ID。可變長度訊息的流(例如，一些視訊格式)應該在第一塊之後使用這一格式表示之後的每個新塊。
timestamp delta（3位元組）：前一個塊時間戳與當前塊時間戳的差值，即相對時間戳，如果大於等於16777215（0xFFFFFF），該欄位仍為16777215，此時Extend Timestamp（擴充套件時間戳）欄位存在，用於對溢位值進行擴充套件。否則，該欄位標識整個差值，不需要擴充套件。
message length（3位元組）：通常與塊載荷的長度不同，塊載荷長度通常表示塊的最大長度（除了最後一個塊）和最後一個塊的剩餘空間。該長度是指為塊載荷AMF編碼後的長度。
message type id（1位元組）：訊息型別。
☆型別2
由3個位元組組成，既不包括message stream ID（訊息流ID），也不包括message length（訊息長度），此時塊與之前的塊取相同的訊息流ID和訊息長度。固定長度訊息的流(例如，一些音訊格式)應該在第一塊之後使用這一格式表示之後的每個新塊。
timestamp delta（3位元組）：前一個塊時間戳與當前塊時間戳的差值，如果大於等於16777215（0xFFFFFF），該欄位仍為16777215，此時Extend Timestamp（擴充套件時間戳）欄位存在，用於對溢位值進行擴充套件。否則，該欄位標識整個差值，不需要擴充套件。
☆型別3
沒有訊息頭，從之前具有相同塊流ID的塊中取相應的值。當一條訊息被分割成多個塊時，所有的塊（除了第一個塊）應該使用這種型別。
3.Extended Timestamp（4位元組）
只有當塊訊息頭中的普通時間戳設定為0x00ffffff時，本欄位才被傳送。如果普通時間戳的值小於0x00ffffff，那麼本欄位一定不能出現。當最近的具有同一塊流ID，型別 0、1 或 2 塊的Extended Timestamp 欄位出現時，這一欄位才會在型別為 3 的塊中出現。當擴充套件時間戳啟用時，timestamp欄位或者timestamp delta要全置為1，表示應該去擴充套件時間戳欄位來提取真正的時間戳或者時間戳差。注意擴充套件時間戳儲存的是完整值，而不是減去時間戳或者時間戳差的值。
4.例子
☆不分割訊息
從上面兩個表中可以看出，從訊息3開始，資料處理得到優化，此時Chunk除了載荷以外，只多了一個塊基本頭。
☆分割訊息
當訊息的載荷長度超過128位元組時，需要將訊息分割為若干個塊進行傳輸。
從上面兩個例子可以看出，塊型別3有兩種用法。一個是指定一個新訊息的訊息頭可以派生自已經存在的狀態資料（例一），另一個是指定訊息的連續性（例二）。
四.訊息
訊息是RTMP協議中基本的資料單元。不同種類的訊息包含不同的Message Type ID，代表不同的功能。RTMP協議中一共規定了十多種訊息型別，分別發揮著不同的作用。例如，Message Type ID在1-6的訊息用於協議控制，這些訊息一般是RTMP協議自身管理要使用的訊息，使用者一般情況下無需操作其中的資料。Message Type ID為8，9的訊息分別用於傳輸音訊和視訊資料。Message Type ID為15-20的訊息用於傳送AMF編碼的命令，負責使用者與伺服器之間的互動，比如播放，暫停等等。
1.訊息頭
訊息頭（Message Header）有四部分組成：標誌訊息型別的Message Type ID，標誌載荷長度的Payload Length，標識時間戳的Timestamp，標識訊息所屬媒體流的Stream ID。訊息的格式如下所示。
2.載荷
載荷是訊息包含的實際資料，它們可能是音訊取樣資料或者是視訊壓縮資料。
由於端與端之間實際傳輸的是塊，所以只需要將載荷加上塊頭封裝成塊。實際應用中，無擴充套件時間戳，一位元組形式的塊基本頭就能滿足要求，整個塊頭滿足以下四種長度：
fmt=0：Basic Head+Message Head=1+11=12
fmt=1：Basic Head+Message Head=1+7=8
fmt=2：Basic Head+Message Head=1+3=4
fmt=3：Basic Head+Message Head=1+0=1
需要注意的是，當載荷為H.264資料時，要使用AMF3進行編碼（即序列化），關於AMF3可以參考：AMF3中文版
五.協議控制訊息
RTMP塊流使用訊息型別ID 1、2、3、5、6作為協議控制訊息。這些訊息包含了必要的RTMP塊流協議資訊。這些協議控制訊息必須使用0作為訊息流ID(這些流也被稱為控制流)，同時使用2作為塊流ID。協議控制訊息接收立即生效；解析時，時間戳欄位被忽略。
1.設定塊大小訊息（Message Type=1）
設定塊大小，被用來通知對方新的最大塊大小。
預設最大塊大小為128位元組，客戶端和伺服器可以使用此訊息來修改預設的塊大小。例如，假設客戶端想要傳送的音訊資料大小為131位元組，而塊大小為128位元組。在這種情況下，客戶端可以通知伺服器新的塊大小為131位元組，然後就可以使用一個塊來發送完整的音訊資料了。
最大的塊大小建議至少為128位元組，但必須至少為1位元組。通訊的每一個方向(例如從客戶端到伺服器)擁有獨立的塊大小設定。最大的塊大小由通訊雙方 (伺服器或者客戶端) 自行維護。
0：此位必須為 0。
chunk size (塊大小，31 位)：這一欄位儲存新的最大塊大小值，以位元組為單位，傳送端之後將使用此值作為最大的塊大小，直到收到 (關於最大塊大小的) 通知。有效值為1到 2147483647(0x7FFFFFFF，1和2147483647都可取)； 但是所有大於16777215(0xFFFFFF) 值是等價的，因為沒有一個塊比一整個訊息大，並且沒有一個訊息會大於16777215位元組。
2.終止訊息（Message Type=2）
終止訊息，用於通知對端，如果正在等待一條訊息的部分塊(已經接收了一部分)，那麼可以丟棄之前已經接收到的塊。對端將接收到的塊流ID作為當前協議控制訊息的有效負載。應用程式可能會在關閉的時候傳送這個訊息以指示不需要進一步對這個訊息的處理了。
chunk stream ID (塊流 ID，32 位)：這一欄位儲存塊流 ID，該流的當前訊息會被丟棄。
3.確認訊息（Message Type=3）
客戶端或者伺服器在接收到等同於視窗大小的位元組之後必須傳送給對端一個確認訊息。視窗大小是指傳送者在沒有收到接收者確認訊息之前傳送的最大位元組數。這個訊息定義了序列號，也就是到目前為止接收到的位元組數。
sequence number (序列號，32 位)：這一欄位儲存到目前為止接收到的位元組數。
4.確認視窗大小訊息（Message Type=5）
在傳送確認訊息（Message Type ID=4）的時候，客戶端或者伺服器端傳送這條訊息來通知對端要使用的視窗大小（也就是說這條訊息可以重置視窗大小）。傳送者在傳送等於視窗大小的資料之後，等待對端的確認。接收端必須傳送一個確認訊息，在會話開始時，或從上一次傳送確認訊息之後接收到了等於視窗大小的資料。
5.設定對端頻寬訊息（Message Type=6）
客戶端或者伺服器端傳送這一訊息來限制其對端的輸出頻寬。對端接收到這一訊息後限制其輸出頻寬，這是通過限制已傳送但未被確認的資料量不超過本訊息所給出的視窗大小來實現的。接收到這一訊息的對端應該回復一個確認視窗大小訊息（Message Type ID=5）—如果這個視窗大小不同於上一條它傳送給“傳送者”的設定對端頻寬訊息。
限制類型取以下列值之一：
0 - Hard：對端應該限制其輸出頻寬不超過指定的視窗大小。
1 - Soft：對端應該限制其輸出頻寬不超過指定的視窗大小，或者已經有限制在起作用的話，就取兩個視窗大小之間的較小值。
2 - Dynamic：如果先前的限制類型為 Hard，則這條訊息的也被視為Hard訊息，否則的話忽略這條訊息。
六.使用者控制訊息（Message Type=4）
RTMP使用訊息型別ID 4表示使用者控制訊息。這些訊息包含RTMP流傳輸層所使用的資訊。協議控制訊息使用的ID為 1、2、3、5 和 6 (前面已經介紹過了)。
使用者控制訊息應該使用訊息流ID 0 (以被認為是控制流)，並且以RTMP塊流傳送時以塊流ID為2。協議控制訊息接收立即生效；解析時，時間戳欄位被忽略。
客戶端或者伺服器端傳送這個訊息來通知對端一些使用者控制事件。這一訊息攜帶有事件型別和事件資料。
負載的前兩個位元組用於指示事件型別。事件型別後面緊跟著事件資料。事件資料欄位的大小是可變的。但是，如果這條訊息必須通過 RTMP 塊流層傳輸時，最大塊大小 (前面已經介紹了) 應該足夠大以允許這些訊息填充在一個單一塊中。
支援的事件型別如下所示：
| 事件 | 描述 |
| Stream Begin (=0) | 伺服器傳送這個事件來通知客戶端一個流已就緒並可以用來通訊。預設情況下，這一事件在成功接收到客戶端的連線命令之後以ID=0傳送。事件資料為4位元組，代表了已就緒流的流ID。 |
| Stream EOF (=1) | 伺服器傳送這一事件來通知客戶端請求的流的資料回放已經結束。在傳送額外的命令之前不再發送任何資料。客戶端將丟棄接收到的這個流的訊息。事件資料為4位元組，代表了回放已結束的流的流 ID。 |
| StreamDry (=2) | 伺服器傳送這一事件來通知客戶端當前流中已沒有資料。當伺服器在一段時間內沒有檢測到任何訊息，它可以通知相關客戶端當前流已經沒資料了。這一事件資料為4位元組，代表了已沒資料的流的流 ID。 |
| SetBuffer Length (=3) | 客戶端傳送這一事件來通知伺服器緩衝區大小 (以毫秒為單位)，這個緩衝區用於快取來自流的任何資料。此事件在伺服器開始處理流之前就傳送。事件資料的前4個位元組代表了流ID，緊接其後的4個位元組代表了以毫秒為單位的緩衝區的長度。 |
| Streams Recorded (=4) | 伺服器傳送這一事件來通知客戶端當前流是一個錄製流。事件資料為4位元組，代表了錄製流的流 ID。 |
| PingRequest (=6) | 伺服器端傳送這一事件用於測試客戶端是否可達。事件資料是為一個4位元組的時間戳，代表了伺服器端傳送這一命令時的伺服器本地時間。客戶端在接收到這一訊息後會立即傳送 PingResponse 回覆。 |
|
PingResponse （=7） |
客戶端傳送這一事件用於回覆伺服器的PingRequest。事件資料是為一個4位元組的時間戳，該時間戳是從接收到的PingRequest的事件資料中獲取的。 |
七.RTMP命令訊息
這一節介紹了在服務端和客戶端通訊互動時使用的不同型別訊息和命令。
服務端和客戶端交換的不同訊息型別包括用於傳送音訊資料的音訊訊息、用於傳送視訊資料的視訊訊息、用於傳送任意使用者資料的資料訊息、共享物件訊息以及命令訊息。共享物件訊息提供了一個通用的方法來管理多使用者和一臺伺服器之間的分散式資料。命令訊息在客戶端和服務端傳輸 AMF 編碼的命令。客戶端或者服務端可以使用命令訊息向對端請求遠端過程呼叫 (RPC)。
1.資料訊息（Message Type=18或15）
客戶端和服務端使用該訊息向對端傳送metadata，metadata包括資料（音訊、視訊等）的詳細資訊，比如建立時間，時長，主題等等。AMF0 編碼時，訊息型別為18；AMF3編碼時，訊息型別為15。
2.共享物件訊息 (Message Type=19或16)
所謂共享物件其實是一個 Flash 物件 (一個名值對的集合)，這個物件在多個不同客戶端、應用例項中保持同步。AMF0
編碼時，訊息型別為19；AMF3編碼時，訊息型別為16。每條訊息可以包含多個事件。
支援的事件型別如下所示：
| 事件 | 描述 |
|---|---|
| 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) | 伺服器端傳送給客戶端這一事件表示連線成功。 |
3.音訊訊息 (Message Type=8)
客戶端和服務端使用該訊息向對端傳送音訊資料。
4.視訊訊息 (Message Type=9)
客戶端和服務端使用該訊息向對端傳送視訊資料。
5.聚合訊息（Message Type=22）
聚合訊息是包含一系列子訊息的單個訊息。
聚合訊息的訊息流ID將覆蓋訊息聚合內的子訊息的流ID。
聚合訊息與第一條子訊息時間戳的區別是偏移量，它用於將子訊息的時間戳重新歸一到流時間表。偏移量被新增到每個子訊息的時間戳以達到歸一化流時間。 第一個子訊息的時間戳應該與聚合訊息的時間戳相同，所以偏移應該為零。
返回指標包含前一個訊息的大小，包括它的訊息頭。 包含訊息頭是為了與FLV檔案的格式相匹配和用於向後查詢（backward seek）。
使用聚合訊息具有以下效能優勢：
☆可以在通過一個塊傳送一條完整的訊息。因此，增加塊大小並使用聚合訊息可以減少傳送的塊數。
☆子訊息能在記憶體中連續儲存。這樣在呼叫系統函式通過網路傳送資料時，會更加高效。
6.命令訊息（Message Type=20或17）
命令訊息在客戶端和伺服器傳遞 AMF 編碼的命令。AMF0 編碼時，訊息型別為20；AMF3編碼時，訊息型別為17。傳送這些訊息是為了進行一些操作，比如，連線，建立流，釋出，播放，暫停。命令訊息，像 onstatus、result 等等，用於通知傳送者請求命令的狀態。一個命令訊息由命令名、業務 ID 和包含相關引數的命令物件組成。客戶端或者服務可以使用命令訊息向對端請求遠端過程呼叫
(RPC)。
客戶端和伺服器交換 AMF 編碼的命令。傳送端傳送一個命令訊息，它由命令名、業務ID以及包含有相關引數的命令物件組成。例如，包含有 'app' 引數的連線命令，這個引數指明瞭客戶端將要連線的伺服器應用名字。接收者處理這一命令並回發一個同樣業務ID的回覆。回覆字串可以是 _result、_error 或者 一個方法名，比如，verifyClient 或者 contactExternalServer。
以下類物件可用於傳送多種不同的命令：
NetConnection 代表伺服器和客戶端之間連線的物件。
NetStream 代表傳送音訊流、視訊流和其他相關資料的通道的物件。當然，我們也會發送控制資料流的命令，比如 play、pause 等等。
6.1.NetConnection相關命令
NetConnection 管理著一個客戶端應用和伺服器之間的雙相連線。此外，它還提供遠端方法的非同步呼叫。
NetConnection 可用於傳送以下命令：
☆connect
☆call
☆close
☆createStream
6.1.1.connect
客戶端傳送connect命令到伺服器，請求連線到伺服器的應用例項。
由客戶端傳送到伺服器的connect命令結構如下：
| 欄位名 | 型別 | 描述 |
| Command Name | 字串 | 命令名，設定為 "connect"。 |
| Transaction ID | 數字 | 業務ID，總是設定為 1。 |
| Command Object | 物件 | 具有名值對的命令物件。 |
| Optional User Arguments | 物件 | 任意可選資訊。 |
|
屬性 |
類 型 |
描述 | 範例 |
| app | 字串 | 客戶端連線到的伺服器應用的名字。 | testapp |
| flashver | 字串 | Flash Player版本號。和ApplicationScript getversion()方法返回的是同一個字串。 | FMSc/1.0 |
| swfUrl | 字串 | 進行當前連線的SWF檔案的URL。 | file://C:/FlvPlayer.swf |
| tcUrl | 字串 | 伺服器的URL。具有以下格式：protocol://servername:port/appName/appInstance | rtmp://localhost:1935/testapp/instance1 |
| fpad | 布林 | 如果使用了代理，為 true。 | true或者false。 |
| audioCodecs | 數字 | 指明客戶端所支援的音訊編碼。 | SUPPORT_SND_MP3 |
| videoCodecs | 數字 | 指明支援的視訊編碼。 | SUPPORT_VID_SORENSON |
| videoFunction | 數字 | 指明所支援的特殊視訊功能。 | SUPPORT_VID_CLIENT_SEEK |
| pageUrl | 字串 | SWF檔案所載入網頁的URL。 | http://somehost/sample.html |
| objectEncoding | 數字 | AMF編碼方式。 | AMF3 |
audioCodecs屬性的標記值
videoCodecs屬性的標記值
videoFunction屬性的標記值
objectEncoding屬性的值
由伺服器傳送到客戶端的connect命令結構如下：
| 欄位名 | 型別 | 描述 |
| Command Name | 字串 | 命令名，_result或_error。指明回覆的是result還是error |
| Transaction ID | 數字 | 業務ID，總是設定為 1。 |
| Properties | 物件 | 名值對，描述連線的屬性（fmsver等）。 |
| Information | 物件 | 名值對，描述來自伺服器的回覆。‘code’、‘level’、‘description’等是資訊的名字 |
命令執行時的訊息流如下：
1. 客戶端傳送connect命令到伺服器以請求對伺服器應用例項的連線。
2. 收到 connect命令後，伺服器傳送協議控制訊息 '確認視窗大小' 到客戶端。伺服器端也會連線到connect命令中提到的應用。
3. 伺服器端傳送協議控制訊息 '設定對端頻寬' 到客戶端。
4. 在處理完協議控制訊息 '設定對端頻寬' 之後，客戶端傳送協議控制訊息 '視窗確認大小' 到伺服器端。
5. 伺服器端傳送使用者控制訊息 (StreamBegin) 到客戶端。
6. 伺服器端傳送結果（ _result）命令訊息告知客戶端連線狀態 (success/fail)。這一訊息指定了業務 ID (connect 命令通常將其設定為1)。這一訊息還定義了一些屬性，比如 FMS 伺服器版本 (字串)。此外，它定義了其他與連線響應相關的資訊，比如 level (字串)、code (字串)、description (字串)、objectencoding (數字) 等等。
6.1.2.Call
NetConnection物件的call方法在接收端執行遠端過程呼叫 (PRC)。被呼叫的PRC名字作為一個引數傳給呼叫命令。
傳送端傳送給接收端的命令結構如下：
| 欄位名 | 型別 | 描述 |
| Procedure Name | 字串 | 呼叫的遠端過程的名字。 |
| Transaction ID | 數字 | 如果期望回覆我們要給一個業務ID。否則我們傳0值即可。 |
| Command Object | 物件 | 如果存在一些命令資訊要設定這個物件，否則置空。 |