Real Time Messaging Protocol（實時消息傳送協議協議)是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸開發的私有協議。 我們公司的平台都是采用的這個協議進行的音視頻的播放
RTMP協議是一個基於TCP的高層協議族（所以wireshark抓包的時候應該選擇tcp進行抓包）
在RTMP協議中信令和媒體數據都稱之為Message，在網絡中傳輸這些Message，為了區分它們肯定是要加一個Message head的，所以RTMP協議也有一個Message head，還有一個問題因為RTMP協議是基於TCP的，由於TCP的包長度是有限制的（一般來說不超過1500個字節），而RTMP的Message長度是有可能很大的，像一個視頻幀的包可能會有幾十甚至幾千K，這個問題就必然有一個分片的問題，在RTMP協議中對應的說法就是chunk，每一個Message + head都是由一個和多個chunk組成的。讓我們來結合實際例子來看一下 ：9see
這些都是頭信息，是用來說明這斷data從什么點開始播放用的
真正的音視頻播放在data里面
粗略帶過。現在從握手開始講解
握手流程：
握手返回的簽名
客戶和服務器通信
依次解釋一下
574-發送 rtmp_connect 命令
576 服務器返回服務器帶寬信息，本地所需帶寬信息，流開始標記，服務器返回連接成功消息 "NetConnection.Connect.Success"
577 告訴服務器本帶寬信息
579 設置緩沖區
578發送創建流請求
581 服務器返回創建流成功
584 發送播放文件消息 rtmp_play
AUDIOdata 解析
再來解釋下一下這個09后面的27
27（16）=0010 0111（2）
解讀就是
0010
0111 代表（7）也就是H.264 代表視頻采用H.264編碼 這個編碼對應的自己查吧~~
那么，
問題1.音頻是怎么跟視頻對齊的呢？
問題2. 如何根據這些數據來查我們視頻的相關信息呢？
RTMP的包頭上有幾個參數，
timestamp delta 直譯--數據軸三角洲 就是這段data 所播放的時間
tunestamp 時間軸
視頻數據 音頻數據
再看看一個參數 body size =1221大小知道了，時間知道，所以碼率就可以算出來了