最近一直在研究視頻實時查看播放 很遺憾 只成功了一半 記錄一下歷程 以便大家相互交流
項目需求是 GPS 視頻設備 連接服務器 將視頻流走RTP 協議發送到服務器 服務器將接收的視頻流 傳輸給客戶端 實時查看
1.第一步 上網查了一下 RTP是什么 參考 http://blog.csdn.net/chen495810242/article/details/39207305
2.第二步 上網查了 視頻是由什么組成的 參考 視頻編碼之I幀 、P幀、B幀 http://www.cnblogs.com/zhangming-blog/articles/6000518.html
視頻傳輸原理
視頻是利用人眼視覺暫留的原理，通過播放一系列的圖片，使人眼產生運動的感覺。單純傳輸視頻畫面，視頻量非常大，對現有的網絡和存儲來說是不可接受的。為了能夠使視頻便於傳輸和存儲，人們發現視頻有大量重復的信息，如果將重復信息在發送端去掉，在接收端恢復出來，這樣就大大減少了視頻數據的文件，因此有了H.264視頻壓縮標准。
在H.264壓縮標准中I幀、P幀、B幀用於表示傳輸的視頻畫面。
1、I幀
I幀又稱幀內編碼幀，是一種自帶全部信息的獨立幀，無需參考其他圖像便可獨立進行解碼，可以簡單理解為一張靜態畫面。視頻序列中的第一個幀始終都是I幀，因為它是關鍵幀。
2、P幀
P幀又稱幀間預測編碼幀，需要參考前面的I幀才能進行編碼。表示的是當前幀畫面與前一幀（前一幀可能是I幀也可能是P幀）的差別。解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。與I幀相比，P幀通常占用更少的數據位，但不足是，由於P幀對前面的P和I參考幀有着復雜的依耐性，因此對傳輸錯誤非常敏感。
3、B幀
B幀又稱雙向預測編碼幀，也就是B幀記錄的是本幀與前后幀的差別。也就是說要解碼B幀，不僅要取得之前的緩存畫面，還要解碼之后的畫面，通過前后畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，但是對解碼性能要求較高。
總結：
I幀只需考慮本幀；P幀記錄的是與前一幀的差別；B幀記錄的是前一幀及后一幀的差別,能節約更多的空間,視頻文件小了,但相對來說解碼的時候就比較麻煩。因為在解碼時,不僅要用之前緩存的畫面,而且要知道下一個I或者P的畫面,對於不支持B幀解碼的播放器容易卡頓。
視頻監控系統中預覽的視頻畫面是實時的，對畫面的流暢性要求較高。采用I幀、P幀進行視頻傳輸可以提高網絡的適應能力，且能降低解碼成本所以現階段的視頻解碼都只采用I幀和P幀進行傳輸。海康攝像機編碼，I幀間隔是50，含49個P幀。
3.第三步 了解完基礎知識后 開始編寫 服務器接收端 直接監聽一個TCP端口 操作設備開始連接這個端口發送視頻流 （注意 由於TCP 發送最大字節最好不要超過1470 不了解的可以百度 而視頻的每一幀 遠遠超過了這個長度 所以需要拆包發送 服務器根據分包 在合成 相應的 I幀 P幀 和B幀）最后形成一個完整的H264 視頻裸碼流
4.第四步 直接將收到的裸碼流 合成視頻文件 用暴風影音或者支持h264裸碼流直接播放 成功出視頻 成功的一半就是這了
5.第五步 客戶端實時播放 這一塊傷腦筋了 H264 需要解碼 一般的播放器才支持 直接谷歌百度這方面資料
6.第六步開始研究 視頻幀解碼 搜索得知 ffmpeg SharpFFmpeg 海思SDK yuv 心好累全是C++的 網上C#的示例很少
7.第七步 ffmpeg 直接調用他提供的.exe 能將我合成的裸碼流文件 直接轉換成通用播放器支持播放的視頻文件 但是 每一幀去調用 轉換成 yuv 進行實時播放 失敗 調用的ffmpeg dll 海思SDk 都沒有成功 卡殼了
參考：
http://www.cnblogs.com/zlp520/p/4238097.html
8.總結： C#搞這個的是不是不行demo太少了 開源少 網上基本全是C++的示例和開源 同時想咨詢交流下 C#有這方面經驗的人
9.繼續 谷歌 百度 尋找答案
以下為 海思SDK 調用代碼
http://www.cnblogs.com/tracky/archive/2013/06/05/3118205.html?utm_source=tuicool
以下為 ffmpeg 下載網址
https://ffmpeg.zeranoe.com/builds/
以下為 SharpFFmpeg 下載網址 SharpFFmpeg 是用C#封裝 ffmpeg 提供調用
https://ncu.dl.sourceforge.net/project/sharpffmpeg/SharpFFmpeg/SharpFFmpeg_2.0/SharpFFmpeg_2.0_src.zip