關於直播視訊平臺與監控視訊平臺技術架構方案

前言

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

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

一、直播平臺（想盡一切辦法來降低延遲，從一開始你就不應該對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這個坑吧，再過五六年或許可以。