這段時間，工作上的需要，在RTMP上做了flv流到標准h264、AAC的轉換，服務器是開源項目CRTMPSERVER，客戶端flex編寫，視頻編碼h264，音頻編碼AAC，現將一些協議相關的東西記錄如下。
一、分析FLV數據
我們先拿一個flv文件來簡單分析一下flv數據的格式
flv標准文檔下載地址http://www.cnblogs.com/chef/archive/2012/07/18/2597003.html
flv文件分析器flvprase下載地址http://www.cnblogs.com/chef/archive/2012/07/18/2596930.html
本文重點不在於此，這塊就跳過了。相信大家對照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就可以播放了，下載地址
http://www.cnblogs.com/chef/archive/2012/07/18/2597008.html
后記：本人接觸音視頻行業不久，故文中內容不一定完全正確，如果你發現問題，請一定指出謝謝。另文中有極少部分內容有參考網絡上一些資料，但實找不出資料原始出處，索性不寫引自何處。