關於直播視頻平臺與監控視頻平臺技術架構方案的一點小想法

javaCV入門指南：序章

截圖服務在線演示demo：https://blog.csdn.net/eguid_1/article/details/82842904

項目維護地址：https://github.com/eguid/easyCV

感謝支持eguid原創，有興趣的小夥伴能夠點擊博客左邊的羣連接加羣討論。

前言

講個大實話，直播平臺複雜在直播端（也就是播放端），而監控平臺複雜在接入端（前端設備或平臺）。

至於技術難點，難者自知。

 

1、直播平臺（想盡一切辦法來下降延遲，從一開始你就不該該對hls抱有任何幻想）
一、直播房間管理
主播管理--[主播申請直播房間]-->房間管理--[房間綁定直播推流地址]-->分配流媒體直播地址（可能會有多個流媒體服務，房間id做爲rtmp和flv播放名稱，只提供rtmp和flv分發，直播場景不考慮hls）

二、流媒體服務（srs或nginx+rtmpmodule），定製需求（經過主播推流和用戶播放回調事件展現實時數據，用戶真實數量後臺不作調整，前端隨意,回調接口由web服務提供）

三、前端直播（web，pc，移動端，微信小程序）
主要是播放器（h5採用flv方案，原生隨意），還有實時彈幕和評論，禮物等等。
直播這塊主要難點在於cdn分發下降延遲，其餘沒有難點。
小程序這塊微信有提供單獨的liveplayer播放器API，支持rtmp和flv，直接用就能夠。
pc端想怎麼搞怎麼搞，就算你想本身解碼而後播放又有什麼不能夠呢？
web端主要仍是H5爲主（flv，兼容低版本ie的話，能夠上flash播放器），畢竟直播仍是年輕人看的多，老年人應該會選擇看電視吧~~maybe。

 

2、監控視頻平臺（視頻接入複雜度較高，依然不考慮hls）
監控平臺複雜度體如今接入複雜，接入協議多，私有協議滿天飛，gb28181，177平臺，sip，各類設備對接和監控系統對接，音視頻裸碼流，rtsp，rtmp，rtmp，hls，錄像文件等等。

一、視頻接入服務
須要一個統一接入服務（必須肯定接入的每臺設備的接入信息和接入方式（大而全，支持協議足夠多，支持各類廠商私有碼流，吃力而不討好），流媒體服務會經過回調方式讓本服務進行拉流並推流到流媒體服務）。

二、流媒體服務
首選srs或nginx+rtmpmodule，定製需求（即時轉流，經過用戶調用方式觸發回調接入服務進行實時推流到流媒體服務）
既然是即時轉流，那麼延遲確定比直播平臺延遲要大，用戶體驗通常般；想要更好的用戶體驗就須要不停的從前端設備拉流推流到流媒體服務，後者本質上跟直播沒區別。

 

三、監控視頻直播（web，pc，移動端，微信小程序）
這塊跟直播平臺沒啥區別，只不過不須要彈幕什麼的了，前端比較簡單，只要能看視頻就行。
小程序這塊微信有提供單獨的liveplayer播放器API，支持rtmp和flv，直接用就能夠。
pc端想怎麼搞怎麼搞，就算你想本身解碼而後播放又有什麼不能夠呢？

 

3、關於兩種平臺推流（接入）的異同 一、監控平臺雖然不須要主動推流，但實際狀況更加撲朔迷離，各類私有協議花樣百出目不暇接，沒有標準接入協議真的很難搞。 誰知道明年會不會出個新的協議或者廠商設備換個型號私有頭也跟着變，可是接入這塊有個好處，能養不少NB程序猿，技術難度高，門檻高（最基礎的你得熟悉rtsp，sip，ts，rtmp，flv，mpeg4/h264，g711，aac這些吧，至於用什麼編程語言這都是後話了）。 二、直播平臺通常能夠移動端推流和pc端推流，用瀏覽器推流不知道腦殼是怎麼想的，仍是暫時遠離webrtc這個坑吧，再過五六年或許能夠。