前言：每個(gè)成功者多是站在巨人的肩膀上蝙泼！在做直播開發(fā)時(shí) 碰到了很多問題寥粹，在收集了許多人博客的基礎(chǔ)上做出來(lái)了成功的直播項(xiàng)目并做了整理宋距，并在最后奉上我的全部代碼轴踱。
其中采用博客的博主開篇在此感謝，本著開源分享的精神谚赎，我會(huì)將前輩的知識(shí)和自己開發(fā)中遇到的問題整理出完整的一套開發(fā)流程淫僻，再次希望采用的博主，能夠容許使用并再次感謝壶唤！ 大多內(nèi)容其他博客給出不錯(cuò)詳解就整理摘抄到此篇雳灵，原理篇相關(guān)技術(shù)點(diǎn)主要來(lái)自于袁崢Seemygo分享整理。采集和服務(wù)器推流會(huì)有所不同（在原有的基礎(chǔ)上添加另一種<LFLiveKit>第三方框架來(lái)采集視頻闸盔、美顏和推流等功能) , 為節(jié)省時(shí)間如有雷同之處细办，也請(qǐng)一些童靴不喜勿噴！
【目錄】
- 如何開發(fā)出一款仿映客直播APP項(xiàng)目實(shí)踐篇 -【原理篇】
- 如何開發(fā)出一款仿映客直播APP項(xiàng)目實(shí)踐篇 -【采集篇 】
- 如何開發(fā)出一款仿映客直播APP項(xiàng)目實(shí)踐篇 -【服務(wù)器搭建+推流】
- 如何開發(fā)出一款仿映客直播APP項(xiàng)目實(shí)踐篇 -【播放篇】
模塊一 ：直播技術(shù)
【 主要模塊】
- 主播端： 把主播實(shí)時(shí)錄制的視頻蕾殴，經(jīng)過(guò)（采集笑撞、美顏處理、編碼）推送到服務(wù)器
- 服務(wù)器： 處理（轉(zhuǎn)碼钓觉、錄制茴肥、截圖、鑒黃）后分發(fā)給用戶播放端
- 播放器： 獲取服務(wù)器地址荡灾， 進(jìn)行拉流瓤狐、解碼、渲染
- 互動(dòng)系統(tǒng)： 聊天室批幌、禮物系統(tǒng)础锐、贊
示例圖：
直播效果圖
【一個(gè)完整直播app實(shí)現(xiàn)流程】
1.采集、2.濾鏡處理荧缘、3.編碼皆警、4.推流、5.CDN分發(fā)截粗、6.拉流信姓、7.解碼鸵隧、8.播放、9.聊天互動(dòng)
【一個(gè)完整直播app架構(gòu)】
【一個(gè)完整直播app技術(shù)點(diǎn)】
模塊二意推、項(xiàng)目功能模塊 -> 技術(shù)
簡(jiǎn)介：
相對(duì)于上面圖中每個(gè)技術(shù)點(diǎn)刨開來(lái)說(shuō)都很繁瑣 豆瘫，也很難掌握，我會(huì)在下面的【相關(guān)技術(shù)知識(shí)點(diǎn)概括】中給與大致講述菊值；由于涉及音視頻的編碼解碼外驱、美顏功能的算法，幀的處理等很多問題腻窒，能從底層自己開發(fā)的完整功能的絕對(duì)是大牛略步！
不過(guò)正是有這些大牛們的奉獻(xiàn) ，我們不需要處理繁瑣的底層問題定页，一些封裝好的庫(kù)可以完美實(shí)現(xiàn)趟薄。
- 主播端: ** LFLiveKit** 已包含采集、美顏典徊、編碼杭煎、推流等功能
- 服務(wù)器 : 【 ** nginx+rtmp服務(wù)器**】免費(fèi)開源，能搭建本地電腦上卒落，支持RTMP協(xié)議羡铲，滿足直播需求。
- 播放端 : ** ijkplayer視頻直播框架** 封裝很完善只要有url儡毕，就可以實(shí)時(shí)播放
模塊三也切、如何快速的開發(fā)一個(gè)完整的iOS直播app
1、利用第三方直播SDK快速的開發(fā)
阿里云: 提供低延遲腰湾、高清晰雷恃、 高并發(fā)支持的直播服務(wù)，幫您從容應(yīng)對(duì)業(yè)務(wù)突發(fā)峰值费坊。廣泛應(yīng)用于 游戲直播倒槐、娛樂直播、泛生活直播附井、 教育類讨越、 遠(yuǎn)程醫(yī)療、 企業(yè)遠(yuǎn)程視頻會(huì)議等典型場(chǎng)景永毅，
百度直播云: 視頻直播把跨、點(diǎn)播一站式解決方案，讓視頻技術(shù)零門檻沼死，結(jié)合領(lǐng)先的人工智能技術(shù)着逐，開放智能圖像識(shí)別、視頻特效、黃反審核功能滨嘱，讓視頻內(nèi)容更豐富峰鄙，更安全
七牛云:七牛直播云是專為直播平臺(tái)打造的全球化直播流服務(wù)和一站式實(shí)現(xiàn)SDK端到端直播場(chǎng)景的企業(yè)級(jí)直播云服務(wù)平臺(tái).
2浸间、自研還是使用第三方直播SDK開發(fā)太雨？
自研： 對(duì)于一個(gè)初創(chuàng)公司或團(tuán)隊(duì)來(lái)講，自研直播不管在技術(shù)門檻魁蒜、CDN囊扳、帶寬上都是有很大的門檻的，而且需要耗費(fèi)大量的時(shí)間和成本才能做出成品兜看，不利于前期發(fā)展锥咸。
第三方SDK開發(fā)：開發(fā)周期短，前期投入少细移，從長(zhǎng)遠(yuǎn)看搏予，第三方費(fèi)用較高，占很大一筆支出弧轧， 相對(duì)來(lái)說(shuō)自研可以節(jié)省成本雪侥，技術(shù)成面比直接用SDK相對(duì)可控。
模塊四精绎、相關(guān)技術(shù)知識(shí)點(diǎn)概括 （袁崢Seemygo分享）
1.采集視頻速缨、音頻
***** 1.1 采集視頻、音頻編碼框架 *****
AVFoundation:AVFoundation是用來(lái)播放和創(chuàng)建實(shí)時(shí)的視聽媒體數(shù)據(jù)的框架代乃，同時(shí)提供Objective-C接口來(lái)操作這些視聽數(shù)據(jù)旬牲，比如編輯，旋轉(zhuǎn)搁吓，重編碼
***** 1.2 視頻原茅、音頻硬件設(shè)備 *****
CCD:圖像傳感器： 用于圖像采集和處理的過(guò)程，把圖像轉(zhuǎn)換成電信號(hào)堕仔。
拾音器:聲音傳感器： 用于聲音采集和處理的過(guò)程员咽，把聲音轉(zhuǎn)換成電信號(hào)。
音頻采樣數(shù)據(jù):一般都是PCM格式
視頻采樣數(shù)據(jù): 一般都是YUV,或RGB格式贮预，采集到的原始音視頻的體積是非常大的贝室，需要經(jīng)過(guò)壓縮技術(shù)處理來(lái)提高傳輸效率
2.視頻處理（美顏，水臃峦獭）
視頻處理原理:因?yàn)橐曨l最終也是通過(guò)GPU滑频，一幀一幀渲染到屏幕上的，所以我們可以利用OpenGL ES唤冈，對(duì)視頻幀進(jìn)行各種加工峡迷，從而視頻各種不同的效果，就好像一個(gè)水龍頭流出的水，經(jīng)過(guò)若干節(jié)管道绘搞，然后流向不同的目標(biāo)
現(xiàn)在的各種美顏和視頻添加特效的app都是利用GPUImage
這個(gè)框架實(shí)現(xiàn)的,.
***** 視頻處理框架 *****
GPUImage: GPUImage是一個(gè)基于OpenGL ES的一個(gè)強(qiáng)大的圖像/視頻處理框架,封裝好了各種濾鏡同時(shí)也可以編寫自定義的濾鏡,其本身內(nèi)置了多達(dá)120多種常見的濾鏡效果彤避。
OpenGL:OpenGL（全寫Open Graphics Library）是個(gè)定義了一個(gè)跨編程語(yǔ)言、跨平臺(tái)的編程接口的規(guī)格夯辖，它用于三維圖象（二維的亦可）琉预。OpenGL是個(gè)專業(yè)的圖形程序接口，是一個(gè)功能強(qiáng)大蒿褂，調(diào)用方便的底層圖形庫(kù)圆米。
OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集，針對(duì)手機(jī)啄栓、PDA和游戲主機(jī)等嵌入式設(shè)備而設(shè)計(jì)娄帖。
3.視頻編碼解碼
***** 3.1 視頻編碼框架 *****
FFmpeg :是一個(gè)跨平臺(tái)的開源視頻框架,能實(shí)現(xiàn)如視頻編碼,解碼,轉(zhuǎn)碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協(xié)議非常豐富,幾乎包含了所有音視頻編解碼昙楚、封裝格式以及播放協(xié)議近速。-Libswresample:可以對(duì)音頻進(jìn)行重采樣,rematrixing 以及轉(zhuǎn)換采樣格式等操 作。
-Libavcodec:提供了一個(gè)通用的編解碼框架,包含了許多視頻,音頻,字幕流 等編碼/解碼器堪旧。
-Libavformat:用于對(duì)視頻進(jìn)行封裝/解封裝削葱。
-Libavutil:包含一些共用的函數(shù),如隨機(jī)數(shù)生成,數(shù)據(jù)結(jié)構(gòu),數(shù)學(xué)運(yùn)算等。
-Libpostproc:用于進(jìn)行視頻的一些后期處理崎场。
-Libswscale:用于視頻圖像縮放,顏色空間轉(zhuǎn)換等佩耳。
-Libavfilter:提供濾鏡功能。
X264 :把視頻原數(shù)據(jù)YUV編碼壓縮成H.264格式
VideoToolbox :蘋果自帶的視頻硬解碼和硬編碼API谭跨，但是在iOS8之后才開放干厚。
AudioToolbox :蘋果自帶的音頻硬解碼和硬編碼API
***** 3.2 視頻編碼技術(shù) *****
視頻壓縮編碼標(biāo)準(zhǔn)：對(duì)視頻進(jìn)行壓縮(視頻編碼)或者解壓縮（視頻解碼）的編碼技術(shù),比如MPEG，H.264螃宙。
這些視頻編碼技術(shù)是壓縮編碼視頻的主要作用:是將視頻像素?cái)?shù)據(jù)壓縮成為視頻碼流蛮瞄，從而降低視頻的數(shù)據(jù)量。如果視頻不經(jīng)過(guò)壓縮編碼的話谆扎，體積通常是非常大的挂捅，一部電影可能就要上百G的空間。
注意:最影響視頻質(zhì)量的是其視頻編碼數(shù)據(jù)和音頻編碼數(shù)據(jù)堂湖，跟封裝格式?jīng)]有多大關(guān)系
MPEG:一種視頻壓縮方式闲先，它采用了幀間壓縮，僅存儲(chǔ)連續(xù)幀之間有差別的地方 无蜂，從而達(dá)到較大的壓縮比
H.264/AVC:一種視頻壓縮方式,采用事先預(yù)測(cè)和與MPEG中的P-B幀一樣的幀預(yù)測(cè)方法壓縮伺糠，它可以根據(jù)需要產(chǎn)生適合網(wǎng)絡(luò)情況傳輸?shù)囊曨l流,還有更高的壓縮比，有更好的圖象質(zhì)量
注意1: 如果是從單個(gè)畫面清晰度比較斥季，MPEG4有優(yōu)勢(shì)训桶；從動(dòng)作連貫性上的清晰度累驮，H.264有優(yōu)勢(shì)
注意2: 由于264的算法更加復(fù)雜，程序?qū)崿F(xiàn)煩瑣舵揭，運(yùn)行它需要更多的處理器和內(nèi)存資源谤专。因此，運(yùn)行264對(duì)系統(tǒng)要求是比較高的午绳。
注意3: 由于264的實(shí)現(xiàn)更加靈活置侍，它把一些實(shí)現(xiàn)留給了廠商自己去實(shí)現(xiàn)，雖然這樣給實(shí)現(xiàn)帶來(lái)了很多好處箱叁，但是不同產(chǎn)品之間互通成了很大的問題墅垮，造成了通過(guò)A公司的編碼器編出的數(shù)據(jù)惕医，必須通過(guò)A公司的解碼器去解這樣尷尬的事情
H.265/HEVC: 一種視頻壓縮方式,基于H.264耕漱，保留原來(lái)的某些技術(shù)，同時(shí)對(duì)一些相關(guān)的技術(shù)加以改進(jìn)抬伺，以改善碼流螟够、編碼質(zhì)量、延時(shí)和算法復(fù)雜度之間的關(guān)系峡钓，達(dá)到最優(yōu)化設(shè)置妓笙。H.265 是一種更為高效的編碼標(biāo)準(zhǔn)，能夠在同等畫質(zhì)效果下將內(nèi)容的體積壓縮得更小能岩，傳輸時(shí)更快更省帶寬
I幀: (關(guān)鍵幀)保留一副完整的畫面寞宫，解碼時(shí)只需要本幀數(shù)據(jù)就可以完成（因?yàn)榘暾嬅妫?/p>
P幀 :(差別幀)保留這一幀跟之前幀的差別，解碼時(shí)需要用之前緩存的畫面疊加上本幀定義的差別拉鹃，生成最終畫面辈赋。（P幀沒有完整畫面數(shù)據(jù)，只有與前一幀的畫面差別的數(shù)據(jù)）
B幀: (雙向差別幀)保留的是本幀與前后幀的差別膏燕，解碼B幀钥屈，不僅要取得之前的緩存畫面，還要解碼之后的畫面坝辫，通過(guò)前后畫面的與本幀數(shù)據(jù)的疊加取得最終的畫面篷就。B幀壓縮率高，但是解碼時(shí)CPU會(huì)比較累
幀內(nèi)（Intraframe）壓縮: 當(dāng)壓縮一幀圖像時(shí)近忙，僅考慮本幀的數(shù)據(jù)而不考慮相鄰幀之間的冗余信息,幀內(nèi)一般采用有損壓縮算法
幀間（Interframe）壓縮: 時(shí)間壓縮（Temporal compression）竭业，它通過(guò)比較時(shí)間軸上不同幀之間的數(shù)據(jù)進(jìn)行壓縮。幀間壓縮一般是無(wú)損的
muxing（合成）：將視頻流及舍、音頻流甚至是字幕流封裝到一個(gè)文件中(容器格式（FLV未辆，TS）)，作為一個(gè)信號(hào)進(jìn)行傳輸击纬。
***** 3.3 音頻編碼技術(shù) *****
AAC鼎姐，mp3：這些屬于音頻編碼技術(shù),壓縮音頻用
***** 3.4碼率控制 *****
多碼率:觀眾所處的網(wǎng)絡(luò)情況是非常復(fù)雜的，有可能是WiFi，有可能4G炕桨、3G饭尝、甚至2G，那么怎么滿足多方需求呢献宫？多搞幾條線路钥平，根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境自定義碼率。列如：常虫⑼荆看見視頻播放軟件中的1024涉瘾，720，高清捷兰，標(biāo)清立叛，流暢等，指的就是各種碼率贡茅。
***** 3.5 視頻封裝格式 *****
TS: 一種流媒體封裝格式秘蛇，流媒體封裝有一個(gè)好處，就是不需要加載索引再播放顶考，大大減少了首次載入的延遲赁还，如果片子比較長(zhǎng)，mp4文件的索引相當(dāng)大驹沿，影響用戶體驗(yàn)
為什么要用TS: 這是因?yàn)閮蓚€(gè)TS片段可以無(wú)縫拼接艘策，播放器能連續(xù)播放
FLV: 一種流媒體封裝格式,由于它形成的文件極小、加載速度極快渊季，使得網(wǎng)絡(luò)觀看視頻文件成為可能,因此FLV格式成為了當(dāng)今主流視頻格式
4.推流
***** 4.1 數(shù)據(jù)傳輸框架 *****
librtmp: 用來(lái)傳輸RTMP協(xié)議格式的數(shù)據(jù)
***** 4.2 流媒體數(shù)據(jù)傳輸協(xié)議 *****
RTMP: 實(shí)時(shí)消息傳輸協(xié)議,Adobe Systems公司為Flash播放器和服務(wù)器之間音頻朋蔫、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議，因?yàn)槭情_放協(xié)議所以都可以使用了梭域。
RTMP協(xié)議用于對(duì)象斑举、視頻、音頻的傳輸病涨，這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上富玷。
RTMP協(xié)議就像一個(gè)用來(lái)裝數(shù)據(jù)包的容器，這些數(shù)據(jù)可以是FLV中的視音頻數(shù)據(jù)既穆。一個(gè)單一的連接可以通過(guò)不同的通道傳輸多路網(wǎng)絡(luò)流赎懦，這些通道中的包都是按照固定大小的包傳輸?shù)?/p>
5.流媒體服務(wù)器
***** 5.1常用服務(wù)器 *****
SRS：一款國(guó)人開發(fā)的優(yōu)秀開源流媒體服務(wù)器系統(tǒng)
BMS: 也是一款流媒體服務(wù)器系統(tǒng)，但不開源幻工，是SRS的商業(yè)版励两，比SRS功能更多
nginx: 免費(fèi)開源web服務(wù)器，常用來(lái)配置流媒體服務(wù)器囊颅。
***** 5.2數(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)于一個(gè)中介。
CDN工作原理：比如請(qǐng)求流媒體數(shù)據(jù)1.上傳流媒體數(shù)據(jù)到服務(wù)器（源站）
2.源站存儲(chǔ)流媒體數(shù)據(jù)
3.客戶端播放流媒體饼疙，向CDN請(qǐng)求編碼后的流媒體數(shù)據(jù)
4.CDN的服務(wù)器響應(yīng)請(qǐng)求溺森，若節(jié)點(diǎn)上沒有該流媒體數(shù)據(jù)存在，則向源站繼續(xù)請(qǐng)求流媒體數(shù)據(jù)窑眯；若節(jié)點(diǎn)上已經(jīng)緩存了該視頻文件屏积，則跳到第6步。
5.源站響應(yīng)CDN的請(qǐng)求磅甩，將流媒體分發(fā)到相應(yīng)的CDN節(jié)點(diǎn)上
6.CDN將流媒體數(shù)據(jù)發(fā)送到客戶端
回源：當(dāng)有用戶訪問某一個(gè)URL的時(shí)候炊林，如果被解析到的那個(gè)CDN節(jié)點(diǎn)沒有緩存響應(yīng)的內(nèi)容，或者是緩存已經(jīng)到期更胖，就會(huì)回源站去獲取搜索铛铁。如果沒有人訪問隔显，那么CDN節(jié)點(diǎn)不會(huì)主動(dòng)去源站拿.
帶寬: 在固定的時(shí)間可傳輸?shù)臄?shù)據(jù)總量却妨，比如64位、800MHz的前端總線括眠，它的數(shù)據(jù)傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s
負(fù)載均衡: 由多臺(tái)服務(wù)器以對(duì)稱的方式組成一個(gè)服務(wù)器集合彪标，每臺(tái)服務(wù)器都具有等價(jià)的地位，都可以單獨(dú)對(duì)外提供服務(wù)而無(wú)須其他服務(wù)器的輔助.通過(guò)某種負(fù)載分擔(dān)技術(shù)掷豺，將外部發(fā)送來(lái)的請(qǐng)求均勻分配到對(duì)稱結(jié)構(gòu)中的某一臺(tái)服務(wù)器上捞烟，而接收到請(qǐng)求的服務(wù)器獨(dú)立地回應(yīng)客戶的請(qǐng)求。
均衡負(fù)載能夠平均分配客戶請(qǐng)求到服務(wù)器列陣当船，籍此提供快速獲取重要數(shù)據(jù)题画，解決大量并發(fā)訪問服務(wù)問題。
這種群集技術(shù)可以用最少的投資獲得接近于大型主機(jī)的性能德频。
QoS（帶寬管理）:限制每一個(gè)組群的帶寬苍息，讓有限的帶寬發(fā)揮最大的效用
6.拉流
直播協(xié)議選擇：即時(shí)性要求較高或有互動(dòng)需求的可以采用RTMP,RTSP
對(duì)于有回放或跨平臺(tái)需求的，推薦使用HLS
直播協(xié)議對(duì)比:
HLS: 由Apple公司定義的用于實(shí)時(shí)流傳輸?shù)膮f(xié)議,HLS基于HTTP協(xié)議實(shí)現(xiàn)壹置，傳輸內(nèi)容包括兩部分竞思，一是M3U8描述文件，二是TS媒體文件钞护「桥纾可實(shí)現(xiàn)流媒體的直播和點(diǎn)播，主要應(yīng)用在iOS系統(tǒng)HLS是以點(diǎn)播的技術(shù)方式
來(lái)實(shí)現(xiàn)直播
HLS是自適應(yīng)碼率流播难咕，客戶端會(huì)根據(jù)網(wǎng)絡(luò)狀況自動(dòng)選擇不同碼率的視頻流课梳，條件允許的情況下使用高碼率距辆，網(wǎng)絡(luò)繁忙的時(shí)候使用低碼率，并且自動(dòng)在二者間隨意切換暮刃。這對(duì)移動(dòng)設(shè)備網(wǎng)絡(luò)狀況不穩(wěn)定的情況下保障流暢播放非常有幫助挑格。
實(shí)現(xiàn)方法是服務(wù)器端提供多碼率視頻流，并且在列表文件中注明沾歪，播放器根據(jù)播放進(jìn)度和下載速度自動(dòng)調(diào)整漂彤。
HLS與RTMP對(duì)比: HLS主要是延時(shí)比較大，RTMP主要優(yōu)勢(shì)在于延時(shí)低HLS協(xié)議的小切片方式會(huì)生成大量的文件灾搏，存儲(chǔ)或處理這些文件會(huì)造成大量資源浪費(fèi)
相比使用RTSP協(xié)議的好處在于挫望，一旦切分完成，之后的分發(fā)過(guò)程完全不需要額外使用任何專門軟件狂窑，普通的網(wǎng)絡(luò)服務(wù)器即可媳板，大大降低了CDN邊緣服務(wù)器的配置要求，可以使用任何現(xiàn)成的CDN,而一般服務(wù)器很少支持RTSP泉哈。
HTTP-FLV: 基于HTTP協(xié)議流式的傳輸媒體內(nèi)容蛉幸。相對(duì)于RTMP，HTTP更簡(jiǎn)單和廣為人知丛晦，內(nèi)容延遲同樣可以做到1~3秒奕纫，打開速度更快，因?yàn)镠TTP本身沒有復(fù)雜的狀態(tài)交互烫沙。所以從延遲角度來(lái)看匹层，HTTP-FLV要優(yōu)于RTMP。
RTSP:實(shí)時(shí)流傳輸協(xié)議,定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù).
RTP: 實(shí)時(shí)傳輸協(xié)議,RTP是建立在UDP協(xié)議上的锌蓄，常與RTCP一起使用升筏，其本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過(guò)程瘸爽。
RTCP: RTP的配套協(xié)議,主要功能是為RTP所提供的服務(wù)質(zhì)量（QoS）提供反饋您访，收集相關(guān)媒體連接的統(tǒng)計(jì)信息，例如傳輸字節(jié)數(shù)剪决，傳輸分組數(shù)灵汪，丟失分組數(shù)，單向和雙向網(wǎng)絡(luò)延遲等等昼捍。
7.解碼
***** 7.1 解封裝 *****
demuxing（分離）
：從視頻流识虚、音頻流，字幕流合成的文件(容器格式（FLV妒茬，TS）
)中担锤， 分解出視頻、音頻或字幕乍钻，各自進(jìn)行解碼肛循。
***** 7.2 音頻編碼框架 *****
fdk_aac:音頻編碼解碼框架铭腕，PCM音頻數(shù)據(jù)和AAC音頻數(shù)據(jù)互轉(zhuǎn)
***** 7.3 解碼介紹 *****
硬解碼：用GPU來(lái)解碼，減少CPU運(yùn)算 優(yōu)點(diǎn)：播放流暢多糠、低功耗累舷，解碼速度快， * 缺點(diǎn)：兼容不好
軟解碼：用CPU來(lái)解碼優(yōu)點(diǎn)：兼容好 * 缺點(diǎn)：加大CPU負(fù)擔(dān)夹孔，耗電增加被盈、沒有硬解碼流暢，解碼速度相對(duì)慢
8.播放
ijkplayer:一個(gè)基于FFmpeg的開源Android/iOS視頻播放器API易于集成搭伤；
編譯配置可裁剪只怎，方便控制安裝包大小怜俐；
支持硬件加速解碼身堡，更加省電
簡(jiǎn)單易用，指定拉流URL拍鲤，自動(dòng)解碼播放.
9.聊天互動(dòng)
IM:(InstantMessaging)即時(shí)通訊:是一個(gè)實(shí)時(shí)通信系統(tǒng)贴谎，允許兩人或多人使用網(wǎng)絡(luò)實(shí)時(shí)的傳遞文字消息、文件季稳、語(yǔ)音與視頻交流.IM
在直播系統(tǒng)中的主要作用是實(shí)現(xiàn)觀眾與主播擅这、觀眾與觀眾之間的文字互動(dòng).
七牛云直播流程
開篇，將從整體介紹直播中的各個(gè)環(huán)節(jié)绞幌。
1.采集
采集是播放環(huán)節(jié)中的第一環(huán)蕾哟，iOS 系統(tǒng)因?yàn)檐浻布N類不多，硬件適配性較好莲蜘，所以比較簡(jiǎn)單。Android 則不同帘营，市面上硬件機(jī)型非常多票渠，難以做到一個(gè)庫(kù)適配所有硬件。PC 端的采集也跟各種攝像頭驅(qū)動(dòng)有關(guān)芬迄，推薦使用目前市面上最好用的 PC 端開源免費(fèi)軟件 OBS问顷。
- 音頻采集
音頻數(shù)據(jù)既能與圖像結(jié)合組合成視頻數(shù)據(jù)，也能以純音頻的方式采集播放禀梳，后者在很多成熟的應(yīng)用場(chǎng)景如在線電臺(tái)和語(yǔ)音電臺(tái)等起著非常重要的作用杜窄。音頻的采集過(guò)程主要通過(guò)設(shè)備將環(huán)境中的模擬信號(hào)采集成 PCM 編碼的原始數(shù)據(jù)，然后編碼壓縮成 MP3 等格式的數(shù)據(jù)分發(fā)出去算途。常見的音頻壓縮格式有：MP3塞耕，AAC，OGG嘴瓤，WMA扫外，Opus莉钙，F(xiàn)LAC，APE筛谚，m4a 和 AMR 等磁玉。
音頻采集和編碼主要面臨的挑戰(zhàn)在于：延時(shí)敏感、卡頓敏感驾讲、噪聲消除（Denoise）蚊伞、回聲消除（AEC）、靜音檢測(cè)（VAD）和各種混音算法等吮铭。
在音頻采集階段厚柳，參考的主要技術(shù)參數(shù)有 ：
采樣率（samplerate）：采樣就是把模擬信號(hào)數(shù)字化的過(guò)程，采樣頻率越高沐兵，記錄這一段音頻信號(hào)所用的數(shù)據(jù)量就越大别垮，同時(shí)音頻質(zhì)量也就越高。
位寬：每一個(gè)采樣點(diǎn)都需要用一個(gè)數(shù)值來(lái)表示大小扎谎，這個(gè)數(shù)值的數(shù)據(jù)類型大小可以是：4bit碳想、8bit、16bit毁靶、32bit 等等胧奔，位數(shù)越多，表示得就越精細(xì)预吆，聲音質(zhì)量自然就越好龙填，而數(shù)據(jù)量也會(huì)成倍增大。我們?cè)谝纛l采樣過(guò)程中常用的位寬是 8bit 或者 16bit拐叉。
聲道數(shù)（channels）：由于音頻的采集和播放是可以疊加的岩遗，因此，可以同時(shí)從多個(gè)音頻源采集聲音凤瘦，并分別輸出到不同的揚(yáng)聲器宿礁，故聲道數(shù)一般表示聲音錄制時(shí)的音源數(shù)量或回放時(shí)相應(yīng)的揚(yáng)聲器數(shù)量。聲道數(shù)為 1 和 2 分別稱為單聲道和雙聲道蔬芥，是比較常見的聲道參數(shù)梆靖。
音頻幀（frame）：音頻跟視頻很不一樣，視頻每一幀就是一張圖像笔诵，而從上面的正玄波可以看出返吻，音頻數(shù)據(jù)是流式的，本身沒有明確的一幀幀的概念乎婿，在實(shí)際的應(yīng)用中测僵，為了音頻算法處理/傳輸?shù)姆奖悖话慵s定俗成取 2.5ms~60ms 為單位的數(shù)據(jù)量為一幀音頻次酌。這個(gè)時(shí)間被稱之為“采樣時(shí)間”恨课，其長(zhǎng)度沒有特別的標(biāo)準(zhǔn)舆乔，它是根據(jù)編解碼器和具體應(yīng)用的需求來(lái)決定的。
根據(jù)以上定義剂公，我們可以計(jì)算一下一幀音頻幀的大小希俩。假設(shè)某音頻信號(hào)是采樣率為 8kHz、雙通道纲辽、位寬為 16bit颜武，20ms 一幀，則一幀音頻數(shù)據(jù)的大小為：
size = 8000 x 2 x 16bit x 0.02s = 5120 bit = 640 byte
- ** 圖像采集**
圖像采集的圖片結(jié)果組合成一組連續(xù)播放的動(dòng)畫拖吼，即構(gòu)成視頻中可肉眼觀看的內(nèi)容鳞上。圖像的采集過(guò)程主要由攝像頭等設(shè)備拍攝成 YUV 編碼的原始數(shù)據(jù)，然后經(jīng)過(guò)編碼壓縮成 H.264 等格式的數(shù)據(jù)分發(fā)出去吊档。常見的視頻封裝格式有：MP4篙议、3GP、AVI怠硼、MKV鬼贱、WMV、MPG香璃、VOB这难、FLV、SWF葡秒、MOV姻乓、RMVB 和 WebM 等。
圖像由于其直觀感受最強(qiáng)并且體積也比較大眯牧，構(gòu)成了一個(gè)視頻內(nèi)容的主要部分蹋岩。圖像采集和編碼面臨的主要挑戰(zhàn)在于：設(shè)備兼容性差、延時(shí)敏感炸站、卡頓敏感以及各種對(duì)圖像的處理操作如美顏和水印等星澳。
在圖像采集階段，參考的主要技術(shù)參數(shù)有：
圖像傳輸格式：通用影像傳輸格式（Common Intermediate Format）是視訊會(huì)議（video conference）中常使用的影像傳輸格式旱易。
圖像格式：通常采用 YUV 格式存儲(chǔ)原始數(shù)據(jù)信息，其中包含用 8 位表示的黑白圖像灰度值腿堤，以及可由 RGB 三種色彩組合成的彩色圖像阀坏。
傳輸通道：正常情況下視頻的拍攝只需 1 路通道，隨著 VR 和 AR 技術(shù)的日漸成熟笆檀，為了拍攝一個(gè)完整的 360° 視頻忌堂，可能需要通過(guò)不同角度拍攝，然后經(jīng)過(guò)多通道傳輸后合成酗洒。
分辨率：隨著設(shè)備屏幕尺寸的日益增多士修，視頻采集過(guò)程中原始視頻分辨率起著越來(lái)越重要的作用枷遂，后續(xù)處理環(huán)節(jié)中使用的所有視頻分辨率的定義都以原始視頻分辨率為基礎(chǔ)。視頻采集卡能支持的最大點(diǎn)陣反映了其分辨率的性能棋嘲。
采樣頻率：采樣頻率反映了采集卡處理圖像的速度和能力酒唉。在進(jìn)行高度圖像采集時(shí)，需要注意采集卡的采樣頻率是否滿足要求沸移。采樣率越高痪伦，圖像質(zhì)量越高，同時(shí)保存這些圖像信息的數(shù)據(jù)量也越大雹锣。
以上网沾，構(gòu)成了一個(gè)視頻采集的主要技術(shù)參數(shù)，以及視頻中音頻和圖像編碼的常用格式蕊爵。而對(duì)于直播 App 開發(fā)者來(lái)說(shuō)辉哥，了解這些細(xì)節(jié)雖然更有幫助，但實(shí)際開發(fā)過(guò)程中可能很少能夠關(guān)注采集環(huán)節(jié)中技術(shù)參數(shù)的控制攒射，而是直接在 SDK 中將采集后的數(shù)據(jù)傳遞給下一個(gè)「處理」和「編碼」環(huán)節(jié)醋旦。
2.處理
視頻或者音頻完成采集之后得到原始數(shù)據(jù)，為了增強(qiáng)一些現(xiàn)場(chǎng)效果或者加上一些額外的效果匆篓，我們一般會(huì)在將其編碼壓縮前進(jìn)行處理浑度，比如打上時(shí)間戳或者公司 Logo 的水印，祛斑美顏和聲音混淆等處理。在主播和觀眾連麥場(chǎng)景中，主播需要和某個(gè)或者多個(gè)觀眾進(jìn)行對(duì)話放可，并將對(duì)話結(jié)果實(shí)時(shí)分享給其他所有觀眾荠察，連麥的處理也有部分工作在推流端完成。
開放式設(shè)計(jì)
如上圖所示时肿，處理環(huán)節(jié)中分為音頻和視頻處理，音頻處理中具體包含混音、降噪和聲音特效等處理论熙，視頻處理中包含美顏、水印摄狱、以及各種自定義濾鏡等處理脓诡。
「80% 的主播沒有美顏根本沒法看∶揭郏」不光是美顏祝谚，很多其它的視頻處理如模糊效果、水印等也都是在這個(gè)環(huán)節(jié)做酣衷。目前 iOS 端比較知名的是 GPUImage 這個(gè)庫(kù)交惯，提供了豐富端預(yù)處理效果，還可以基于這個(gè)庫(kù)自己寫算法實(shí)現(xiàn)更豐富端效果。Android 也有 GPUImage 這個(gè)庫(kù)的移植席爽，叫做 android-gpuimage意荤。同時(shí)，Google 官方開源了一個(gè)偉大的庫(kù)只锻，覆蓋了 Android 上面很多多媒體和圖形圖像相關(guān)的處理玖像。
美顏的主要原理是通過(guò)「磨皮+美白」來(lái)達(dá)到整體美顏的效果。磨皮的技術(shù)術(shù)語(yǔ)是「去噪」炬藤，也即對(duì)圖像中的噪點(diǎn)進(jìn)行去除或者模糊化處理御铃，常見的去噪算法有均值模糊、高斯模糊和中值濾波等沈矿。當(dāng)然上真， 由于臉部的每個(gè)部位不盡相同，臉上的雀斑可能呈現(xiàn)出眼睛黑點(diǎn)的樣子羹膳，對(duì)整張圖像進(jìn)行「去噪」處理的時(shí)候不需要將眼睛也去掉睡互，因此這個(gè)環(huán)節(jié)中也涉及到人臉和皮膚檢測(cè)技術(shù)。
3.編碼和封裝
編碼主要難點(diǎn)有兩個(gè)：1. 處理硬件兼容性問題陵像。2. 在高 fps就珠、低 bitrate 和音質(zhì)畫質(zhì)之間找到平衡。iOS 端硬件兼容性較好醒颖，可以直接采用硬編妻怎。而 Android 的硬編的支持則難得多，需要支持各種硬件機(jī)型泞歉，推薦使用軟編逼侦。
為什么封裝？
原始視頻數(shù)據(jù)存儲(chǔ)空間大腰耙，一個(gè) 1080P 的 7 s 視頻需要 817 MB
原始視頻數(shù)據(jù)傳輸占用帶寬大榛丢，10 Mbps 的帶寬傳輸上述 7 s 視頻需要 11 分鐘
而經(jīng)過(guò) H.264 編碼壓縮之后，視頻大小只有 708 k ,10 Mbps 的帶寬僅僅需要 500 ms 挺庞，可以滿足實(shí)時(shí)傳輸?shù)男枨笪蓿詮囊曨l采集傳感器采集來(lái)的原始視頻勢(shì)必要經(jīng)過(guò)視頻編碼。
基本原理
那為什么巨大的原始視頻可以編碼成很小的視頻呢选侨？這其中的技術(shù)是什么呢掖鱼？核心思想就是去除冗余信息：
空間冗余：圖像相鄰像素之間有較強(qiáng)的相關(guān)性
時(shí)間冗余：視頻序列的相鄰圖像之間內(nèi)容相似
編碼冗余：不同像素值出現(xiàn)的概率不同
視覺冗余：人的視覺系統(tǒng)對(duì)某些細(xì)節(jié)不敏感
知識(shí)冗余：規(guī)律性的結(jié)構(gòu)可由先驗(yàn)知識(shí)和背景知識(shí)得到
詳細(xì)介紹：七牛的編碼和封裝原理
4.推流和傳輸
傳輸涉及到很多端：從主播端到服務(wù)端，從收流服務(wù)端到邊緣節(jié)點(diǎn)援制，以及再?gòu)倪吘壒?jié)點(diǎn)到觀眾端锨用。
推流端和分發(fā)端理論上需要支持的并發(fā)用戶數(shù)應(yīng)該都是億級(jí)的，不過(guò)畢竟產(chǎn)生內(nèi)容的推流端在少數(shù)隘谣，和消費(fèi)內(nèi)容端播放端不是一個(gè)量級(jí)，但是他們對(duì)推流穩(wěn)定性和速度的要求比播放端高很多，這涉及到所有播放端能否看到直播寻歧，以及直播端質(zhì)量如何掌栅。
詳情介紹: 推流和傳輸
5.轉(zhuǎn)碼
為了讓主播推上來(lái)的流適配各個(gè)平臺(tái)端各種不同協(xié)議，需要在服務(wù)端做一些流處理工作码泛，比如轉(zhuǎn)碼成不同格式支持不同協(xié)議如 RTMP猾封、HLS 和 FLV，一路轉(zhuǎn)多路流來(lái)適配各種不同的網(wǎng)絡(luò)狀況和不同分辨率的終端設(shè)備噪珊。
6.解碼和渲染
解碼和渲染晌缘，也即音視頻的播放，目前 iOS 端的播放兼容性較好痢站，在延遲可接受的情況下使用 HLS 協(xié)議是最好的選擇磷箕，我們也提供了能夠播放 RTMP 和 HLS 的播放器 SDK。Android 的硬件解碼和編碼一樣也存在兼容性問題阵难，目前比較好的開源播放器是基于 ffplay 的 ijkplayer岳枷，
gitHub代碼地址
Object-C版 : https://github.com/one-tea/ZKKLiveDemo
Swift版 : https://github.com/one-tea/ZKKLiveAPP_Swift3.0
總結(jié) ：到此介紹了直播大致功能模塊 ，底層技術(shù)不懂也沒關(guān)系呜叫，在接下來(lái)的【采集篇】空繁、【服務(wù)器搭建+推流篇】、【播放篇】中教你如何運(yùn)用這些封裝好的庫(kù)來(lái)創(chuàng)建自己的直播朱庆！
當(dāng)然一個(gè)直播還有許多功能： ** 禮物盛泡、IM聊天、 彈幕 娱颊、連麥**等后續(xù)整理出來(lái),待完善傲诵，喜歡的朋友可以關(guān)注！
