【一個完整直播app架構】
【一個完整直播app技術點】
1.採集視頻、音頻
1.1 採集視頻、音頻編碼框架
AVFoundation:AVFoundation是用來播放和創建實時的視聽媒體數據的框架，同時提供Objective-C接口來操作這些視聽數據，比如編輯，旋轉，重編碼
1.2 視頻、音頻硬件設備
CCD圖像傳感器： 用於圖像採集和處理的過程，把圖像轉換成電信號。
拾音器：聲音傳感器： 用於聲音採集和處理的過程，把聲音轉換成電信號。
音頻採樣數據：一般都是PCM格式
視頻採樣數據:：一般都是YUV,或RGB格式，採集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率
2.視頻處理（美顏，水印）
視頻處理原理：因爲視頻最終也是通過GPU，一幀一幀渲染到屏幕上的，所以我們可以利用OpenGL ES，對視頻幀進行各種加工，從而視頻各種不同的效果，就好像一個水龍頭流出的水，經過若干節管道，然後流向不同的目標
現在的各種美顏和視頻添加特效的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 :是一個跨平臺的開源視頻框架,能實現如視頻編碼,解碼,轉碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協議非常豐富,幾乎包含了所有音視頻編解碼、封裝格式以及播放協議。
-
Libswresample：可以對音頻進行重採樣,rematrixing 以及轉換採樣格式等操 作。
-
Libavcodec：提供了一個通用的編解碼框架,包含了許多視頻,音頻,字幕流 等編碼/解碼器。
-
Libavformat：用於對視頻進行封裝/解封裝。
-
Libavutil：包含一些共用的函數,如隨機數生成,數據結構,數學運算等。
-
Libpostproc：用於進行視頻的一些後期處理。
-
Libswscale：用於視頻圖像縮放,顏色空間轉換等。
-
Libavfilter：提供濾鏡功能。
X264：把視頻原數據YUV編碼壓縮成H.264格式
VideoToolbox ：蘋果自帶的視頻硬解碼和硬編碼API，但是在iOS8之後纔開放。
AudioToolbox ：蘋果自帶的音頻硬解碼和硬編碼API
3.2 視頻編碼技術
視頻壓縮編碼標準：對視頻進行壓縮(視頻編碼)或者解壓縮（視頻解碼）的編碼技術,比如MPEG，H.264。
這些視頻編碼技術是壓縮編碼視頻的主要作用：是將視頻像素數據壓縮成爲視頻碼流，從而降低視頻的數據量。如果視頻不經過壓縮編碼的話，體積通常是非常大的，一部電影可能就要上百G的空間。
注意：最影響視頻質量的是其視頻編碼數據和音頻編碼數據，跟封裝格式沒有多大關係
MPEG：一種視頻壓縮方式，它採用了幀間壓縮，僅存儲連續幀之間有差別的地方 ，從而達到較大的壓縮比
H.264/AVC：一種視頻壓縮方式,採用事先預測和與MPEG中的P-B幀一樣的幀預測方法壓縮，它可以根據需要產生適合網絡情況傳輸的視頻流，還有更高的壓縮比，有更好的圖象質量
-
注意1：如果是從單個畫面清晰度比較，MPEG4有優勢；從動作連貫性上的清晰度，H.264有優勢
-
注意2：由於264的算法更加複雜，程序實現煩瑣，運行它需要更多的處理器和內存資源。因此，運行264對系統要求是比較高的。
-
注意3： 由於264的實現更加靈活，它把一些實現留給了廠商自己去實現，雖然這樣給實現帶來了很多好處，但是不同產品之間互通成了很大的問題，造成了通過A公司的編碼器編出的數據，必須通過A公司的解碼器去解這樣尷尬的事情
H.265/HEVC：一種視頻壓縮方式,基於H.264，保留原來的某些技術，同時對一些相關的技術加以改進，以改善碼流、編碼質量、延時和算法複雜度之間的關係，達到最優化設置。H.265 是一種更爲高效的編碼標準，能夠在同等畫質效果下將內容的體積壓縮得更小，傳輸時更快更省帶寬。
I幀: (關鍵幀)保留一副完整的畫面，解碼時只需要本幀數據就可以完成（因爲包含完整畫面）
P幀 :(差別幀)保留這一幀跟之前幀的差別，解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。（P幀沒有完整畫面數據，只有與前一幀的畫面差別的數據）
B幀: (雙向差別幀)保留的是本幀與前後幀的差別，解碼B幀，不僅要取得之前的緩存畫面，還要解碼之後的畫面，通過前後畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，但是解碼時CPU會比較累
幀內（Intraframe）壓縮: 當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗餘信息,幀內一般採用有損壓縮算法
幀間（Interframe）壓縮: 時間壓縮（Temporal compression），它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的
muxing（合成）：將視頻流、音頻流甚至是字幕流封裝到一個文件中(容器格式（FLV，TS）)，作爲一個信號進行傳輸。
3.3 音頻編碼技術
AAC，mp3：這些屬於音頻編碼技術,壓縮音頻用
3.4碼率控制
多碼率:觀衆所處的網絡情況是非常複雜的，有可能是WiFi，有可能4G、3G、甚至2G，那麼怎麼滿足多方需求呢？多搞幾條線路，根據當前網絡環境自定義碼率。列如：常常看見視頻播放軟件中的1024，720，高清，標清，流暢等，指的就是各種碼率。
3.5 視頻封裝格式
TS：一種流媒體封裝格式，流媒體封裝有一個好處，就是不需要加載索引再播放，大大減少了首次載入的延遲，如果片子比較長，mp4文件的索引相當大，影響用戶體驗
爲什麼要用TS: 這是因爲兩個TS片段可以無縫拼接，播放器能連續播放
FLV：一種流媒體封裝格式,由於它形成的文件極小、加載速度極快，使得網絡觀看視頻文件成爲可能,因此FLV格式成爲了當今主流視頻格式
4.推流
4.1 數據傳輸框架
librtmp: 用來傳輸RTMP協議格式的數據
4.2 流媒體數據傳輸協議
RTMP： 實時消息傳輸協議,Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議，因爲是開放協議所以都可以使用了。
RTMP協議用於對象、視頻、音頻的傳輸，這個協議建立在TCP協議或者輪詢HTTP協議之上。
RTMP協議就像一個用來裝數據包的容器，這些數據可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的
5.流媒體服務器
5.1 常用服務器
SRS：一款國人開發的優秀開源流媒體服務器系統
BMS: 也是一款流媒體服務器系統，但不開源，是SRS的商業版，比SRS功能更多
nginx: 免費開源web服務器，常用來配置流媒體服務器。
5.2 數據分發
1、CDN：(Content Delivery Network)，即內容分發網絡,將網站的內容發佈到最接近用戶的網絡”邊緣”，使用戶可以就近取得所需的內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度.
CDN：代理服務器，相當於一箇中介。
CDN工作原理：比如請求流媒體數據1.上傳流媒體數據到服務器（源站）
2、源站存儲流媒體數據
3、客戶端播放流媒體，向CDN請求編碼後的流媒體數據
4、CDN的服務器響應請求，若節點上沒有該流媒體數據存在，則向源站繼續請求流媒體數據；若節點上已經緩存了該視頻文件，則跳到第6步。
5、源站響應CDN的請求，將流媒體分發到相應的CDN節點上
6、CDN將流媒體數據發送到客戶端
回源：當有用戶訪問某一個URL的時候，如果被解析到的那個CDN節點沒有緩存響應的內容，或者是緩存已經到期，就會回源站去獲取搜索。如果沒有人訪問，那麼CDN節點不會主動去源站拿.
帶寬: 在固定的時間可傳輸的數據總量，比如64位、800MHz的前端總線，它的數據傳輸率就等64bit×800MHz÷8(Byte)=6.4GB/s
負載均衡: 由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具有等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助.通過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地迴應客戶的請求。
均衡負載能夠平均分配客戶請求到服務器列陣，籍此提供快速獲取重要數據，解決大量併發訪問服務問題。
這種羣集技術可以用最少的投資獲得接近於大型主機的性能。
QoS（帶寬管理）:限制每一個組羣的帶寬，讓有限的帶寬發揮最大的效用
6、拉流
直播協議選擇：即時性要求較高或有互動需求的可以採用RTMP,RTSP對於有回放或跨平臺需求的，推薦使用HLS
直播協議對比：
-
HLS：由Apple公司定義的用於實時流傳輸的協議,HLS基於HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。可實現流媒體的直播和點播，主要應用在iOS系統HLS是以點播的技術方式來實現直播。
HLS是自適應碼率流播，客戶端會根據網絡狀況自動選擇不同碼率的視頻流，條件允許的情況下使用高碼率，網絡繁忙的時候使用低碼率，並且自動在二者間隨意切換。這對移動設備網絡狀況不穩定的情況下保障流暢播放非常有幫助。
實現方法是服務器端提供多碼率視頻流，並且在列表文件中註明，播放器根據播放進度和下載速度自動調整。HLS與RTMP對比: HLS主要是延時比較大，RTMP主要優勢在於延時低HLS協議的小切片方式會生成大量的文件，存儲或處理這些文件會造成大量資源浪費，相比使用RTSP協議的好處在於，一旦切分完成，之後的分發過程完全不需要額外使用任何專門軟件，普通的網絡服務器即可，大大降低了CDN邊緣服務器的配置要求，可以使用任何現成的CDN,而一般服務器很少支持RTSP。 -
HTTP-FLV：基於HTTP協議流式的傳輸媒體內容。相對於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運算 優點：播放流暢、低功耗，解碼速度快， 缺點：兼容不好
軟解碼：用CPU來解碼優點：兼容好 缺點：加大CPU負擔，耗電增加、沒有硬解碼流暢，解碼速度相對慢
8、播放
ijkplayer：一個基於FFmpeg的開源Android/iOS視頻播放器API易於集成；
編譯配置可裁剪，方便控制安裝包大小；
支持硬件加速解碼，更加省電
簡單易用，指定拉流URL，自動解碼播放.
9、聊天互動
IM:(InstantMessaging)即時通訊：是一個實時通信系統，允許兩人或多人使用網絡實時的傳遞文字消息、文件、語音與視頻流.IM
在直播系統中的主要作用是實現觀衆與主播、觀衆與觀衆之間的文字互動。
10、編碼和封裝
編碼主要難點有兩個：1. 處理硬件兼容性問題。2. 在高 fps、低 bitrate 和音質畫質之間找到平衡。iOS 端硬件兼容性較好，可以直接採用硬編。而 Android 的硬編的支持則難得多，需要支持各種硬件機型，推薦使用軟編。
爲什麼封裝？
原始視頻數據存儲空間大，一個 1080P 的 7 s 視頻需要 817 MB原始視頻數據傳輸佔用帶寬大，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘，而經過 H.264 編碼壓縮之後，視頻大小隻有 708 k ,10 Mbps 的帶寬僅僅需要 500 ms ，可以滿足實時傳輸的需求，所以從視頻採集傳感器採集來的原始視頻勢必要經過視頻編碼。
基本原理
那爲什麼巨大的原始視頻可以編碼成很小的視頻呢？這其中的技術是什麼呢？核心思想就是去除冗餘信息：
空間冗餘：圖像相鄰像素之間有較強的相關性
時間冗餘：視頻序列的相鄰圖像之間內容相似
編碼冗餘：不同像素值出現的概率不同
視覺冗餘：人的視覺系統對某些細節不敏感
知識冗餘：規律性的結構可由先驗知識和背景知識得到
11、推流和傳輸
傳輸涉及到很多端：從主播端到服務端，從收流服務端到邊緣節點，以及再從邊緣節點到觀衆端。
推流端和分發端理論上需要支持的併發用戶數應該都是億級的，不過畢竟產生內容的推流端在少數，和消費內容端播放端不是一個量級，但是他們對推流穩定性和速度的要求比播放端高很多，這涉及到所有播放端能否看到直播，以及直播端質量如何。
12、轉碼
爲了讓主播推上來的流適配各個平臺端各種不同協議，需要在服務端做一些流處理工作，比如轉碼成不同格式支持不同協議如 RTMP、HLS 和 FLV，一路轉多路流來適配各種不同的網絡狀況和不同分辨率的終端設備。
13、解碼和渲染
解碼和渲染，也即音視頻的播放，目前 iOS 端的播放兼容性較好，在延遲可接受的情況下使用 HLS 協議是最好的選擇，我們也提供了能夠播放 RTMP 和 HLS 的播放器 SDK。Android 的硬件解碼和編碼一樣也存在兼容性問題，目前比較好的開源播放器是基於 ffplay 的 ijkplayer。