直播流程

1.採集視頻、音頻

*1.1 採集視頻、音頻編碼框架 *

*1.2 視頻、音頻硬件設備 *

· CCD :圖像傳感器：用於圖像採集和處理的過程，把圖像轉換成電信號。

· 拾音器 :聲音傳感器：用於聲音採集和處理的過程，把聲音轉換成電信號。

· 音頻採樣數據 :通常都是PCM格式

· 視頻採樣數據 : 通常都是 YUV ,或 RGB 格式，採集到的原始音視頻的體積是很是大的，須要通過壓縮技術處理來提升傳輸效率

2.視頻處理（美顏，水印）

· 視頻處理原理 :由於視頻最終也是經過GPU，一幀一幀渲染到屏幕上的，因此咱們能夠利用OpenGL ES，對視頻幀進行各類加工，從而視頻各類不一樣的效果，就好像一個水龍頭流出的水，通過若干節管道，而後流向不一樣的目標

o 如今的各類美顏和視頻添加特效的app都是利用GPUImage這個框架實現的,.

*視頻處理框架 *

· GPUImage : GPUImage是一個基於OpenGL ES的一個強大的圖像/視頻處理框架,封裝好了各類濾鏡同時也能夠編寫自定義的濾鏡,其自己內置了多達120多種常見的濾鏡效果。

· OpenGL :OpenGL（全寫Open Graphics Library）是個定義了一個跨編程語言、跨平臺的編程接口的規格，它用於三維圖象（二維的亦可）。OpenGL是個專業的圖形程序接口，是一個功能強大，調用方便的底層圖形庫。

· OpenGL ES :OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集，針對手機、PDA和遊戲主機等嵌入式設備而設計。

3.視頻編碼解碼

*3.1 視頻編碼框架 *

· FFmpeg :是一個跨平臺的開源視頻框架,能實現如視頻編碼,解碼,轉碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協議很是豐富,幾乎包含了全部音視頻編解碼、封裝格式以及播放協議。

o -Libswresample:能夠對音頻進行重採樣,rematrixing以及轉換採樣格式等操做。

o -Libavcodec:提供了一個通用的編解碼框架,包含了許多視頻,音頻,字幕流等編碼/解碼器。

o -Libavformat:用於對視頻進行封裝/解封裝。

o -Libavutil:包含一些共用的函數,如隨機數生成,數據結構,數學運算等。

o -Libpostproc:用於進行視頻的一些後期處理。

o -Libswscale:用於視頻圖像縮放,顏色空間轉換等。

o -Libavfilter:提供濾鏡功能。

· X264 :把視頻原數據YUV編碼壓縮成H.264格式

*3.2 視頻編碼技術 *

· 視頻壓縮編碼標準：對視頻進行壓縮(視頻編碼)或者解壓縮（視頻解碼）的編碼技術 ,好比 MPEG ， H.264 ,這些視頻編碼技術是壓縮編碼視頻的

o 主要做用 :是將視頻像素數據壓縮成爲視頻碼流，從而下降視頻的數據量。若是視頻不通過壓縮編碼的話，體積一般是很是大的，一部電影可能就要上百G的空間。

o 注意 :最影響視頻質量的是其視頻編碼數據和音頻編碼數據，跟封裝格式沒有多大關係

· MPEG :一種視頻壓縮方式，它採用了幀間壓縮，僅存儲連續幀之間有差異的地方，從而達到較大的壓縮比

· H.264/AVC :一種視頻壓縮方式,採用事先預測和與MPEG中的P-B幀同樣的幀預測方法壓縮，它能夠根據須要產生適合網絡狀況傳輸的視頻流,還有更高的壓縮比，有更好的圖象質量

o 注意1 :若是是從單個畫面清晰度比較，MPEG4有優點；從動做連貫性上的清晰度，H.264有優點

o 注意2 :因爲264的算法更加複雜，程序實現煩瑣，運行它須要更多的處理器和內存資源。所以，運行264對系統要求是比較高的。

o 注意3 :因爲264的實現更加靈活，它把一些實現留給了廠商本身去實現，雖然這樣給實現帶來了不少好處，可是不一樣產品之間互通成了很大的問題，形成了經過A公司的編碼器編出的數據，必須經過A公司的解碼器去解這樣尷尬的事情

· H.265/HEVC :一種視頻壓縮方式,基於H.264，保留原來的某些技術，同時對一些相關的技術加以改進，以改善碼流、編碼質量、延時和算法複雜度之間的關係，達到最優化設置。

o H.265 是一種更爲高效的編碼標準，可以在同等畫質效果下將內容的體積壓縮得更小，傳輸時更快更省帶寬

o I幀 :(關鍵幀)保留一副完整的畫面，解碼時只須要本幀數據就能夠完成（由於包含完整畫面）

· P幀 :(差異幀)保留這一幀跟以前幀的差異，解碼時須要用以前緩存的畫面疊加上本幀定義的差異，生成最終畫面。（P幀沒有完整畫面數據，只有與前一幀的畫面差異的數據）

· B幀 :(雙向差異幀)保留的是本幀與先後幀的差異，解碼B幀，不只要取得以前的緩存畫面，還要解碼以後的畫面，經過先後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，可是解碼時CPU會比較累

· 幀內（Intraframe）壓縮 :當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗餘信息,幀內通常採用有損壓縮算法

· 幀間（Interframe）壓縮 :時間壓縮（Temporal compression），它經過比較時間軸上不一樣幀之間的數據進行壓縮。幀間壓縮通常是無損的

· muxing（合成）：將視頻流、音頻流甚至是字幕流封裝到一個文件中( 容器格式（FLV，TS） )，做爲一個信號進行傳輸。

*3.3 音頻編碼技術 *

· AAC ， mp3 ：這些屬於音頻編碼技術,壓縮音頻用

*3.4碼率控制 *

· 多碼率 :觀衆所處的網絡狀況是很是複雜的，有多是WiFi，有可能4G、3G、甚至2G，那麼怎麼知足多方需求呢？多搞幾條線路，根據當前網絡環境自定義碼率。

o 列如：經常看見視頻播放軟件中的1024，720，高清，標清，流暢等，指的就是各類碼率。

*3.5 視頻封裝格式 *

· TS : 一種流媒體封裝格式，流媒體封裝有一個好處，就是不須要加載索 引再播放，大大減小了首次載入的延遲，若是片子比較長，mp4文件的索引至關大，影響用戶體驗

o 爲何要用TS :這是由於兩個TS片斷能夠無縫拼接，播放器能連續播放

· FLV : 一種流媒體封裝格式,因爲它造成的文件極小、加載速度極快，使得網絡觀看視頻文件成爲可能,所以FLV格式成爲了當今主流視頻格式

4.推流

*4.1 數據傳輸框架 *

librtmp :用來傳輸RTMP協議格式的數據

*4.2 流媒體數據傳輸協議 *

· RTMP :實時消息傳輸協議,Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議，由於是開放協議因此均可以使用了。

o RTMP協議用於對象、視頻、音頻的傳輸。

o 這個協議創建在TCP協議或者輪詢HTTP協議之上。

o RTMP協議就像一個用來裝數據包的容器，這些數據能夠是FLV中的視音頻數據。一個單一的鏈接能夠經過不一樣的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的

chunk :消息包

5.流媒體服務器

*5.1經常使用服務器 *

· SRS ：一款國人開發的優秀開源流媒體服務器系統

· BMS :也是一款流媒體服務器系統，但不開源，是SRS的商業版，比SRS功能更多

· nginx :免費開源web服務器，經常使用來配置流媒體服務器。

*5.2數據分發 *

· CDN ：(Content Delivery Network)，即內容分發網絡,將網站的內容發佈到最接近用戶的網絡」邊緣」，使用戶能夠就近取得所需的內容，解決 Internet網絡擁擠的情況，提升用戶訪問網站的響應速度.

o CDN ：代理服務器，至關於一箇中介。

o CDN工做原理：好比請求流媒體數據

§ 1.上傳流媒體數據到服務器（源站）

§ 2.源站存儲流媒體數據

§ 3.客戶端播放流媒體，向CDN請求編碼後的流媒體數據

§ 4.CDN的服務器響應請求，若節點上沒有該流媒體數據存在，則向源站繼續請求流媒體數據；若節點上已經緩存了該視頻文件，則跳到第6步。

§ 5.源站響應CDN的請求，將流媒體分發到相應的CDN節點上

§ 6.CDN將流媒體數據發送到客戶端

· 回源：當有用戶訪問某一個URL的時候，若是被解析到的那個CDN節點沒有緩存響應的內容，或者是緩存已經到期，就會回源站去獲取搜索。若是沒有人訪問，那麼CDN節點不會主動去源站拿.

· 帶寬 :在固定的時間可傳輸的數據總量，

o 好比64位、800MHz的前端總線，它的數據傳輸率就等於64bit×800MHz÷8(Byte)=6.4GB/s

· 負載均衡 : 由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具備等價的地位，均可以單獨對外提供服務而無須其餘服務器的輔助.

o 經過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地迴應客戶的請求。

o 均衡負載可以平均分配客戶請求到服務器列陣，籍此提供快速獲取重要數據，解決大量併發訪問服務問題。

o 這種羣集技術能夠用最少的投資得到接近於大型主機的性能。

· QoS（帶寬管理） :限制每個組羣的帶寬，讓有限的帶寬發揮最大的效用

6.拉流

· 直播協議選擇：

即時性要求較高或有互動需求的能夠採用 RTMP , RTSP

對於有回放或跨平臺需求的，推薦使用 HLS

· 直播協議對比 :

 

· HLS :由Apple公司定義的用於實時流傳輸的協議,HLS基於HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。可實現流媒體的直播和點播，主要應用在iOS系統

o HLS是以點播的技術方式來實現直播

o HLS是自適應碼率流播，客戶端會根據網絡情況自動選擇不一樣碼率的視頻流，條件容許的狀況下使用高碼率，網絡繁忙的時候使用低碼率，而且自動在兩者間隨意切

換。這對移動設備網絡情況不穩定的狀況下保障流暢播放很是有幫助。

o 實現方法是服務器端提供多碼率視頻流，而且在列表文件中註明，播放器根據播放進度和下載速度自動調整。

· HLS與RTMP對比 :HLS主要是延時比較大，RTMP主要優點在於延時低

o HLS協議的小切片方式會生成大量的文件，存儲或處理這些文件會形成大量資源浪費

o 相比使用RTSP協議的好處在於，一旦切分完成，以後的分發過程徹底不須要額外使用任何專門軟件，普通的網絡服務器便可，大大下降了CDN邊緣服務器的配置要求，可使用任何現成的CDN,而通常服務器不多支持RTSP。

· HTTP-FLV :基於HTTP協議流式的傳輸媒體內容。

o 相對於RTMP，HTTP更簡單和廣爲人知，內容延遲一樣能夠作到1~3秒，打開速度更快，由於HTTP自己沒有複雜的狀態交互。因此從延遲角度來看，HTTP-FLV要優於RTMP。

· RTSP :實時流傳輸協議,定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據.

· RTP :實時傳輸協議,RTP是創建在UDP協議上的，常與RTCP一塊兒使用，其自己並無提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。

· RTCP :RTP的配套協議,主要功能是爲RTP所提供的服務質量（QoS）提供反饋，收集相關媒體鏈接的統計信息，例如傳輸字節數，傳輸分組數，丟失分組數，單向和雙向網絡延遲等等。

7.解碼

*7.1 解封裝 *

· demuxing（分離）：從視頻流、音頻流，字幕流合成的文件( 容器格式（FLV，TS） )中，分解出視頻、音頻或字幕，各自進行解碼。

*7.2 音頻編碼框架 *

· fdk_aac :音頻編碼解碼框架，PCM音頻數據和AAC音頻數據互轉

*7.3 解碼介紹 *

· 硬解碼：用GPU來解碼，減小CPU運算

o 優勢：播放流暢、低功耗，解碼速度快，

*    缺點：兼容很差

· 軟解碼：用CPU來解碼

o 優勢：兼容好

*    缺點：加大CPU負擔，耗電增長、沒有硬解碼流暢，解碼速度相對慢

8.播放

· ijkplayer :一個基於FFmpeg的開源Android/iOS視頻播放器

o API易於集成；

o 編譯配置可裁剪，方便控制安裝包大小；

o 支持硬件加速解碼，更加省電

o 簡單易用，指定拉流URL，自動解碼播放.

9.聊天互動

· IM :(InstantMessaging)即時通信:是一個實時通訊系統，容許兩人或多人使用網絡實時的傳遞文字消息、文件、語音與視頻交流.

o IM 在直播系統中的主要做用是實現觀衆與主播、觀衆與觀衆之間的文字互動.

*第三方SDK *

· 騰訊雲 ：騰訊提供的即時通信SDK，可做爲直播的聊天室

· 融雲 ：一個比較經常使用的即時通信SDK，可做爲直播的聊天室--------------------- 做者：deng_wei_csdn 來源：CSDN 原文：https://blog.csdn.net/github_37855556/article/details/73467698