視頻轉播系統方案？

視頻直播平臺架構

1.推流和上傳

2.視頻基礎服務

3.應用基礎服務

4.客戶端播放

直播方案整體設計

直播平臺的流程可以分為如下幾步： 采集 —>編碼和封裝—>推流—>處理—>分發—>播放

采集

采集是整個視頻推流過程中的第一個環節，它從系統的采集設備中獲取原始視頻數據，將其輸出到下一個環節。視頻的采集涉及兩方面數據的采集：音頻采集和圖像采集，它們分別對應兩種完全不同的輸入源和數據格式。

音頻采集 音頻數據既能與圖像結合組合成視頻數據，也能以純音頻的方式采集播放，后者在很多成熟的應用場景如在線電臺和語音電臺等起著非常重要的作用。音頻的采集過程主要通過設備將環境中的模擬信號采集成 PCM 編碼的原始數據，然后編碼壓縮成 MP3 等格式的數據分發出去。圖像采集 將圖像采集的圖片結果組合成一組連續播放的動畫，即構成視頻中可肉眼觀看的內容。圖像的采集過程主要由攝像頭等設備拍攝成 YUV 編碼的原始數據，然后經過編碼壓縮成 H.264 等格式的數據分發出去。

視頻采集的采集源主要有 攝像頭采集、屏幕錄制和從視頻文件推流。

編碼

如果把整個流媒體比喻成一個物流系統，那么編解碼就是其中配貨和裝貨的過程，這個過程非常重要，它的速度和壓縮比對物流系統的意義非常大，影響物流系統的整體速度和成本。同樣，對流媒體傳輸來說，編碼也非常重要，它的編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。

封裝

沿用前面的比喻，封裝可以理解為采用哪種貨車去運輸，也就是媒體的容器。 所謂容器，就是把編碼器生成的多媒體內容(視頻，音頻，字幕，章節信息等)混合封裝在一起的標準。容器使得不同多媒體內容同步播放變得很簡單，而容器的另一個作用就是為多媒體內容提供索引，也就是說如果沒有容器存在的話一部影片你只能從一開始看到最后，不能拖動進度條，而且如果你不自己去手動另外載入音頻就沒有聲音。

推流

推流是直播的第一公里，直播的推流對這個直播鏈路影響非常大，如果推流的網絡不穩定，無論我們如何做優化，觀眾的體驗都會很糟糕。所以也是我們排查問題的第一步，如何系統地解決這類問題需要我們對相關理論有基礎的認識。 推送協議主要有三種：

RTSP（Real Time Streaming Protocol）：實時流傳送協議，是用來控制聲音或影像的多媒體串流協議, 由 Real Networks 和 Netscape 共同提出的；

RTMP(Real Time Messaging Protocol)：實時消息傳送協議，是 Adobe 公司為 Flash 播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議；

HLS(HTTP Live Streaming)：是蘋果公司(Apple Inc.)實現的基于 HTTP 的流媒體傳輸協議；

處理

視頻或者音頻完成采集之后得到原始數據，1）為了增強一些現場效果或者加上一些額外的效果，我們一般會在將其重新編碼壓縮（轉碼）前進行處理，比如打上時間戳或者公司 Logo 的水印，祛斑美顏和聲音混淆等處理。2）對視頻內容進行合法性、合規性的鑒權。

分發

流媒體服務器的作用是負責直播流的發布和轉播分發功能。

播放

主要是實現直播節目在終端上的展現。因為我這里使用的傳輸協議是 RTMP， 所以只要支持 RTMP 流協議的播放器都可以使用，譬如：

電腦端：VLC 等

手機端：Vitamio 以及 ijkplayer 等

參考：王教授App 智庫