直播基本流程
1.1、采集【AVFoundation】
? ? ? ? 創(chuàng)建捕捉會話AVCaptureSession:startRunning開始采集
? ? ? ? 輸入源（AVCaptureDeviceInput）：從攝像頭輸入
? ? ? ? 輸入源（AVCaptureDeviceInput）：從話筒輸入
? ? ? ? 創(chuàng)建AVCaptureMovieFileOutput 用于將音頻視頻寫入文件
1.2、前處理：美顏，濾鏡，水印
? ? ? 【GPUImage】：GPUImage是利用GPU，使在圖片和視頻上應(yīng)用不同的效果和濾鏡變得非常的容易（120種），同時它還擁有出色的性能，并且它的性能要比蘋果內(nèi)置的相關(guān)APIs出色。
??????? 如高斯模糊：
?????? let processView =GPUImagePicture(image: sourceImage)
?????? let blurFilter =GPUImageGaussianBlurFilter()
?????? // 紋理大小blurFilter.texelSpacingMultiplier =2.0
??????? processView?.addTarget(blurFilter)
? ? ? ? 【GPUImage美顏相機】
GPUImageStillCamera->GPUImageFilter->GPUImageView 這樣,攝像機轉(zhuǎn)到濾鏡再轉(zhuǎn)到view上顯示出來.
? ? ? ?? GPUImageStillCamera* imageCamera;//可以理解為設(shè)備
??????? GPUImageFilter* filter;//filter濾鏡
??????? viewGPUImageView* iv;? //顯示出來的
1.3、編碼：視頻壓縮，音頻壓縮
為了不讓用戶感受到卡頓效果, 1秒鐘之內(nèi)至少需要16幀畫面(正常開發(fā)通常會采集30幀)
去除冗余信息的過程，我們就稱之為壓縮編碼
? ? ? 【硬編碼】使用GPU解碼（ios8之前不可以硬編碼，8之后可用VideoToolBox&AudioToolbox）
????????? 「優(yōu)缺點：軟參數(shù)調(diào)整方便，升級易，但CPU負(fù)載重，性能比硬低」
????????? 「優(yōu)缺點：硬對CPU無壓力，但是對GPU要求較高」
? ? ? 【軟編碼】使用CPU解碼（ffmpeg+x264）（手機發(fā)燙）：android難以找到統(tǒng)一庫兼容平臺，通常軟編。
?????? 【編碼標(biāo)準(zhǔn)】音頻：AAC、Opus。 視頻：H.264（高壓縮高質(zhì)量和支持多種網(wǎng)絡(luò)的流媒體傳輸）、H.265、VP8、VP9
?? ? ? 【編碼流程】：
????????? 1、在進(jìn)行當(dāng)前信號編碼時，編碼器首先會產(chǎn)生對當(dāng)前信號做預(yù)測的信號，稱作預(yù)測信號
????????? 2、 得到預(yù)測信號后，編碼器會將當(dāng)前信號與預(yù)測信號相減得到殘余信號（residual signal），并只對殘余信號進(jìn)行編碼
? ? ? ? ? 3、編碼器并不會直接對殘余信號進(jìn)行編碼，而是先將殘余信號經(jīng)過變換（通常為離散余弦變換）然后量化以進(jìn)一步去除空間上和感知上的冗余信息
? ? ? ? ? 4、量化后得到的量化系數(shù)會再透過熵編碼，去除統(tǒng)計上的冗余信息
H.264壓縮算法要點：（NAL【網(wǎng)絡(luò)提取層】+VCL【視頻編碼層】）
【VCL介紹】
????????? 1、在H264協(xié)議里定義了三種幀
I幀：完整編碼的幀叫I幀
P幀：參考之前的I幀生成的只包含差異部分編碼的幀叫P幀
B幀：參考前后的幀編碼的幀叫B幀
????????? 2、H264采用的核心算法是幀內(nèi)壓縮和幀間壓縮
幀內(nèi)壓縮是生成I幀的算法
幀間壓縮是生成B幀和P幀的算法
????????? 3、H264的壓縮方法:
3.1、分組:把幾幀圖像分為一組GOP，為防止運動變化,幀數(shù)不宜取多。
GOP即Group of picture（圖像組），指兩個I幀之間的距離，也就是一個序列，一個序列的第一個圖像叫做 IDR 圖像，IDR 圖像都是 I 幀圖像：如果前一個序列出現(xiàn)重大錯誤，在這里可以獲得重新同步的機會),
3.2、定義幀:將每組內(nèi)各幀圖像定義為三種類型,即I幀、B幀和P幀;
3.3、預(yù)測幀:以I幀做為基礎(chǔ)幀,以I幀預(yù)測P幀,再由I幀和P幀預(yù)測B幀;
3.4、數(shù)據(jù)傳輸:最后將I幀數(shù)據(jù)與預(yù)測的差值信息進(jìn)行存儲和傳輸。
【NAL介紹】
3.1、根據(jù)不同的網(wǎng)絡(luò)把數(shù)據(jù)打包成相應(yīng)的格式，將VCL產(chǎn)生的比特字符串適配到各種各樣的網(wǎng)絡(luò)和多元環(huán)境中。
3.2、I幀、P幀、B幀都是被封裝成一個或者多個NALU進(jìn)行傳輸或者存儲的
3.3、NALU頭通常為00 00 00 01，作為一個新的NALU的起始標(biāo)識
3.4、NALU體封裝著VCL編碼后的信息或者其他信息
FFMpeg + X264 軟編碼
FFMpeg：非常強大的音視頻處理庫,包括視頻采集功能、視頻格式轉(zhuǎn)換、視頻抓圖、給視頻加水印等
x264:里面集成了非常多優(yōu)秀的算法用于視頻編碼
1.4、推流：將編碼推送給服務(wù)器
??????? 將數(shù)據(jù)經(jīng)過采集預(yù)處理，編碼后推流到服務(wù)器
?????? 【傳輸協(xié)議】RTMP、RTSP、HLS
HLS協(xié)議：
?????? HLS：Apple基于HTTP的流媒體傳輸協(xié)議，HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲為連續(xù)的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因為服務(wù)器端總是會將最新的直播數(shù)據(jù)生成新的小文件，這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件，就實現(xiàn)了直播。
HLS工作流程為:
采集視頻源和音頻源的數(shù)據(jù)
對原始數(shù)據(jù)進(jìn)行H264編碼和AAC編碼
視頻和音頻數(shù)據(jù)封裝為MPEG-TS包
HLS分段生成策略及m3u8索引文件
HTTP傳輸協(xié)議傳輸數(shù)據(jù)
RTMP協(xié)議：
基于TCP的應(yīng)用層協(xié)議優(yōu)勢如下：
實時性高，延遲在3S內(nèi)，若對實時性有要求，建議用RTMP。
支持加密；
穩(wěn)定性高。
播放一個RTMP協(xié)議的流媒體需要經(jīng)過以下幾個步驟：握手，建立連接，建立流，播放。RTMP連接都是以握手作為開始的。建立連接階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)連接”；建立流階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)流”；播放階段用于傳輸視音頻數(shù)據(jù)
RTMP傳輸媒體數(shù)據(jù)的過程中，發(fā)送端首先把媒體數(shù)據(jù)封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過TCP協(xié)議發(fā)送出去。接收端在通過TCP協(xié)議收到數(shù)據(jù)后，首先把消息塊重新組合成消息，然后通過對消息進(jìn)行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。
推流框架LFLiveKit是一個集成了視頻采集-美顏-編碼-推流為一體的框架,并且使用起來非常的簡單, 我們可以在iOS中直接使用該框架進(jìn)行推流
1.5、流分發(fā)：服務(wù)器進(jìn)一步視頻轉(zhuǎn)碼
?????? 服務(wù)端為適配各個平臺各種不同協(xié)議，需要做一些流處理工作，比如轉(zhuǎn)碼成不同格式，支持不同協(xié)議等。
1.6、播放
?????? 拉流獲取數(shù)據(jù)后，需要編碼器解碼渲染才可以在播放器上播放：
? ? ? 解協(xié)議：取出網(wǎng)絡(luò)傳輸過程中一些無用信息
????? 解封裝：獲取到的是音頻&視頻放在一起的封裝文件
????? 音視頻解碼：音視頻都是經(jīng)過壓縮編碼的內(nèi)容，解碼后才能進(jìn)行播放
??? ? 音視頻同步：視頻&音頻文件需要通過播放
????? 音視頻播放：聲卡&顯卡等對音視頻進(jìn)行播放
