前言
本文結合作者實際項目經曆介紹如何搭建一個小型的視訊直播系統，包括設計思路，開發過程以及優化方向還有踩過的坑。
功能梳理
2014年由于項目要求需要具備将遠端的現場視訊資訊回傳到以供多個地方的使用者同時檢視的功能，同時由于系統采用B/S架構，是以視訊隻能通過浏覽器來通路，而且系統基本浏覽器按照chrome設計，是以視訊實時浏覽必須支援chrome，此外，還需要支援曆史回放。
需求總結如下：
1. 支援實時視訊的預覽
2. 支援曆史視訊的回放
3. 支援20使用者的同時浏覽
4. 支援chrome浏覽器
5. 支援現場RTSP的視訊流
設計思路
問題分析
好了有了大緻的功能清單，我們可以進行開始系統的實作了。
首先必然是調研了，因為之前并不是十分了解這方面情況。調研也是要有目标，是以我大體梳理出來了如下幾個問題
1. 目前有沒有類似的系統，現在哪幾種解決方案
2. 如何能夠滿足多使用者的同時檢視實時視訊
3. 目前通過浏覽器來檢視實時視訊
4. RTSP視訊流是什麼？
現狀了解
有經過一番google和百度之後有了如下的發現
- 現有的直播系統大多需要采購硬體或系統，經費都是10w以上的
- 要想滿足多使用者同時看實時視訊需要一個叫流媒體伺服器的東西，主要由fms，red5，srs等現成軟體
- 一般的web播放器是無法播放rtsp視訊的，有一款vlc的插件之前能在chrome下觀看視訊，但現在由于安全性問題chrome已經不支援這個插件了，web視訊播放器中大部分支援rtmp或hls的實時視訊流。
-
有不少方案可以将rtsp轉為rtmp視訊流
經過以上調研，就有了下面的大體設計思路，建立一個視訊轉發服務，将現場的rtsp視訊流轉為rtmp視訊流發送到流媒體伺服器，使用者通過web視訊播放器播放流媒體伺服器的rtmp視訊流。
選型調研和驗證
有了以上的思路，就展開了第二輪調研，主要是對于流媒體伺服器選型，web播放器的選型以及最重要的視訊轉碼方案的确定。
流媒體選型方向：
在網絡上流媒體伺服器的資料最為豐富的是red5和fms，fms是商業軟體需要購買的是以就選了red5，同時發現了一個神器adobe的live encoder這個軟體就能将攝像頭的視訊轉為rtmp的視訊流，同時發現有一個fvplayer就能直接播放視訊。
流媒體選型涉及到一個關鍵的20并發的性能名額，我們就是通過搭建了live encoder+fvplayer+red5的測試平台快速驗證了red5的性能名額。
web播放器方向：
web視訊播放器選擇jwplayer，雖然也是商業軟體，但免費版也能先湊用，
視訊轉碼方向
關鍵的視訊轉發方案則選擇了最為簡單的ffmpeg 指令行的方式，
初步确定 的指令行大概是這樣。
在這些問題确定後，我們的視訊轉發系統的總體設計就完成了，由于我們系統還需要跟主要的業務系統關聯，是以系統框圖如下所示。
系統框圖
實作思路
确定好設計方案，實作就相對簡單了。
整體實作可以被劃分為下面幾個階段
- Red5的部署和調試
- Ffmpeg的指令行的設計和調試
- web前端的開發
- 視訊轉發控制子產品的開發
流媒體伺服器實作
red5 的部署網絡上有相當多的資料可以查詢到，這裡就不再贅述了。
Ffmpeg的指令行主要可以分為輸入配置，輸出配置，儲存配置這三塊，輸入配置和儲存配置較為簡單，需要注意的是輸入配置中需要确定rtsp的視訊源url這個是根據不同裝置不同的。而輸出配置最為複雜配置項又可以分為帶寬，編碼，格式，幀率，程序等部分。最終指令行如下所示（針對海康的視訊伺服器），
ffmpeg -i rtsp://admin:[email protected]:554/PSIA/streaming/channels/ -c copy -vcodec libx264 -f flv -r -threads -b:v k -an -y rtmp://20.10.114.150/live/20150423201047382 "C:/Z111W/out.mp4"
Web前端實作
web前端開發也是很簡單，html+js就能搞定，jwplayer的初始化代碼如下所示。
<html>
<head>
<script src="/jwplayer/jwplayer.js"></script>
</head>
<body>
<div id='myplayer'></div> <script type='text/javascript'>
jwplayer('myplayer').setup({
file: 'rtmp-url',
width: '640',
height: '480' });
</script>
</body>
</html>
視訊轉發控制子產品實作
視訊轉發控制器初期功能其實很簡單，就是根據視訊源的資訊，解析為ffmpeg的指令行配置參數，最後再啟動ffmpeg進行視訊轉發。整體采用springboot架構，采用restful接口與業務系統對接，通過直接調用cmd ffmepg的方式啟動視訊轉發。
系統聯調
在開發環境内的區域網路的測試聯調還是比較順利的，系統初步開發完成。
填坑之旅
自己造輪子最有挑戰性的階段并不是開發階段，而是後來的填坑階段
要填的坑有以下幾個
- 視訊轉發如何結束
- 曆史回放如何實作
- 實際高動态視訊在有限帶寬下的轉發調優
- 如何支援rtsp之外的視訊流
-
能同時轉發多少路視訊以及優化方向
由于篇幅原因，這裡就不一一詳細說明這幾個坑是怎麼填的，這裡隻是給出幾個大體思路
1.通過管理轉發線程id，視訊轉發任務id的對應的表，在要進行結束轉發時發送ctrl+c指令到對應的線程停止視訊轉發
2.通過将儲存的實時視訊歸檔到red5的live檔案夾下，通過業務系統的記錄歸檔的檔案名傳回使用者，使用者通用通過jwplayer讀取曆史檔案進行回放
3.試驗試驗試驗
4.通過擴充視訊轉發子產品來組合指令行擴充ffmpeg支援的視訊流，對于不支援的視訊流則采用前置硬體轉碼器進行轉碼譬如h265；
5.通過重構視訊轉發子產品采用執行轉碼的子產品與控制子產品分離的政策，通過消息中間件來實作控制與轉碼子產品的對接，利用轉碼服務叢集的水準擴充提高視訊轉發性能。
回顧與反思
該系統随着時間的推移，經過不斷的重構所用技術甚至架構已經跟最開始的設計非常不一樣的，這個過程正好展現了系統演進的過程。
說明了一個普遍現象隻要時間和資源不是問題，那麼技術本身就不是問題。
DRY在開發上是真理，但在技術成長上優勢偶爾突破一次也會有不同的收獲。
人有多大膽，地有多大産啊，但這是建立在技術直覺的基礎上的，否則就是隻挖坑不填坑。
總結
最後，這個系統并不複雜，但我希望在搭建和開發這個系統的思路還是對大家是有幫助的。
![Java通過調用FFMPEG擷取視訊時長（已測試）[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)