關於直播視頻平台與監控視頻平台技術架構方案的一點小想法
- 2019 年 11 月 1 日
- 筆記
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/eguid_1/article/details/83021107
截圖服務在線演示demo：https://blog.csdn.net/eguid_1/article/details/82842904
項目維護地址：https://github.com/eguid/easyCV
前言
講個大實話，直播平台複雜在直播端（也就是播放端），而監控平台複雜在接入端（前端設備或平台）。
至於技術難點，難者自知。
一、直播平台（想盡一切辦法來降低延遲，從一開始你就不應該對hls抱有任何幻想） 1、直播房間管理 主播管理–[主播申請直播房間]–>房間管理–[房間綁定直播推流地址]–>分配流媒體直播地址（可能會有多個流媒體服務，房間id作為rtmp和flv播放名稱，只提供rtmp和flv分發，直播場景不考慮hls）
2、流媒體服務（srs或nginx+rtmpmodule），定製需求（通過主播推流和用戶播放回調事件展示實時數據，用戶真實數量後台不做調整，前端隨意,回調接口由web服務提供）
3、前端直播（web，pc，移動端，微信小程序） 主要是播放器（h5採用flv方案，原生隨意），還有實時彈幕和評論，禮物等等。 直播這塊主要難點在於cdn分發降低延遲，其他沒有難點。 小程序這塊微信有提供單獨的liveplayer播放器API，支持rtmp和flv，直接用就可以。 pc端想怎麼搞怎麼搞，就算你想自己解碼然後播放又有什麼不可以呢？ web端主要還是H5為主（flv，兼容低版本ie的話，可以上flash播放器），畢竟直播還是年輕人看的多，老年人應該會選擇看電視吧~~maybe。
二、監控視頻平台（視頻接入複雜度較高，依然不考慮hls） 監控平台複雜度體現在接入複雜，接入協議多，私有協議滿天飛，gb28181，177平台，sip，各種設備對接和監控系統對接，音視頻裸碼流，rtsp，rtmp，rtmp，hls，錄像文件等等。
1、視頻接入服務 需要一個統一接入服務（必須確定接入的每台設備的接入信息和接入方式（大而全，支持協議足夠多，支持各種廠商私有碼流，吃力而不討好），流媒體服務會通過回調方式讓本服務進行拉流並推流到流媒體服務）。
2、流媒體服務 首選srs或nginx+rtmpmodule，定製需求（即時轉流，通過用戶調用方式觸發回調接入服務進行實時推流到流媒體服務） 既然是即時轉流，那麼延遲肯定比直播平台延遲要大，用戶體驗一般般；想要更好的用戶體驗就需要不停的從前端設備拉流推流到流媒體服務，後者本質上跟直播沒區別。
3、監控視頻直播（web，pc，移動端，微信小程序） 這塊跟直播平台沒啥區別，只不過不需要彈幕什麼的了，前端比較簡單，只要能看視頻就行。 小程序這塊微信有提供單獨的liveplayer播放器API，支持rtmp和flv，直接用就可以。 pc端想怎麼搞怎麼搞，就算你想自己解碼然後播放又有什麼不可以呢？
三、關於兩種平台推流（接入）的異同 1、監控平台雖然不需要主動推流，但實際情況更加撲朔迷離，各種私有協議花樣百出應接不暇，沒有標準接入協議真的很難搞。 誰知道明年會不會出個新的協議或者廠商設備換個型號私有頭也跟着變，但是接入這塊有個好處，能養很多NB程序猿，技術難度高，門檻高（最基礎的你得熟悉rtsp，sip，ts，rtmp，flv，mpeg4/h264，g711，aac這些吧，至於用什麼編程語言這都是後話了）。 2、直播平台一般可以移動端推流和pc端推流，用瀏覽器推流不知道腦袋是怎麼想的，還是暫時遠離webrtc這個坑吧，再過五六年或許可以。
