基於live555開發嵌入式linux系統的rtsp直播服務

最近要搞一個直播服務，車機自己是個先後雙路的Dvr，前路1080P 25fps,後路720P 50fps，如今要鏈接手機app預覽實時畫面，且支持先後攝像頭畫面切換。

若是要作直播，這個分辨率和幀率是很是艱難的，必須下降，通過考量以後先設定爲480P 25fps，編碼碼率爲512k看看效果再作優化。

研究了一段時間的live555，裏面有不少demo能夠參考，可是我這個需求和裏面demo的效果有比較大的差別

由於要作實時直播，必須是實時的攝像頭數據，因此無法用rtspServe播放視頻文件的方式來實現，。

換一個思路能夠在rtspServe裏面本身去打開攝像頭獲取數據，移植x264進行編解碼再直播，可是由於Dvr佔據了兩個攝像頭進行錄像，沒法騰出來，因此其餘用戶無權再開啓攝像頭。

rtspServe須要攝像頭數據只能從Dvr獲取，如此則須要一套進程間通訊機制，並且要能承載大數據量的通訊。能夠考慮用有名管道或者共享內存。

 

基於此模式，我又有兩個不一樣的直播編碼方式，

方式一 獨立編碼直播流

rtspServe只從Dvr獲取YUV原始數據，本身採用X264對每一幀進行編碼，而後推流。

優勢:

一、獨立性，能夠獨立於Dvr的數據，本身單獨設置編碼參數，同時直播過程可控性強，好比遇到網絡阻塞能夠自由丟原始數據幀。

二、靈活性，直播服務器自由控制。

缺點:

一、YUV原始數據很大，通訊壓力大。

二、須要使用x264進行軟編碼，軟編碼時效未知。

方案2、採用錄像編碼數據分流

Dvr是一直在編碼錄像的，可是是一段一段的錄製，能夠從Dvr編好的數據流在保存文件的同事開一個分支共享給直播

優勢：

一、失效高，錄像編碼採用硬件編碼的，一直用來錄像編碼，已經通過長期的驗證。

二、共享數據量小，共享數據是編碼好的相比於YUV原始數據會小不少。

缺點：

一、編碼的各項參數必須是和錄像同樣的，無法獨立調節。

二、直播過程受錄像影響，好比開始錄像中止錄像，意味着編碼數據的開關。

 

以上兩個方案我的更傾向於第一個，可是我最擔憂的就是x264的軟編碼時效是否能跟上，因而單獨先移植了x264弄了個demo驗證，果真x264亂編碼的時效性過低了，碼率設置在200k也無法跟上這麼大分辨率這麼高幀率的數據編碼，一秒鐘的視頻數據須要編碼兩三秒，因此只能走第二個方案。

走方案二須要解決的只剩下rtspServer了，我須要實現一個本身的rtspServer，從管道獲取編碼數據而後推流

參考live555裏面的testProgs

咱們須要實現本身的幾個文件類

一、實現本身的FrameSource：

FrameSource主要完成從哪裏獲取數據流(文件或者其餘地方)，怎麼獲取數據流等。

二、實現本身的MediaSubsession

這個類主要是根據本身的source數據類型，創建不一樣的RTPSink和FrameSource

三、實現本身的rtspServer主函數

能夠參考testOnDemandRTSPServer實現，把不要的各類類型的rtsp刪除掉(mp三、mp四、wav、vob)，只保留本身的。

 

通過幾天的倒騰測試基本把rtspServer的通路打通了，app能正常播放，效果後續優化。