一辜纲、直播難與易
`直播難`：個(gè)人認(rèn)為要想把直播從零開始做出來螃征，絕對(duì)是牛逼中的牛逼犬庇，大牛中的大牛，因?yàn)橹辈ブ羞\(yùn)用到的技術(shù)難點(diǎn)非常之多，
視頻/音頻處理逻澳，圖形處理垒在， 視頻/音頻壓縮蒜魄，CDN分發(fā)，即時(shí)通訊等技術(shù)场躯，每一個(gè)技術(shù)都?jí)蚰銓W(xué)幾年的谈为。
`直播易`：已經(jīng)有各個(gè)領(lǐng)域的大牛，封裝好了許多牛逼的框架踢关，我們只需要用別人寫好的框架伞鲫，
就能快速的搭建一個(gè)直播app，也就是傳說中的站在大牛肩膀上編程签舞。
二秕脓、直播相關(guān)概述
1.一個(gè)完整直播app功能
1、`聊天`
私聊儒搭、聊天室吠架、點(diǎn)亮、推送师妙、黑名單等;
2诵肛、`禮物`
普通禮物、豪華禮物、紅包怔檩、排行榜褪秀、第三方充值、內(nèi)購(gòu)薛训、禮物動(dòng)態(tài)更新媒吗、提現(xiàn)等；
3乙埃、`直播列表`
關(guān)注闸英、熱門、最新介袜、分類直播用戶列表等甫何；
4、`自己直播`
錄制遇伞、推流辙喂、解碼、播放鸠珠、美顏巍耗、心跳、后臺(tái)切換渐排、主播對(duì)管理員操作炬太、管理員對(duì)用戶等；
5驯耻、`房間邏輯`
創(chuàng)建房間亲族、進(jìn)入房間、退出房間吓歇、關(guān)閉房間孽水、切換房間票腰、房間管理員設(shè)置城看、房間用戶列表等；
6杏慰、`用戶邏輯`
普通登陸测柠、第三方登陸、注冊(cè)缘滥、搜索轰胁、修改個(gè)人信息、關(guān)注列表朝扼、粉絲列表赃阀、忘記密碼、查看個(gè)人信息擎颖、收入榜榛斯、關(guān)注和取關(guān)观游、檢索等；
7驮俗、`觀看直播`
聊天信息懂缕、滾屏彈幕、禮物顯示王凑、加載界面等搪柑；
8、`統(tǒng)計(jì)`
APP業(yè)務(wù)統(tǒng)計(jì)索烹、第三方統(tǒng)計(jì)等工碾；
9、`超管`
禁播百姓、隱藏倚喂、審核等；
2.一個(gè)完整直播app原理
`直播原理`：把主播錄制的視頻瓣戚，推送到服務(wù)器端圈，在由服務(wù)器分發(fā)給觀眾觀看。
`直播環(huán)節(jié)`：推流端（采集子库、美顏處理舱权、編碼、推流）仑嗅、
服務(wù)端處理（轉(zhuǎn)碼宴倍、錄制、截圖仓技、鑒黃）鸵贬、
播放器（拉流、解碼脖捻、渲染）阔逼、
互動(dòng)系統(tǒng)（聊天室、禮物系統(tǒng)地沮、贊）
3.一個(gè)完整直播app實(shí)現(xiàn)流程
`1.采集嗜浮、2.濾鏡處理、3.編碼摩疑、4.推流危融、5.CDN分發(fā)、6.拉流雷袋、7.解碼吉殃、8.播放、9.聊天互動(dòng)`
4.一個(gè)完整直播app架構(gòu)
5.一個(gè)完整直播app技術(shù)點(diǎn)
三、了解流媒體（直播需要用到流媒體）
`流媒體開發(fā)`: 網(wǎng)絡(luò)層(socket或st)負(fù)責(zé)傳輸蛋勺，協(xié)議層(rtmp或hls)負(fù)責(zé)網(wǎng)絡(luò)打包速侈，封裝層(flv、ts)負(fù)責(zé)編解碼數(shù)據(jù)的封裝迫卢，
編碼層(h.264和aac)負(fù)責(zé)圖像倚搬，音頻壓縮。
`幀`: 每幀代表一幅靜止的圖像
`GOP`:（Group of Pictures）畫面組乾蛤，一個(gè)GOP就是一組連續(xù)的畫面每界，每個(gè)畫面都是一幀，一個(gè)GOP就是很多幀的集合;
直播的數(shù)據(jù)家卖，其實(shí)是一組圖片眨层，包括I幀、P幀上荡、B幀趴樱，當(dāng)用戶第一次觀看的時(shí)候，會(huì)尋找I幀酪捡，
而播放器會(huì)到服務(wù)器尋找到最近的I幀反饋給用戶叁征。因此，GOP Cache增加了端到端延遲逛薇，因?yàn)樗仨氁玫阶罱腎幀
GOP Cache的長(zhǎng)度越長(zhǎng)捺疼，畫面質(zhì)量越好
`碼率`：圖片進(jìn)行壓縮后每秒顯示的數(shù)據(jù)量。
`幀率`：每秒顯示的圖片數(shù)永罚。影響畫面流暢度啤呼，與畫面流暢度成正比：幀率越大，畫面越流暢呢袱；幀率越小官扣，畫面越有跳動(dòng)感。
由于人類眼睛的特殊生理結(jié)構(gòu)羞福，如果所看畫面之幀率高于16的時(shí)候惕蹄，就會(huì)認(rèn)為是連貫的，此現(xiàn)象稱之為視覺暫留坯临。
并且當(dāng)幀速達(dá)到一定數(shù)值后焊唬，再增長(zhǎng)的話，人眼也不容易察覺到有明顯的流暢度提升了看靠。
`分辨率`：(矩形)圖片的長(zhǎng)度和寬度，即圖片的尺寸
`壓縮前的每秒數(shù)據(jù)量`: 幀率X分辨率(單位應(yīng)該是若干個(gè)字節(jié))
`壓縮比`: 壓縮前的每秒數(shù)據(jù)量/碼率 （對(duì)于同一個(gè)視頻源并采用同一種視頻編碼算法液肌，則：壓縮比越高挟炬，畫面質(zhì)量越差利术。）
`視頻文件格式`：文件的后綴，比如.wmv,.mov,.mp4,.mp3,.avi,
主要用處招狸，根據(jù)文件格式甜孤，系統(tǒng)會(huì)自動(dòng)判斷用什么軟件打開,
注意: 隨意修改文件格式，對(duì)文件的本身不會(huì)造成太大的影響粥喜，比如把a(bǔ)vi改成mp4,文件還是avi.
`視頻封裝格式`： 一種儲(chǔ)存視頻信息的容器凸主，流式封裝可以有TS、FLV等额湘，索引式的封裝有MP4,MOV,AVI等卿吐，
主要作用：一個(gè)視頻文件往往會(huì)包含圖像和音頻，還有一些配置信息(如圖像和音頻的關(guān)聯(lián)锋华，如何解碼它們等)：
這些內(nèi)容需要按照一定的規(guī)則組織嗡官、封裝起來.
注意：會(huì)發(fā)現(xiàn)封裝格式跟文件格式一樣，因?yàn)橐话阋曨l文件格式的后綴名即采用相應(yīng)的視頻封裝格式的名稱,
所以視頻文件格式就是視頻封裝格式毯焕。
`視頻封裝格式和視頻壓縮編碼標(biāo)準(zhǔn)`： 就好像項(xiàng)目工程和編程語言衍腥，封裝格式就是一個(gè)項(xiàng)目的工程，視頻編碼方式就是編程語言纳猫，
一個(gè)項(xiàng)目工程可以用不同語言開發(fā)婆咸。
四、直播基礎(chǔ)知識(shí)介紹：
1.采集視頻芜辕、音頻
***** 1.1 采集視頻擅耽、音頻編碼框架 *****
`AVFoundation`: AVFoundation是用來播放和創(chuàng)建實(shí)時(shí)的視聽媒體數(shù)據(jù)的框架，
同時(shí)提供Objective-C接口來操作這些視聽數(shù)據(jù)物遇，比如編輯乖仇，旋轉(zhuǎn)，重編碼
***** 1.2 視頻询兴、音頻硬件設(shè)備 *****
`CCD`: 圖像傳感器： 用于圖像采集和處理的過程乃沙，把圖像轉(zhuǎn)換成電信號(hào)。
`拾音器`: 聲音傳感器： 用于聲音采集和處理的過程诗舰，把聲音轉(zhuǎn)換成電信號(hào)警儒。
`音頻采樣數(shù)據(jù)`: 一般都是PCM格式
`視頻采樣數(shù)據(jù)`: 一般都是YUV,或RGB格式，采集到的原始音視頻的體積是非常大的眶根，需要經(jīng)過壓縮技術(shù)處理來提高傳輸效率
2.視頻處理（美顏蜀铲，水印）
`視頻處理原理`: 因?yàn)橐曨l最終也是通過GPU属百，一幀一幀渲染到屏幕上的记劝，所以我們可以利用OpenGL ES，對(duì)視頻幀進(jìn)行各種加工族扰，
從而視頻各種不同的效果厌丑，`就好像一個(gè)水龍頭流出的水定欧，經(jīng)過若干節(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è)跨編程語言、跨平臺(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)過壓縮編碼的話，
體積通常是非常大的微驶，一部電影可能就要上百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)帶來了很多好處阻课，
但是不同產(chǎn)品之間互通成了很大的問題叫挟，造成了通過A公司的編碼器編出的數(shù)據(jù)，必須通過A公司的解碼器去解這樣尷尬的事情
`H.265/HEVC`: 一種視頻壓縮方式,基于H.264限煞，保留原來的某些技術(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幀`:(差別幀)保留這一幀跟之前幀的差別窃这，解碼時(shí)需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面征候。
（P幀沒有完整畫面數(shù)據(jù)杭攻，只有與前一幀的畫面差別的數(shù)據(jù)）
`B幀`:(雙向差別幀)保留的是本幀與前后幀的差別，解碼B幀疤坝，不僅要取得之前的緩存畫面兆解，還要解碼之后的畫面，
通過前后畫面的與本幀數(shù)據(jù)的疊加取得最終的畫面卒煞。B幀壓縮率高痪宰，但是解碼時(shí)CPU會(huì)比較累
`幀內(nèi)（Intraframe）壓縮`:當(dāng)壓縮一幀圖像時(shí)，僅考慮本幀的數(shù)據(jù)而不考慮相鄰幀之間的冗余信息,幀內(nèi)一般采用有損壓縮算法
`幀間（Interframe）壓縮`:時(shí)間壓縮（Temporal compression）畔裕，它通過比較時(shí)間軸上不同幀之間的數(shù)據(jù)進(jìn)行壓縮衣撬。
幀間壓縮一般是無損的
`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片段可以無縫拼接攀芯，播放器能連續(xù)播放
`FLV`: 一種流媒體封裝格式,由于它形成的文件極小屯断、加載速度極快，使得網(wǎng)絡(luò)觀看視頻文件成為可能,
因此FLV格式成為了當(dāng)今主流視頻格式
4.推流
***** 4.1 數(shù)據(jù)傳輸框架 *****
`librtmp`:用來傳輸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è)用來裝數(shù)據(jù)包的容器彼棍，這些數(shù)據(jù)可以是FLV中的視音頻數(shù)據(jù)。一個(gè)單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流膳算，
這些通道中的包都是按照固定大小的包傳輸?shù)?
`chunk`:消息包
`推流的過程：`
建立tcp連接
建立rtmp連接,以及發(fā)送各種控制指令
獲取原始視頻數(shù)據(jù)和音頻數(shù)據(jù)
對(duì)原始視頻數(shù)據(jù)和音頻數(shù)據(jù)進(jìn)行壓縮編碼
（實(shí)現(xiàn)音視頻數(shù)據(jù)的編碼座硕，視頻編碼成h264，音頻編碼成aac）
對(duì)編碼后的視頻數(shù)據(jù)和音頻數(shù)據(jù)進(jìn)行打包
發(fā)送打包后的音頻和視頻數(shù)據(jù)
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ù)器机隙，常用來配置流媒體服務(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ù)器的輔助.
通過某種負(fù)載分擔(dān)技術(shù)湃交，將外部發(fā)送來的請(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ù)方式`來實(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ā)過程完全不需要額外使用任何專門軟件眠冈，普通的網(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)交互崔挖。
所以從延遲角度來看，HTTP-FLV要優(yōu)于RTMP娃闲。
`RTSP`:實(shí)時(shí)流傳輸協(xié)議,定義了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù).
`RTP`:實(shí)時(shí)傳輸協(xié)議,RTP是建立在UDP協(xié)議上的虚汛，常與RTCP一起使用，其本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證皇帮，
它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程卷哩。
`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來解碼，減少CPU運(yùn)算
優(yōu)點(diǎn)：播放流暢菇用、低功耗澜驮，解碼速度快，
缺點(diǎn)：兼容不好
`軟解碼`：用CPU來解碼
優(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í)的傳遞文字消息樟凄、文件、語音與視頻交流.
`IM`在直播系統(tǒng)中的主要作用是實(shí)現(xiàn)觀眾與主播兄渺、觀眾與觀眾之間的文字互動(dòng).
***** 第三方SDK *****
五挂谍、如何快速的開發(fā)一個(gè)完整的iOS直播app
1叔壤、利用第三方直播SDK快速的開發(fā)
七牛云:
七牛直播云是專為直播平臺(tái)打造的全球化直播流服務(wù)和一站式實(shí)現(xiàn)SDK端到端直播場(chǎng)景的企業(yè)級(jí)直播云服務(wù)平臺(tái).
熊貓TV,龍珠TV等直播平臺(tái)都是用的七牛云
基于專業(yè)的跨平臺(tái)視頻編解碼技術(shù)和大規(guī)模視頻內(nèi)容分發(fā)網(wǎng)絡(luò)，提供穩(wěn)定流暢口叙、低延時(shí)炼绘、高并發(fā)的實(shí)時(shí)音視頻服務(wù)，
可將視頻直播無縫對(duì)接到自身App.
2妄田、自研還是使用第三方直播SDK開發(fā)俺亮？
第三方SDK開發(fā): 對(duì)于一個(gè)初創(chuàng)團(tuán)隊(duì)來講，自研直播不管在技術(shù)門檻疟呐、CDN脚曾、帶寬上都是有很大的門檻的，
而且需要耗費(fèi)大量的時(shí)間才能做出成品启具，不利于拉投資本讥。
自研： 公司直播平臺(tái)大，從長(zhǎng)遠(yuǎn)看，自研可以節(jié)省成本拷沸，技術(shù)成面比直接用SDK可控多了旨椒。
3.簡(jiǎn)易搭建
推流：LFLiveKit
服務(wù)器:nginx+rtmp+ffmpeg
拉流播放：ijkplayer
