前言：每個成功者多是站在巨人的肩膀上！在做直播開發時 碰到了很多問題，在收集了許多人部落格的基礎上做出來了成功的直播專案並做了整理，並在最後奉上我的全部程式碼。
其中採用部落格的博主開篇在此感謝，本著開源分享的精神，我會將前輩的知識和自己開發中遇到的問題整理出完整的一套開發流程，再次希望採用的博主能夠容許使用，並再次感謝！ 大多內容其他部落格給出很不錯詳解就整理到此篇，原理篇相關技術點來自袁崢Seemygo分享整理。採集和伺服器推流會有所不同（在原有的系統框架採集視訊基礎上新增另一種框架來採集視訊、美顏和推流) , 為節省時間， 也請一些童靴不喜勿噴！
【目錄】
- 如何開發出一款仿映客直播APP專案實踐篇 -【原理篇】
- 如何開發出一款仿映客直播APP專案實踐篇 -【採集篇 】
- 如何開發出一款仿映客直播APP專案實踐篇 -【伺服器搭建+推流】
- 如何開發出一款仿映客直播APP專案實踐篇 -【播放篇】
模組一 ：直播技術
【 主要模組】
- 主播端： 把主播實時錄製的視訊，經過（採集、美顏處理、編碼）推送到伺服器
- 伺服器： 處理（轉碼、錄製、截圖、鑑黃）後分發給使用者播放端
- 播放器： 獲取伺服器地址， 進行拉流、解碼、渲染
- 互動系統： 聊天室、禮物系統、贊
示例圖：
直播效果圖
【一個完整直播app實現流程】
1.採集、2.濾鏡處理、3.編碼、4.推流、5.CDN分發、6.拉流、7.解碼、8.播放、9.聊天互動
【一個完整直播app架構】
【一個完整直播app技術點】
模組二、專案功能模組 -> 技術
簡介：
相對於上面圖中每個技術點刨開來說都很繁瑣 ，也很難掌握，我會在下面的【相關技術知識點概括】中給與大致講述；由於涉及音視訊的編碼解碼、美顏功能的演算法，幀的處理等很多問題，能從底層自己開發的完整功能的絕對是大牛！
不過正是有這些大牛們的奉獻 ，我們不需要處理繁瑣的底層問題，一些封裝好的庫可以完美實現。
- 主播端: LFLiveKit 已包含採集、美顏、編碼、推流等功能
- 伺服器 : 【 nginx+rtmp伺服器】免費開源，能搭建本地電腦上，支援RTMP協議，滿足直播需求。
- 播放端 : ijkplayer視訊直播框架 封裝很完善只要有url，就可以實時播放
模組三、如何快速的開發一個完整的iOS直播app
1、利用第三方直播SDK快速的開發
阿里雲: 提供低延遲、高清晰、 高併發支援的直播服務，幫您從容應對業務突發峰值。廣泛應用於 遊戲直播、娛樂直播、泛生活直播、 教育類、 遠端醫療、 企業遠端視訊會議等典型場景，
百度直播雲: 視訊直播、點播一站式解決方案，讓視訊技術零門檻，結合領先的人工智慧技術，開放智慧影象識別、視訊特效、黃反稽核功能，讓視訊內容更豐富，更安全
七牛雲:七牛直播雲是專為直播平臺打造的全球化直播流服務和一站式實現SDK端到端直播場景的企業級直播雲服務平臺.
2、自研還是使用第三方直播SDK開發？
自研： 對於一個初創公司或團隊來講，自研直播不管在技術門檻、CDN、頻寬上都是有很大的門檻的，而且需要耗費大量的時間和成本才能做出成品，不利於前期發展。
第三方SDK開發：開發週期短，前期投入少，從長遠看，第三方費用較高，佔很大一筆支出， 相對來說自研可以節省成本，技術成面比直接用SDK相對可控。
模組四、相關技術知識點概括 （袁崢Seemygo分享）
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資料分發 *
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
在直播系統中的主要作用是實現觀眾與主播、觀眾與觀眾之間的文字互動.
七牛雲直播流程
開篇，將從整體介紹直播中的各個環節。
1.採集
採集是播放環節中的第一環，iOS 系統因為軟硬體種類不多，硬體適配性較好，所以比較簡單。Android 則不同，市面上硬體機型非常多，難以做到一個庫適配所有硬體。PC 端的採集也跟各種攝像頭驅動有關，推薦使用目前市面上最好用的 PC 端開源免費軟體 OBS。
- 音訊採集
音訊資料既能與影象結合組合成視訊資料，也能以純音訊的方式採集播放，後者在很多成熟的應用場景如線上電臺和語音電臺等起著非常重要的作用。音訊的採集過程主要通過裝置將環境中的模擬訊號採整合 PCM 編碼的原始資料，然後編碼壓縮成 MP3 等格式的資料分發出去。常見的音訊壓縮格式有：MP3，AAC，OGG，WMA，Opus，FLAC，APE，m4a 和 AMR 等。
音訊採集和編碼主要面臨的挑戰在於：延時敏感、卡頓敏感、噪聲消除（Denoise）、回聲消除（AEC）、靜音檢測（VAD）和各種混音演算法等。
在音訊採集階段，參考的主要技術引數有 ：
取樣率（samplerate）：取樣就是把模擬訊號數字化的過程，取樣頻率越高，記錄這一段音訊訊號所用的資料量就越大，同時音訊質量也就越高。
位寬：每一個取樣點都需要用一個數值來表示大小，這個數值的資料型別大小可以是：4bit、8bit、16bit、32bit 等等，位數越多，表示得就越精細，聲音質量自然就越好，而資料量也會成倍增大。我們在音訊取樣過程中常用的位寬是 8bit 或者 16bit。
聲道數（channels）：由於音訊的採集和播放是可以疊加的，因此，可以同時從多個音訊源採集聲音，並分別輸出到不同的揚聲器，故聲道數一般表示聲音錄製時的音源數量或回放時相應的揚聲器數量。聲道數為 1 和 2 分別稱為單聲道和雙聲道，是比較常見的聲道引數。
音訊幀（frame）：音訊跟視訊很不一樣，視訊每一幀就是一張影象，而從上面的正玄波可以看出，音訊資料是流式的，本身沒有明確的一幀幀的概念，在實際的應用中，為了音訊演算法處理/傳輸的方便，一般約定俗成取 2.5ms~60ms 為單位的資料量為一幀音訊。這個時間被稱之為“取樣時間”，其長度沒有特別的標準，它是根據編解碼器和具體應用的需求來決定的。
根據以上定義，我們可以計算一下一幀音訊幀的大小。假設某音訊訊號是取樣率為 8kHz、雙通道、位寬為 16bit，20ms 一幀，則一幀音訊資料的大小為：
size = 8000 x 2 x 16bit x 0.02s = 5120 bit = 640 byte
- 影象採集
影象採集的圖片結果組合成一組連續播放的動畫，即構成視訊中可肉眼觀看的內容。影象的採集過程主要由攝像頭等裝置拍攝成 YUV 編碼的原始資料，然後經過編碼壓縮成 H.264 等格式的資料分發出去。常見的視訊封裝格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。
影象由於其直觀感受最強並且體積也比較大，構成了一個視訊內容的主要部分。影象採集和編碼面臨的主要挑戰在於：裝置相容性差、延時敏感、卡頓敏感以及各種對影象的處理操作如美顏和水印等。
在影象採集階段，參考的主要技術引數有：
影象傳輸格式：通用影像傳輸格式（Common Intermediate Format）是視訊會議（video conference）中常使用的影像傳輸格式。
影象格式：通常採用 YUV 格式儲存原始資料資訊，其中包含用 8 位表示的黑白影象灰度值，以及可由 RGB 三種色彩組合成的彩色影象。
傳輸通道：正常情況下視訊的拍攝只需 1 路通道，隨著 VR 和 AR 技術的日漸成熟，為了拍攝一個完整的 360° 視訊，可能需要通過不同角度拍攝，然後經過多通道傳輸後合成。
解析度：隨著裝置螢幕尺寸的日益增多，視訊採集過程中原始視訊解析度起著越來越重要的作用，後續處理環節中使用的所有視訊解析度的定義都以原始視訊解析度為基礎。視訊採集卡能支援的最大點陣反映了其解析度的效能。
取樣頻率：取樣頻率反映了採集卡處理影象的速度和能力。在進行高度影象採集時，需要注意採集卡的取樣頻率是否滿足要求。取樣率越高，影象質量越高，同時儲存這些影象資訊的資料量也越大。
以上，構成了一個視訊採集的主要技術引數，以及視訊中音訊和影象編碼的常用格式。而對於直播 App 開發者來說，瞭解這些細節雖然更有幫助，但實際開發過程中可能很少能夠關注採集環節中技術引數的控制，而是直接在 SDK 中將採集後的資料傳遞給下一個「處理」和「編碼」環節。
2.處理
視訊或者音訊完成採集之後得到原始資料，為了增強一些現場效果或者加上一些額外的效果，我們一般會在將其編碼壓縮前進行處理，比如打上時間戳或者公司 Logo 的水印，祛斑美顏和聲音混淆等處理。在主播和觀眾連麥場景中，主播需要和某個或者多個觀眾進行對話，並將對話結果實時分享給其他所有觀眾，連麥的處理也有部分工作在推流端完成。
開放式設計
如上圖所示，處理環節中分為音訊和視訊處理，音訊處理中具體包含混音、降噪和聲音特效等處理，視訊處理中包含美顏、水印、以及各種自定義濾鏡等處理。
「80% 的主播沒有美顏根本沒法看。」不光是美顏，很多其它的視訊處理如模糊效果、水印等也都是在這個環節做。目前 iOS 端比較知名的是 GPUImage 這個庫，提供了豐富端預處理效果，還可以基於這個庫自己寫演算法實現更豐富端效果。Android 也有 GPUImage 這個庫的移植，叫做 android-gpuimage。同時，Google 官方開源了一個偉大的庫，覆蓋了 Android 上面很多多媒體和圖形影象相關的處理。
美顏的主要原理是通過「磨皮+美白」來達到整體美顏的效果。磨皮的技術術語是「去噪」，也即對影象中的噪點進行去除或者模糊化處理，常見的去噪演算法有均值模糊、高斯模糊和中值濾波等。當然， 由於臉部的每個部位不盡相同，臉上的雀斑可能呈現出眼睛黑點的樣子，對整張影象進行「去噪」處理的時候不需要將眼睛也去掉，因此這個環節中也涉及到人臉和皮膚檢測技術。
3.編碼和封裝
編碼主要難點有兩個：1. 處理硬體相容性問題。2. 在高 fps、低 bitrate 和音質畫質之間找到平衡。iOS 端硬體相容性較好，可以直接採用硬編。而 Android 的硬編的支援則難得多，需要支援各種硬體機型，推薦使用軟編。
為什麼封裝？
原始視訊資料儲存空間大，一個 1080P 的 7 s 視訊需要 817 MB
原始視訊資料傳輸佔用頻寬大，10 Mbps 的頻寬傳輸上述 7 s 視訊需要 11 分鐘
而經過 H.264 編碼壓縮之後，視訊大小隻有 708 k ,10 Mbps 的頻寬僅僅需要 500 ms ，可以滿足實時傳輸的需求，所以從視訊採集感測器採集來的原始視訊勢必要經過視訊編碼。
基本原理
那為什麼巨大的原始視訊可以編碼成很小的視訊呢？這其中的技術是什麼呢？核心思想就是去除冗餘資訊：
空間冗餘：影象相鄰畫素之間有較強的相關性
時間冗餘：視訊序列的相鄰影象之間內容相似
編碼冗餘：不同畫素值出現的概率不同
視覺冗餘：人的視覺系統對某些細節不敏感
知識冗餘：規律性的結構可由先驗知識和背景知識得到
詳細介紹：七牛的編碼和封裝原理
4.推流和傳輸
傳輸涉及到很多端：從主播端到服務端，從收流服務端到邊緣節點，以及再從邊緣節點到觀眾端。
推流端和分發端理論上需要支援的併發使用者數應該都是億級的，不過畢竟產生內容的推流端在少數，和消費內容端播放端不是一個量級，但是他們對推流穩定性和速度的要求比播放端高很多，這涉及到所有播放端能否看到直播，以及直播端質量如何。
詳情介紹: 推流和傳輸
5.轉碼
為了讓主播推上來的流適配各個平臺端各種不同協議，需要在服務端做一些流處理工作，比如轉碼成不同格式支援不同協議如 RTMP、HLS 和 FLV，一路轉多路流來適配各種不同的網路狀況和不同解析度的終端裝置。
6.解碼和渲染
解碼和渲染，也即音視訊的播放，目前 iOS 端的播放相容性較好，在延遲可接受的情況下使用 HLS 協議是最好的選擇，我們也提供了能夠播放 RTMP 和 HLS 的播放器 SDK。Android 的硬體解碼和編碼一樣也存在相容性問題，目前比較好的開源播放器是基於 ffplay 的 ijkplayer，
gitHub程式碼地址
Object-C版 : https://github.com/one-tea/ZKKLiveDemo
Swift版 : https://github.com/one-tea/ZKKLiveAPP_Swift3.0 （swift更新到現在越加簡潔 , 如果感覺不錯請給予鼓勵 ）
總結 ：到此介紹了直播大致功能模組 ，底層技術不懂沒關係，我在接下來的【採集篇】、【伺服器搭建+推流篇】、【播放篇】中教你如何運用這些封裝好的庫來建立你自己的直播！
當然一個直播還有許多功能： 禮物、IM聊天、 彈幕 、連麥等後續整理出來,待完善，喜歡的朋友可以關注！