最近要搞一個直播服務，車機本身是個前后雙路的Dvr，前路1080P 25fps,后路720P 50fps，現在要連接手機app預覽實時畫面，且支持前后攝像頭畫面切換。
如果要做直播，這個分辨率和幀率是非常艱難的，必須降低，經過考量之后先設定為480P 25fps，編碼碼率為512k看看效果再做優化。
研究了一段時間的live555，里面有很多demo可以參考，但是我這個需求和里面demo的效果有比較大的差異
因為要做實時直播，必須是實時的攝像頭數據，所以沒法用rtspServe播放視頻文件的方式來實現，。
換一個思路可以在rtspServe里面自己去打開攝像頭獲取數據，移植x264進行編解碼再直播，但是因為Dvr占據了兩個攝像頭進行錄像，無法騰出來，所以其他用戶無權再開啟攝像頭。
rtspServe需要攝像頭數據只能從Dvr獲取，如此則需要一套進程間通信機制，而且要能承載大數據量的通信。可以考慮用有名管道或者共享內存。
基於此模式，我又有兩個不同的直播編碼方式，
方式一 獨立編碼直播流
rtspServe只從Dvr獲取YUV原始數據，自己采用X264對每一幀進行編碼，然后推流。
優點:
1、獨立性，可以獨立於Dvr的數據，自己單獨設置編碼參數，同時直播過程可控性強，比如遇到網絡阻塞可以自由丟原始數據幀。
2、靈活性，直播服務器自由控制。
缺點:
1、YUV原始數據很大，通信壓力大。
2、需要使用x264進行軟編碼，軟編碼時效未知。
方案二、采用錄像編碼數據分流
Dvr是一直在編碼錄像的，但是是一段一段的錄制，可以從Dvr編好的數據流在保存文件的同事開一個分支共享給直播
優點：
1、失效高，錄像編碼采用硬件編碼的，一直用來錄像編碼，已經經過長期的驗證。
2、共享數據量小，共享數據是編碼好的相比於YUV原始數據會小很多。
缺點：
1、編碼的各項參數必須是和錄像一樣的，沒法獨立調節。
2、直播過程受錄像影響，比如開始錄像停止錄像，意味着編碼數據的開關。
以上兩個方案個人更傾向於第一個，但是我最擔心的就是x264的軟編碼時效是否能跟上，於是單獨先移植了x264弄了個demo驗證，果然x264亂編碼的時效性太低了，碼率設置在200k也沒法跟上這么大分辨率這么高幀率的數據編碼，一秒鍾的視頻數據需要編碼兩三秒，所以只能走第二個方案。
走方案二需要解決的只剩下rtspServer了，我需要實現一個自己的rtspServer，從管道獲取編碼數據然后推流
參考live555里面的testProgs
我們需要實現自己的幾個文件類
1、實現自己的FrameSource：
FrameSource主要完成從哪里獲取數據流(文件或者其他地方)，怎么獲取數據流等。
2、實現自己的MediaSubsession
這個類主要是根據自己的source數據類型，建立不同的RTPSink和FrameSource
3、實現自己的rtspServer主函數
可以參考testOnDemandRTSPServer實現，把不要的各種類型的rtsp刪除掉(mp3、mp4、wav、vob)，只保留自己的。
經過幾天的倒騰測試基本把rtspServer的通路打通了，app能正常播放，效果后續優化。
