這段時間，工作上的需要，在RTMP上做了flv流到標準h264、AAC的轉換，伺服器是開源專案CRTMPSERVER，客戶端flex編寫，視訊編碼h264，音訊編碼AAC，現將一些協議相關的東西記錄如下。

一、分析FLV資料

    我們先拿一個flv檔案來簡單分析一下flv資料的格式

    本文重點不在於此，這塊就跳過了。相信大家對照flv標準文件都能看懂flv資料格式，而且我也強烈建議想學習這塊知識的朋友先把這步的工作完成。

二、分析RTMP上行的h264視訊流

    在server上將上行視訊存成二進位制檔案（注意，一定要用二進位制形式儲存資料）如下圖（圖片所顯示的二進位制資料每行有16列資料，即從0至f，如顯示不完全，請單獨開啟圖片檢視）

    我使用的工具是notepad++（並安裝二進位制檢視外掛）

    如果你有做第一步的工作，不難看出rtmp中flv視訊流就是一個接著一個的Video tag——即FLV tag中去除頭資訊， 只保留video tag內容。

    我們對照flv標準文件來逐個分析

    17：1-keyframe  7-avc

    00：AVC sequence header -- AVC packet type

    00 00 00：composition time，AVC時，全0，無意義

    因為AVC packet type=AVC sequence header，接下來就是AVCDecoderConfigurationRecord的內容

    configurationVersion = 01

    AVCProfileIndication = 42

    profile_compatibility = 00

    AVCLevelIndication = 1f

    lengthSizeMinusOne = ff -- FLV中NALU包長資料所使用的位元組數，（lengthSizeMinusOne & 3）+1，實際測試時發現總為ff，計算結果為4，下文還會提到這個資料

    numOfSequenceParameterSets = E1 -- SPS 的個數，numOfSequenceParameterSets & 0x1F，實際測試時發現總為E1，計算結果為1

    sequenceParameterSetLength = 00 31 -- SPS 的長度，2個位元組，計算結果49

    sequenceParameterSetNALUnits = 67 42 80 1f 96 54 05 01 ed 80 a8 40 00 00 03 00 40 00 00 07 b8 00 00 20 00 00 03 01 00 01 fc 63 8c 00 00 10 00 　　　　　　　　　　　　　　　　　　　　00 03 00 80 00 fe 31 c3 b4 24 4d 40 -- SPS，為剛才計算的49個位元組， SPS中包含了視訊長、寬的資訊

    numOfPictureParameterSets = 01 -- PPS 的個數，實際測試時發現總為E1，計算結果為1

    pictureParameterSetLength = 00 04 -- PPS 的長度

    pictureParameterSetNALUnits = 68 ce 35 20 -- PPS 

    接下來又是新的一包videotag資料了

    17：1-keyframe  7-avc

    01：AVC NALU

    00 00 00：composition time，AVC時，全0，無意義

    因為AVCPacket type = AVC NALU，接下來就是一個或多個NALU

    每個NALU包前面都有（lengthSizeMinusOne & 3）+1個位元組的NAL包長度描述（前文提到的，還記得嗎），前面計算結果為4個位元組

    00 00 00 02 ：2 -- NALU length

    09 10：NAL包

    這裡插入一點NALU的小知識，每個NALU第一個位元組的前5位標明的是該NAL包的型別，即NAL nal_unit_type

#define NALU_TYPE_SLICE 1
#define NALU_TYPE_DPA 2
#define NALU_TYPE_DPB 3
#define NALU_TYPE_DPC 4
#define NALU_TYPE_IDR 5
#define NALU_TYPE_SEI 6
#define NALU_TYPE_SPS 7
#define NALU_TYPE_PPS 8
#define NALU_TYPE_AUD 9　　//訪問分隔符
#define NALU_TYPE_EOSEQ 10
#define NALU_TYPE_EOSTREAM 11
#define NALU_TYPE_FILL 12

    09&0x1f=9，訪問單元分隔符

    前面我們解析的sps頭位元組為67，67&0x1f = 7，pps頭位元組為68，68&0x1f=8，正好能對應上。

    00 00 00 29：說明接下來的NAL包長度為41

    06 00 11 80 00 af c8 00 00 03 00 00 03 00 00 af c8 00 00 03 00 00 40 01 0c 00 00 03 00 00 03 00 90 80 08 00 00 03 00 08 80：06&0x1f=6 -- SEI

    00 00 3c d0：接下來的NAL包長度

    65 88 80……：65&0x1f=5 -- I幀資料

    這包video tag分析到此結束了，下面會緊接著來一些該I幀對應的P幀資料， 見下圖

    看00003d80那行，前面的內容一直到53 4f 7f都是上一個video tag的內容，即前面說的65 88 80那個I幀的資料拉，27開始是新的一個video tag

    27：2-inter frame即P幀，7-codecid=AVC

    01：AVCPacket type = AVC NALU

    00 00 00：composition time，AVC時，全0，無意義

    00 00 00 02 09 30：跟上面分析的一樣拉，2個位元組的nal包，訪問單元分隔符

    00 00 00 11：17位元組的NAL包

    06 01 0c 00 00 80 00 00 90 80 18 00 00 03 00 08 80：06&0x1f=6-SEI

    00 00 46 85： NAL包資料長度

    41 9a 02……： 41&0x1f=1，P幀資料

三、轉換

    大致總結下flv h264流，按順序依次是

    1、一個video tag，包含的資訊：SPS，PPS，訪問單元分隔符，SEI，I幀包

    2、一個或多個video tag，包含的資訊：訪問單元分隔符，SEI，P幀包可為多個

    迴圈1、2

    這裡需要說明下，做轉換這一步時，我們只需要從videotag中獲取到所有的、一個一個的NAL包就可以了，至於它是I幀、P幀及其他型別，實際上我們並不需要關心，這裡只是為了更好的分析資料。

    h264的NALU和NALU之間是由00 00 01（也可以是00 00 00 01）分隔開的，我們組成h264之後的格式為

    1、00 00 00 01 SPS 00 00 00 01 PPS 00 00 00 01 訪問單元分隔符 00 00 00 01 SEI 00 00 00 01 I幀 00 00 00 01 P幀 00 00 00 01 P幀……（P幀數量不定）

    迴圈1

    其中的訪問單元分隔符和SEI不是必須的，將h264以二進位制的形式寫入檔案，使用Elecard StreamEye就可以播放了，下載地址

    後記：本人接觸音視訊行業不久，故文中內容不一定完全正確，如果你發現問題，請一定指出謝謝。另文中有極少部分內容有參考網路上一些資料，但實找不出資料原始出處，索性不寫引自何處。