此文件是想到哪寫到哪：參考文件：

https://www.cnblogs.com/shishuo365/p/5862613.html

一些控制協議訊息（訊息型別ID可以在下列文件中查詢）

https://blog.csdn.net/lipengshiwo/article/details/53267674

原始碼檔案參考：

https://blog.csdn.net/leixiaohua1020/article/details/42105049

客戶端和伺服器互動文件：

https://www.cnblogs.com/zjoch/archive/2013/08/28/3286301.html

在傳輸的過程中以流為單位，但流又細分為塊，所以傳輸基本的大小是塊。（程式中設定也為塊）：

為什麼設定為塊（一般為128（可以動態設定，在RTMP_Init函式中））：塊太大會早成視訊幀阻塞，造成卡頓，塊太小會傳輸太多的塊頭，減小了訊息的傳輸。

1：rtmp傳輸的基本格式：（塊格式）（塊頭+資料）（該格式很重要）

塊頭=基本頭+訊息頭+擴充套件時間戳+塊資料

a：基本頭（1-3位元組）：塊流ID和塊型別

    （在這還要知道塊頭型別（塊型別值為0.1.2.3），然後設定塊流ID（簡稱CSID））

     1位元組：2~63的塊流ID      2位元組64~319的塊流ID  3位元組64~65599位元組的塊流ID。

b：塊訊息頭（0.3.7.11位元組）：被髮送的訊息，由塊頭型別決定（基本頭中的塊頭型別引數）

        根據型別欄位來確定訊息頭的大小1：型別0:11位元組

         時間戳（3位元組）+訊息長度（3）+訊息型別ID（1）+訊息流ID（4）

        型別為0的塊，此欄位必須為絕對時間戳。如果時間戳大於等於16777215(0xFFFFFF)，此欄位的取值必須為16777215，並且與擴充套件時間戳一起組成32位元的完整時間戳。如果時間戳小於16777215，那麼此欄位代表了完整的時間戳

       訊息長度：，實際傳送的資料。塊的總長度：：：：注意（不是塊本身的長度）

       訊息型別ID：傳送資料的種類：音訊（是8），視訊（是9）等引數，

        訊息流ID：該塊所在的流的ID值。根據該ID將塊組裝成訊息。

        其他型別省略：

c：擴充套件時間戳：取決於訊息頭中編碼的時間戳。

            chunk中會有時間戳timestamp和時間戳差timestamp delta，並且它們不會同時存在，只有這兩者之一大於3個位元組能表示的最大數值0xFFFFFF＝16777215時，才會用這個欄位來表示真正的時間戳，否則這個欄位為0。擴充套件時間戳佔4個位元組，能表示的最大數值就是0xFFFFFFFF＝4294967295。當擴充套件時間戳啟用時，timestamp欄位或者timestamp delta要全置為1，表示應該去擴充套件時間戳欄位來提取真正的時間戳或者時間戳差。注意擴充套件時間戳儲存的是完整值，而不是減去時間戳或者時間戳差的值

d：塊資料：當前塊的有效資料。