一评雌、流媒體(直播需要用到流媒體)
-
流媒體開發(fā)：網(wǎng)絡(luò)層負責(zé)傳輸(socket)，協(xié)議層負責(zé)網(wǎng)絡(luò)打包(RTMP/HLS)，封裝層(flv,ts)負責(zé)編碼毛甲、解碼數(shù)據(jù)的封裝，編碼層負責(zé)圖像視頻的壓縮(H264/AAC)具被。 -
幀：每幀代表一副靜止的圖像玻募。 -
GOP：(Group of pictures)畫面組，一個GOP就是一組連續(xù)的畫面一姿，每個畫面都是一個幀七咧，一個GOP就是很多幀的集合跃惫。
直播數(shù)據(jù)：其實就是一組圖片，包括I幀坑雅、P幀辈挂、B幀，當(dāng)用戶第一次觀看的時候裹粤，會尋找I幀终蒂，而播放器會到服務(wù)器尋找到最近的I幀反饋給用戶。因此遥诉，GOP增加了端到端的延遲拇泣，因為它必須要拿到最近的幀。 -
碼率：圖片進行壓縮后每秒顯示的數(shù)據(jù)量矮锈。 -
幀率：每秒顯示的圖片數(shù)(FPS)霉翔。幀越大越流暢，幀越小越卡頓苞笨。
電影制作者發(fā)現(xiàn)一旦將幀數(shù)提升到24幀债朵，人眼就能讓組成影片的一幅幅圖像流暢的合為一體（其實這是大腦的感覺），因此將24幀定為了行業(yè)標(biāo)準瀑凝。游戲制作公司一般把流暢游戲的標(biāo)準定為30FPS序芦，推薦標(biāo)準定為60FPS，多數(shù)液晶顯示器的刷新率也是60Hz粤咪。 -
壓縮比：壓縮前的每秒數(shù)據(jù)量/壓縮后的每秒數(shù)據(jù)量(碼率)谚中。壓縮比越高，也就意味著碼率越低寥枝，畫質(zhì)越模糊宪塔。 -
視頻文件格式：文件的后綴，比如：mp4囊拜、mp3某筐、mov、wmv艾疟、avi来吩。
用處：根據(jù)文件格式，系統(tǒng)會自動判斷用什么軟件打開蔽莱。注意一點弟疆，修改文件的格式并不會對文件本身造成太大的影響，如把avi改成mp4盗冷，其實文件還是avi怠苔。 -
視頻封裝格式：一種存儲視頻信息的容器，流式封裝有TS仪糖、FLV等柑司，索引式的封裝有MP4迫肖、MOV、AVI等攒驰。
主要作用：一個視頻文件包含圖像蟆湖、音頻以及一些配置信息(圖像和音頻的關(guān)聯(lián)，怎么去解碼它們等)玻粪，這些內(nèi)容需要按照一定的規(guī)則隅津，組織封裝起來。
疑問點：你會發(fā)現(xiàn)劲室，視頻的封裝格式和視頻的文件格式一樣伦仍，因為一般視頻文件格式的后綴名就是采用封裝格式的名稱，所以視頻文件格式就是視頻封裝格式很洋。
二充蓝、直播的基礎(chǔ)知識
1、采集視頻喉磁、音頻
1.1 采集音視頻編碼框架
-
AVFoundation:AVFoundation是用來播放和創(chuàng)建實時視聽媒體數(shù)據(jù)框架谓苟，同時提供OC接口來操作這些視聽數(shù)據(jù)，比如編輯协怒、旋轉(zhuǎn)娜谊、重編碼。
1.2 音視頻硬件設(shè)備
-
CCD:圖像傳感器斤讥，用于圖像采集和處理過程，把圖像轉(zhuǎn)換成電信號湾趾。 -
拾音器:聲音傳感器芭商，用于聲音的采集和處理過程，把聲音轉(zhuǎn)換成電信號搀缠。 -
音頻采樣數(shù)據(jù):一般都是PCM格式铛楣。 -
視頻采樣數(shù)據(jù):一般都是YUV或者RGB格式，由于采集到的音視頻的體積非常大艺普，所以需要經(jīng)過壓縮技術(shù)處理來提高傳輸效率簸州。
2、視頻處理（美顏歧譬、水影痘搿）
視頻處理原理:因為視頻最終通過GPU，一幀幀的渲染到屏幕上的瑰步，所以我們可以利用OpenGL ES矢洲，對視頻進行各種加工，從而實現(xiàn)各種不同的效果缩焦。目前各種美顏和視頻添加特效的APP都是用GUIImage這個框架實現(xiàn)的读虏。GUIImage:GUIImage是一個基于OpenGL ES的一個強大的圖像/視頻處理框架责静，封裝好了各種濾鏡同時也可以編寫自定義的濾鏡，其本身內(nèi)置了多達120多種的濾鏡效果盖桥。OpenGL：OpenGL(Open Graphics Library)是個定義了一個跨編程語言灾螃、跨平臺的編程接口的規(guī)格，它用于三維圖象（二維的亦可）揩徊。OpenGL是個專業(yè)的圖形程序接口腰鬼，是一個功能強大，調(diào)用方便的底層圖形庫靴拱。OpenGL ES：OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集垃喊，針對手機、PDA和游戲主機等嵌入式設(shè)備而設(shè)計袜炕。
三本谜、視頻編碼、解碼
1偎窘、視頻編碼框架
-
FFMPEG：跨平臺的開源視頻框架乌助，能實現(xiàn)如視頻編碼、解碼陌知、轉(zhuǎn)碼他托、串流、播放等豐富的功能仆葡。器支持的視頻格式以及播放協(xié)議很豐富赏参，幾乎包含了所有的音視頻編解碼、封裝格式以及播放協(xié)議沿盅。 -
X264：把視頻原數(shù)據(jù)YUV壓縮成H264格式把篓。 -
VideoToolbox：蘋果自帶的視頻硬編碼API，在iOS8之后才開放腰涧。 -
AudioToolbox：蘋果自帶的音頻硬編碼API韧掩。
2、視頻編碼技術(shù)
-
視頻壓縮編碼標(biāo)準：對視頻進行壓縮或者解壓縮的編碼技術(shù)窖铡，比如MPEG疗锐、H.264，這些視頻編碼技術(shù)是用來壓縮編碼視頻的费彼。
主要作用：是將視頻像素數(shù)據(jù)壓縮成為視頻碼流滑臊，降低視頻的數(shù)據(jù)量。一部上百G的電影壓縮之后也就幾G敌买。
注意：最影響視頻質(zhì)量的是其視頻編碼數(shù)據(jù)和音頻編碼數(shù)據(jù)简珠，跟封裝格式?jīng)]多大關(guān)系。 -
MPEG：一種視頻壓縮方式，采用看幀間壓縮聋庵，僅存儲連續(xù)幀之間有差別的地方膘融，從而達到比較大的壓縮比。 -
H.264/AVC：一種視頻壓縮方式祭玉，采用事先預(yù)測和與MPEG中的P-B幀一樣的幀預(yù)測方法壓縮氧映，它可以根據(jù)需要產(chǎn)生適合網(wǎng)絡(luò)情況傳輸?shù)囊曨l流,還有更高的壓縮比，有更好的圖象質(zhì)量脱货。
注意1：如果從單個畫面清晰度比較岛都，MPEG有優(yōu)勢；從動作連貫性上的清晰度振峻，H.264有優(yōu)勢臼疫。
注意2：H.264算法更加復(fù)雜，程序?qū)崿F(xiàn)繁瑣扣孟，運行它需要更多的處理器和內(nèi)存資源烫堤。因此，運行H264對系統(tǒng)要求還是比較高的凤价。
注意3：由于264的實現(xiàn)更加靈活鸽斟，它把一些實現(xiàn)留給了廠商自己去實現(xiàn)，雖然這樣給實現(xiàn)帶來了很多好處利诺，但是不同產(chǎn)品之間互通成了很大的問題富蓄，造成了通過A公司的編碼器編出的數(shù)據(jù)，必須通過A公司的解碼器去解這樣尷尬的事情慢逾。 -
H.265/HEVC：一種視頻壓縮方式,基于H.264立倍，保留原來的某些技術(shù)，同時對一些相關(guān)的技術(shù)加以改進侣滩，以改善碼流帐萎、編碼質(zhì)量、延時和算法復(fù)雜度之間的關(guān)系胜卤，達到最優(yōu)化設(shè)置。 -
I幀：(關(guān)鍵幀)保留一副完整的畫面赁项，解碼時只需要本幀數(shù)據(jù)就可以完成（包含了完整的畫面）葛躏。 -
P幀：(差別幀)保留本幀和之前幀的差別，解碼時需要用之前緩存的畫面疊加上本幀定義的差別悠菜，生成最終畫面舰攒。（P幀沒有完整畫面，只有與前一幀畫面差別的數(shù)據(jù)） -
B幀：(雙向差別幀)保留的是本幀與前后幀的差別悔醋，解碼B幀摩窃，不僅要取得之前緩存的畫面，還要解碼之后的畫面，通過前后畫面與本幀數(shù)據(jù)的疊加取得最終的畫面猾愿。B幀的壓縮率高鹦聪，但是解碼時也會更加耗費CPU。 -
幀內(nèi)（Intraframe）壓縮：當(dāng)壓縮一幀圖像時蒂秘，僅考慮本幀的數(shù)據(jù)而不考慮相鄰幀之間的冗余信息,幀內(nèi)一般采用有損壓縮算法泽本。 -
幀間（Interframe）壓縮：時間壓縮（Temporal compression），它通過比較時間軸上不同幀之間的數(shù)據(jù)進行壓縮姻僧。幀間壓縮一般是無損的规丽。 -
muxing（合成）：將視頻流、音頻流甚至是字幕流封裝到一個文件中(容器格式（FLV撇贺，TS）)赌莺，作為一個信號進行傳輸。
三松嘶、音頻編碼技術(shù)與視頻封裝技術(shù)
-
AAC艘狭、mp3：音頻編碼技術(shù)，用于壓縮音頻喘蟆。 -
多碼率：現(xiàn)實場景很復(fù)雜缓升，有可能是WiFi，有可能4G蕴轨、3G港谊、甚至2G，那么怎么滿足多方需求呢橙弱？多搞幾條線路歧寺，根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境自定義碼率。常臣辏看見視頻播放軟件中的1024斜筐，720，高清蛀缝，標(biāo)清顷链，流暢等，指的就是各種碼率屈梁。 -
TS：一種流媒體封裝格式嗤练，流媒體封裝有一個好處，就是不需要加載索引再播放在讶，大大減少了首次載入的延遲煞抬，如果片子比較長，mp4文件的索引相當(dāng)大构哺，影響用戶體驗革答。
TS優(yōu)點：兩個TS片段可以無縫拼接，播放器能連續(xù)播放 -
FLV：一種流媒體封裝格式,由于它形成的文件極小、加載速度極快残拐，使得網(wǎng)絡(luò)觀看視頻文件成為可能,因此FLV格式成為了當(dāng)今主流視頻格式途茫。
四、推流
-
數(shù)據(jù)傳輸框架：librtmp用來傳輸RTMP協(xié)議格式的數(shù)據(jù)蹦骑。 -
流媒體數(shù)據(jù)傳輸協(xié)議：RTMP實時消息傳輸協(xié)議慈省，Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議眠菇，因為是開放協(xié)議所以都可以使用了边败。
1、RTMP協(xié)議用于對象捎废、視頻笑窜、音頻的傳輸。
2登疗、這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上排截。
3、RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器辐益，這些數(shù)據(jù)可以是FLV中的視音頻數(shù)據(jù)断傲。一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流，這些通道中的包都是按照固定大小的包傳輸?shù)摹?/code>
五智政、流媒體服務(wù)器
常用服務(wù)器：
-
SRS：一款國人開發(fā)的優(yōu)秀開源流媒體服務(wù)器系統(tǒng)认罩。 -
BMS：也是一款流媒體服務(wù)器系統(tǒng)，但不開源续捂，是SRS的商業(yè)版垦垂，比SRS功能更多 -
nginx：免費開源web服務(wù)器，常用來配置流媒體服務(wù)器牙瓢。
數(shù)據(jù)分發(fā)： -
CDN：(Content Delivery Network)劫拗，即內(nèi)容分發(fā)網(wǎng)絡(luò),將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)”邊緣”，使用戶可以就近取得所需的內(nèi)容矾克，解決 Internet網(wǎng)絡(luò)擁擠的狀況页慷，提高用戶訪問網(wǎng)站的響應(yīng)速度。 -
CDN：代理服務(wù)器胁附，相當(dāng)于中介差购。 -
工作原理：請求流媒體數(shù)據(jù)
1.上傳流媒體數(shù)據(jù)到服務(wù)器（源站）
2.源站存儲流媒體數(shù)據(jù)
3.客戶端播放流媒體，向CDN請求編碼后的流媒體數(shù)據(jù)
4.CDN的服務(wù)器響應(yīng)請求汉嗽，若節(jié)點上沒有該流媒體數(shù)據(jù)存在，則向源站繼續(xù)請求流媒體數(shù)據(jù)找蜜；若節(jié)點上已經(jīng)緩存了該視頻文件饼暑，則跳到第6步。
5.源站響應(yīng)CDN的請求，將流媒體分發(fā)到相應(yīng)的CDN節(jié)點上弓叛。
6.CDN將流媒體數(shù)據(jù)發(fā)送到客戶端彰居。 -
回源：當(dāng)有用戶訪問某一個URL的時候，如果被解析到的那個CDN節(jié)點沒有緩存響應(yīng)的內(nèi)容撰筷，或者是緩存已經(jīng)到期陈惰，就會回源站去獲取搜索。如果沒有人訪問毕籽，那么CDN節(jié)點不會主動去源站拿抬闯。 -
帶寬：在固定時間可傳輸?shù)臄?shù)據(jù)總量。
比如64位关筒、800MHz的前端總線溶握，它的數(shù)據(jù)傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s（1Byte = 8bit） -
負載均衡：由多臺服務(wù)器以對稱的方式組成一個服務(wù)器集合，每臺服務(wù)器都具有等價的地位蒸播，都可以單獨對外提供服務(wù)而無須其他服務(wù)器的輔助睡榆。
1.通過某種負載分擔(dān)技術(shù)，將外部發(fā)送來的請求均勻分配到對稱結(jié)構(gòu)中的某一臺服務(wù)器上袍榆，而接收到請求的服務(wù)器獨立地回應(yīng)客戶的請求胀屿。
2.均衡負載能夠平均分配客戶請求到服務(wù)器列陣，籍此提供快速獲取重要數(shù)據(jù)，解決大量并發(fā)訪問服務(wù)問題百炬。
3.這種群集技術(shù)可以用最少的投資獲得接近于大型主機的性能货邓。 -
QOS(帶寬管理)：限制每一個組群的帶寬，讓有限的帶寬發(fā)揮最大的效用劳曹。
六、拉流
直播協(xié)議：
1琅摩、即時性要求較高或有互動需求的可以采用RTMP,RTSP
2铁孵、對于有回放或跨平臺需求的，推薦使用HLSHLS：由Apple公司定義的用于實時流傳輸?shù)膮f(xié)議,HLS基于HTTP協(xié)議實現(xiàn)房资，傳輸內(nèi)容包括兩部分蜕劝，一是M3U8描述文件，二是TS媒體文件轰异♂妫可實現(xiàn)流媒體的直播和點播，主要應(yīng)用在iOS系統(tǒng)搭独。
HLS是以點播的技術(shù)方式來實現(xiàn)直播.
HLS是自適應(yīng)碼率流播婴削，客戶端會根據(jù)網(wǎng)絡(luò)狀況自動選擇不同碼率的視頻流，條件允許的情況下使用高碼率牙肝，網(wǎng)絡(luò)繁忙的時候使用低碼率唉俗，并且自動在二者間隨意切 換嗤朴。這對移動設(shè)備網(wǎng)絡(luò)狀況不穩(wěn)定的情況下保障流暢播放非常有幫助。
實現(xiàn)方法是服務(wù)器端提供多碼率視頻流虫溜，并且在列表文件中注明雹姊，播放器根據(jù)播放進度和下載速度自動調(diào)整。HLS與RTMP對比：HLS主要是延時比較大衡楞，RTMP主要優(yōu)勢在于延時低吱雏。
HLS協(xié)議的小切片方式會生成大量的文件，存儲或處理這些文件會造成大量資源浪費瘾境。
相比使用RTSP協(xié)議的好處在于歧杏，一旦切分完成，之后的分發(fā)過程完全不需要額外使用任何專門軟件寄雀，普通的網(wǎng)絡(luò)服務(wù)器即可得滤，大大降低了CDN邊緣服務(wù)器的配置要求，可以使用任何現(xiàn)成的CDN,而一般服務(wù)器很少支持RTSP盒犹。HTTP-FLV：基于HTTP協(xié)議流式的傳輸媒體內(nèi)容懂更。
相對于RTMP，HTTP更簡單和廣為人知急膀，內(nèi)容延遲同樣可以做到1~3秒，打開速度更快卓嫂，因為HTTP本身沒有復(fù)雜的狀態(tài)交互慷暂。所以從延遲角度來看晨雳，HTTP-FLV要優(yōu)于RTMP行瑞。RTSP：實時流傳輸協(xié)議,定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù).RTP：實時傳輸協(xié)議,RTP是建立在UDP協(xié)議上的餐禁，常與RTCP一起使用血久，其本身并沒有提供按時發(fā)送機制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實現(xiàn)這一過程帮非。RTP：RTP的配套協(xié)議,主要功能是為RTP所提供的服務(wù)質(zhì)量（QoS）提供反饋氧吐，收集相關(guān)媒體連接的統(tǒng)計信息，例如傳輸字節(jié)數(shù)筑舅，傳輸分組數(shù)，丟失分組數(shù)陨舱，單向和雙向網(wǎng)絡(luò)延遲等等。
七游盲、解碼
解封裝：
-
demuxing（分離)：從視頻流误墓、音頻流邦尊，字幕流合成的文件(容器格式（FLV，TS）)中优烧， 分解出視頻、音頻或字幕链峭，各自進行解碼畦娄。
音頻編碼框架 : -
fdk_aac：音頻編碼解碼框架弊仪，PCM音頻數(shù)據(jù)和AAC音頻數(shù)據(jù)互轉(zhuǎn)熙卡。
解碼介紹： -
硬解碼：使用GPU解碼，減少CPU的使用励饵。
優(yōu)點：播放流暢、低功耗役听，解碼速度快。
缺點：兼容不好典予。 -
軟解碼：CPU解碼
優(yōu)點：兼容好
缺點：加大CPU負擔(dān)，耗電增加瘤袖、沒有硬解碼流暢衣摩，解碼速度相對慢捂敌。
八艾扮、播放
-
ijkplayer：一個基于FFmpeg的開源Android/iOS視頻播放器占婉。
API易于集成;
編譯配置可裁剪泡嘴，方便控制安裝包大腥裱摹；
支持硬件加速解碼纹腌，更加省電;
簡單易用，指定拉流URL升薯，自動解碼播放;
特別感謝莱褒，袁崢同學(xué)涎劈，上面的文字基本都是自己一個一個碼出來的阅茶，我再次寫下來他的總結(jié)只是為了加深記憶，且方便自己的閱讀谅海。
資料來源
