關(guān)于直播拷窜，所有的技術(shù)細(xì)節(jié)都在這里了（一）
2016年5月10日
網(wǎng)絡(luò)視頻直播存在已有很長一段時(shí)間俭茧，隨著移動(dòng)上下行帶寬提升及資費(fèi)的下調(diào)咆疗，視頻直播被賦予了更多娛樂和社交的屬性，人們享受隨時(shí)隨地進(jìn)行直播和觀看母债，主播不滿足于單向的直播午磁，觀眾則更渴望互動(dòng)，直播的打開時(shí)間和延遲變成了影響產(chǎn)品功能發(fā)展重要指標(biāo)毡们。那么迅皇，問題來了：如何實(shí)現(xiàn)低延遲、秒開的直播衙熔？
先來看看視頻直播的5個(gè)關(guān)鍵的流程：錄制->編碼->網(wǎng)絡(luò)傳輸->解碼->播放喧半，每個(gè)環(huán)節(jié)對(duì)于直播的延遲都會(huì)產(chǎn)生不同程度的影響。這里重點(diǎn)分析移動(dòng)設(shè)備的情況青责。受限于技術(shù)的成熟度挺据、硬件環(huán)境等，我們針對(duì)移動(dòng)場景簡單總結(jié)出直播延遲優(yōu)化的4個(gè)點(diǎn)：網(wǎng)絡(luò)脖隶、協(xié)議扁耐、編解碼、移動(dòng)終端产阱，并將分四期來一一解密UCloud直播云實(shí)現(xiàn)低延遲婉称、秒開的技術(shù)細(xì)節(jié)。
本文主要講述UCloud直播云實(shí)現(xiàn)接入網(wǎng)絡(luò)優(yōu)化的技術(shù)細(xì)節(jié)构蹬。
1）全局負(fù)載均衡-就近接入
實(shí)現(xiàn)就近接入的技術(shù)比較廣為人知王暗，就是CDN即Content Delivery Network （內(nèi)容分發(fā)網(wǎng)絡(luò)）。CDN包含兩大核心技術(shù)：負(fù)載均衡和分發(fā)網(wǎng)絡(luò)庄敛，隨著10多年的演進(jìn)俗壹，對(duì)負(fù)載均衡和分發(fā)的實(shí)現(xiàn)方式已多種多樣，分發(fā)網(wǎng)絡(luò)的構(gòu)建策略通常是經(jīng)過日積月累的總結(jié)出一套最合適的分發(fā)路由藻烤，并且也不是一成不變绷雏，需時(shí)刻關(guān)注調(diào)整，動(dòng)態(tài)運(yùn)營怖亭。這里重點(diǎn)介紹下CDN的負(fù)載均衡技術(shù)涎显。
負(fù)載均衡是如何實(shí)現(xiàn)讓用戶就進(jìn)訪問的呢？比較普遍的實(shí)現(xiàn)方式：通過用戶使用的DNS服務(wù)器來判斷客戶端所在的網(wǎng)絡(luò)位置兴猩，從而返回對(duì)應(yīng)的服務(wù)IP期吓。如下圖示例:
廣東電信用戶IP:1.1.1.1 需要看一個(gè)直播http://www.ucloud.cn/helloworld.flv，實(shí)現(xiàn)就近訪問的過程是：
1>用戶向配置的DNS服務(wù)器1.1.1.0(通常是運(yùn)營商指定倾芝，也稱local DNS讨勤，后面簡稱Ldns)發(fā)起www.ucloud.cn的查詢；
2> Ldns 上沒有該域名的記錄蛀醉，則往頂級(jí)即Root NS上發(fā)起查詢悬襟；
3>Root NS返回告知Ldns該域名的權(quán)威解析記錄在UCloud NS上；
4>Ldns 向UCloud NS發(fā)起查詢拯刁；
5>UCloud NS 向UCloud GSLB服務(wù)發(fā)起查詢脊岳，GSLB發(fā)現(xiàn) Ldns1.1.1.0是屬于廣東電信；
6>返回廣東電信的就近節(jié)節(jié)點(diǎn)IP1.1.1.2垛玻；
7>返回1.1.1.2給Ldns割捅；
8>返回給用戶1.1.1.2，用戶到1.1.1.2上去獲取直播內(nèi)容帚桩。
鏈路很長亿驾，但是每個(gè)Ldns上都會(huì)對(duì)查詢過的域名做合理的緩存，下一個(gè)廣東電信的用戶再來查詢的時(shí)候就可以直接返回1.1.1.2账嚎。架構(gòu)并不復(fù)雜莫瞬，關(guān)鍵點(diǎn)是如何知道Ldns是位于廣東電信儡蔓，這就涉及一個(gè)IP地址庫。有開源地址庫疼邀，也有商業(yè)地址庫喂江，可以按需求采購即可，一般一年1萬左右旁振。這里不難看出來获询，調(diào)度的準(zhǔn)確度是完全依賴用戶配置的Ldns，而這些Ldns大多數(shù)是省級(jí)別的拐袜，即GLSB只知道用戶是廣東電信吉嚣，但是常常分不出來是廣東廣州電信，還是廣東深圳電信蹬铺。 HTTPDNS就是實(shí)現(xiàn)更精準(zhǔn)的調(diào)度一種方式：
1>用戶1.1.1.1通過HTTP協(xié)議直接向UCloud NS請(qǐng)求直播域名www.ucloud.cn尝哆；
2>UCloud NS發(fā)現(xiàn)用戶IP1.1.1.1屬于廣東深圳電信；
3>返回廣東深圳電信節(jié)點(diǎn)1.1.1.11給UCloud NS丛塌；
4>返回給用戶较解。
HTTPDNS的好處顯而易見：一可精準(zhǔn)獲得用戶端的IP，有效避免用戶配錯(cuò)Ldns（有時(shí)是網(wǎng)絡(luò)中心配錯(cuò)DNS）的情況赴邻，可更精準(zhǔn)定位用戶所在網(wǎng)絡(luò)位置印衔。二可避免DNS解析劫持。
2）BGP中轉(zhuǎn)架構(gòu)-最短傳輸路徑
BGP即Border Gateway Protocol （邊界網(wǎng)關(guān)協(xié)議）姥敛，業(yè)內(nèi)簡稱BGP奸焙。為什么BGP中轉(zhuǎn)架構(gòu)對(duì)直播加速和分發(fā)如此重要？不得不提國內(nèi)復(fù)雜的網(wǎng)絡(luò)狀況彤敛，較廣為人知的是“南電信北聯(lián)通”的寬帶用戶分布与帆。那一個(gè)簡單的問題，電信主播發(fā)起了直播墨榄，聯(lián)通的用戶想看怎么辦呢玄糟？ 從結(jié)構(gòu)上講，肯定是有有限個(gè)電信聯(lián)通兩個(gè)運(yùn)營商的交匯點(diǎn)袄秩，相當(dāng)于信息橋梁阵翎。 這就會(huì)帶來兩個(gè)問題：1、路程要繞遠(yuǎn)之剧，網(wǎng)絡(luò)延遲高且不穩(wěn)定郭卫；2、高峰期擁堵背稼，導(dǎo)致直播流卡頓贰军。
BGP的技術(shù)原理往簡單的說就是允許同一IP在不同網(wǎng)絡(luò)中廣播不同的路由信息，效果就是同一個(gè)IP蟹肘，當(dāng)電信用戶來訪問時(shí)走電信網(wǎng)內(nèi)的路由词疼，聯(lián)通用戶來訪問時(shí)走的聯(lián)通的路由俯树。所以BGP技術(shù)對(duì)跨運(yùn)營商的訪問帶來了巨大的便利，特別是直播場景贰盗。不同于傳統(tǒng)的文件緩存場景聘萨，一個(gè)圖片哪怕第一次是跨了遙遠(yuǎn)的距離從源站獲取后，本地網(wǎng)絡(luò)進(jìn)行緩存童太，后面的訪問都走本地網(wǎng)絡(luò)。直播加速是流式的胸完，并且當(dāng)要做到低延遲的時(shí)候书释，中間的緩存要盡可能少。 BGP相當(dāng)于給跨網(wǎng)的用戶就近搭建了一坐橋梁赊窥，不必繞遠(yuǎn)路爆惧，延時(shí)和穩(wěn)定性都大大提高了。
技術(shù)原理部分介紹完了锨能，那么多直播延遲影響有多少改善呢扯再？首先這里的就近，不一定是物理距離近址遇，不考慮瞬時(shí)負(fù)載情況下熄阻，更多是指測速延時(shí)最優(yōu)的機(jī)房。在國內(nèi)一般而言相同的接入運(yùn)營商（電信倔约、聯(lián)通秃殉、移動(dòng)）并且地理位置最近的情況網(wǎng)絡(luò)延遲最優(yōu)，小于15ms浸剩〖鼐跨省同運(yùn)營商的網(wǎng)絡(luò)延遲25~50ms，跨運(yùn)營商情況更復(fù)雜一些绢要，在50~100ms吏恭。總結(jié)起來重罪，直播當(dāng)中每個(gè)包的延時(shí)可以縮短100ms樱哼，由于網(wǎng)絡(luò)的疊加效果，反射到上層是秒級(jí)的延遲縮減蛆封。
以上就是直播云實(shí)現(xiàn)接入網(wǎng)絡(luò)優(yōu)化的技術(shù)細(xì)節(jié)唇礁。公開的直播協(xié)議眾多，RTMP惨篱、HLS盏筐、HDL（HTTP-FLV）、RTP砸讳，直播平臺(tái)應(yīng)該怎樣選擇合適的協(xié)議琢融？請(qǐng)參考《關(guān)于直播界牡，所有的技術(shù)細(xì)節(jié)都在這里了（二）》。
關(guān)于直播漾抬，所有的技術(shù)細(xì)節(jié)都在這里了（二）
2016年5月12日
上篇《關(guān)于直播宿亡，所有的技術(shù)細(xì)節(jié)都在這里了（一）》我們講述了如何讓直播內(nèi)容以“最短”路徑從主播到觀眾上，傳輸層面獲得最低延遲纳令，在本篇中我們會(huì)介紹直播應(yīng)用層協(xié)議及傳輸層協(xié)議的選擇以及對(duì)直播體驗(yàn)影響的分析?挽荠。
直播協(xié)議的選擇
國內(nèi)常見公開的直播協(xié)議有幾個(gè)：RTMP、HLS平绩、HDL（HTTP-FLV）圈匆、RTP，我們來逐一介紹捏雌。
RTMP協(xié)議：
是Adobe的專利協(xié)議跃赚，現(xiàn)在大部分國外的CDN已不支持。在國內(nèi)流行度很高性湿。原因有幾個(gè)方面：
1纬傲、開源軟件和開源庫的支持穩(wěn)定完整。如斗魚主播常用的OBS軟件肤频，開源的librtmp庫叹括，服務(wù)端有nginx-rtmp插件。
2着裹、播放端安裝率高领猾。只要瀏覽器支持FlashPlayer就能非常簡易的播放RTMP的直播，協(xié)議詳解可以Google了解骇扇。相對(duì)其他協(xié)議而言摔竿，RTMP協(xié)議初次建立連接的時(shí)候握手過程過于復(fù)雜（底層基于TCP，這里說的是RTMP協(xié)議本身的交互）少孝，視不同的網(wǎng)絡(luò)狀況會(huì)帶來給首開帶來100ms以上的延遲继低。基于RTMP的直播一般內(nèi)容延遲在2~5秒稍走。
HTTP-FLV協(xié)議：
即使用HTTP協(xié)議流式的傳輸媒體內(nèi)容袁翁。相對(duì)于RTMP，HTTP更簡單和廣為人知婿脸，而且不擔(dān)心被Adobe的專利綁架粱胜。內(nèi)容延遲同樣可以做到2~5秒，打開速度更快狐树，因?yàn)镠TTP本身沒有復(fù)雜的狀態(tài)交互焙压。所以從延遲角度來看，HTTP-FLV要優(yōu)于RTMP。
HLS協(xié)議：
即Http Live Streaming涯曲，是由蘋果提出基于HTTP的流媒體傳輸協(xié)議野哭。HLS有一個(gè)非常大的優(yōu)點(diǎn)：HTML5可以直接打開播放；這個(gè)意味著可以把一個(gè)直播鏈接通過微信等轉(zhuǎn)發(fā)分享幻件，不需要安裝任何獨(dú)立的APP拨黔，有瀏覽器即可，所以流行度很高绰沥。社交直播APP篱蝇，HLS可以說是剛需，下來我們分析下其原理 徽曲。
基于HLS的直播流URL是一個(gè)m3u8的文件态兴，里面包含了最近若干個(gè)小視頻TS（一種視頻封裝格式，這里就不擴(kuò)展介紹）文件疟位，如http://www.ucloud.cn/helloworld.m3u8是一個(gè)直播留鏈接，其內(nèi)容如下：
假設(shè)列表里面的包含5個(gè)TS文件喘垂，每個(gè)TS文件包含5秒的視頻內(nèi)容甜刻，那么整體的延遲就是25秒。當(dāng)然可以縮短列表的長度和單個(gè)TS文件的大小來降低延遲正勒，極致來說可以縮減列表長度為1得院，1秒內(nèi)容的m3u8文件，但是極易受網(wǎng)絡(luò)波動(dòng)影響造成卡頓章贞。
通過公網(wǎng)的驗(yàn)證祥绞，目前按同城網(wǎng)絡(luò)可以做到比較好的效果是5~7秒的延遲，也是綜合流暢度和內(nèi)容延遲的結(jié)果鸭限。那么HTML5是否可以有更低延遲直接打開的直播流技術(shù)呢蜕径？ 我們?cè)谧詈髸?huì)探討這個(gè)問題。
RTP協(xié)議：
即Real-time Transport Protocol败京，用于Internet上針對(duì)多媒體數(shù)據(jù)流的一種傳輸層協(xié)議兜喻。
實(shí)際應(yīng)用場景下經(jīng)常需要RTCP（RTP Control Protocol）配合來使用，可以簡單理解為RTCP傳輸交互控制的信令赡麦，RTP傳輸實(shí)際的媒體數(shù)據(jù)朴皆。
RTP在視頻監(jiān)控、視頻會(huì)議泛粹、IP電話上有廣泛的應(yīng)用遂铡，因?yàn)橐曨l會(huì)議、IP電話的一個(gè)重要的使用體驗(yàn)：內(nèi)容實(shí)時(shí)性強(qiáng)晶姊。
對(duì)比與上述3種或?qū)嶋H是2種協(xié)議扒接，RTP和它們有一個(gè)重要的區(qū)別就是默認(rèn)是使用UDP協(xié)議來傳輸數(shù)據(jù)，而RTMP和HTTP是基于TCP協(xié)議傳輸。為什么UDP 能做到如此實(shí)時(shí)的效果呢珠增？關(guān)于TCP和UDP差別的分析文章一搜一大把超歌，這里不在贅述，簡單概括：
UDP：單個(gè)數(shù)據(jù)報(bào)蒂教，不用建立連接巍举，簡單，不可靠凝垛，會(huì)丟包懊悯，會(huì)亂序；
TCP：流式梦皮，需要建立連接炭分，復(fù)雜，可靠剑肯，有序捧毛。
實(shí)時(shí)音視頻流的場景不需要可靠保障，因此也不需要有重傳的機(jī)制让网，實(shí)時(shí)的看到圖像聲音呀忧，網(wǎng)絡(luò)抖動(dòng)時(shí)丟了一些內(nèi)容，畫面模糊和花屏溃睹，完全不重要而账。TCP為了重傳會(huì)造成延遲與不同步，如某一截內(nèi)容因?yàn)橹貍饕蚱瑢?dǎo)致1秒以后才到泞辐，那么整個(gè)對(duì)話就延遲了1秒，隨著網(wǎng)絡(luò)抖動(dòng)竞滓，延遲還會(huì)增加成2秒咐吼、3秒，如果客戶端播放是不加以處理將嚴(yán)重影響直播的體驗(yàn)商佑。
總結(jié)一下：在直播協(xié)議的選擇中汽烦，如果選擇是RTMP或HTTP-FLV則意味著有2~5秒的內(nèi)容延遲，但是就打開延遲開莉御，HTTP-FLV 要優(yōu)于RTMP撇吞。HLS則有5~7秒的內(nèi)容延遲。選擇RTP進(jìn)行直播則可以做到1秒內(nèi)的直播延遲礁叔。但就目前所了解牍颈，各大CDN廠商沒有支持基于RTP直播的，所以目前國內(nèi)主流還是RTMP或HTTP-FLV琅关。
是否有除了HLS外更低延遲的方案煮岁？
HLS的優(yōu)點(diǎn)點(diǎn)是顯而易見的：移動(dòng)端無需安裝APP使用兼容HTML5的瀏覽器打開即可觀看讥蔽，所有主流的移動(dòng)端瀏覽器基本都支持HTML5，在直播的傳播和體驗(yàn)上有巨大的優(yōu)勢画机。
而看起來唯一的缺點(diǎn)：內(nèi)容延遲高（這里也有很多HLS限制沒有提到冶伞，比如必須是H264+AAC編碼，也可認(rèn)為是“缺點(diǎn)”之一）步氏。如果能得到解決响禽，那將會(huì)是直播技術(shù)非常大的一個(gè)進(jìn)步〖孕眩或者換個(gè)說法芋类，有沒有更低延遲可直接用鏈接傳播的直播方案？不局限于HLS本身界阁。
對(duì)于瀏覽器直接的視頻互動(dòng)侯繁，Google一直在推WebRTC，目前已有不少成型的產(chǎn)品出現(xiàn)泡躯，可以瀏覽器打開即實(shí)時(shí)對(duì)話贮竟、直播。但來看看如下的瀏覽器覆蓋圖：
非常遺憾的說，在直至iOS 9.3上的Safari仍然不能支持WebRTC。繼續(xù)我們的探索雹仿，那Websocket支持度如何呢？
除了老而不化的Opera Mini外，所有的瀏覽器都支持WebSocket凫乖。這似乎是個(gè)好消息确垫。梳理一下HTML5 WebSocket直播需要解決的問題：
1、后端兼容
2帽芽、傳輸
3删掀、解碼播放
對(duì)于#1似乎不是特別大問題，對(duì)于做過RTMP轉(zhuǎn)HLS导街、RTP來說是基本功披泪。#2對(duì)于瀏覽器來說使用HTTP來傳輸是比較好的選項(xiàng)。對(duì)于#3 這里推薦一個(gè)開源的JS解碼項(xiàng)目jsmpeg:https://github.com/phoboslab/jsmpeg搬瑰，里面已有一個(gè)用于直播的stream-server.js的NodeJS服務(wù)器款票。
從測試結(jié)果看，該項(xiàng)目的代碼相對(duì)較薄泽论，還沒達(dá)到工業(yè)級(jí)的成熟度艾少，需要大規(guī)模應(yīng)用估計(jì)需要自填不少坑，有興趣的同學(xué)可以學(xué)習(xí)研究翼悴。
以上就是直播云：直播應(yīng)用層協(xié)議及傳輸層協(xié)議的選擇以及對(duì)直播體驗(yàn)影響的分析 缚够。關(guān)于接入網(wǎng)絡(luò)優(yōu)化、內(nèi)容緩存與傳輸策略優(yōu)化、終端優(yōu)化谍椅，請(qǐng)參閱接下來發(fā)布的其他部分误堡。
延遲與卡頓的矛盾關(guān)系如何解決？有的時(shí)候需要主動(dòng)丟包雏吭？欲知內(nèi)容緩存與傳輸策略優(yōu)化技巧锁施，請(qǐng)關(guān)注下一篇解析內(nèi)容：《關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了（三）》思恐。
關(guān)于直播沾谜，所有的技術(shù)細(xì)節(jié)都在這里了（三）
2016年5月17日
上篇《關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了（二）》我們講述了直播應(yīng)用層協(xié)議及傳輸層協(xié)議的選擇以及對(duì)直播體驗(yàn)影響的分析 胀莹。本篇中我們將介紹在傳輸直播流媒體過程中的內(nèi)容緩存與傳輸策略優(yōu)化細(xì)節(jié)原理基跑。
基礎(chǔ)知識(shí)：I幀、B幀描焰、P幀
I幀表示關(guān)鍵幀媳否。你可以理解為這一幀畫面的完整保留；解碼時(shí)只需要本幀數(shù)據(jù)就可以完成荆秦。（因?yàn)榘暾嬅妫?/p>
P幀表示這一幀跟之前的一個(gè)關(guān)鍵幀（或P幀）的差別篱竭。解碼時(shí)需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面步绸。（也就是差別幀掺逼，P幀沒有完整畫面數(shù)據(jù)，只有與前一幀的畫面差別的數(shù)據(jù)）
B幀是雙向差別幀瓤介。B幀記錄的是本幀與前后幀的差別（具體比較復(fù)雜吕喘，有4種情況）。換言之刑桑，要解碼B幀氯质，不僅要取得之前的緩存畫面，還要解碼之后的畫面祠斧，通過前后畫面的與本幀數(shù)據(jù)的疊加取得最終的畫面闻察。
B幀壓縮率高，但是編解碼時(shí)會(huì)比較耗費(fèi)CPU琢锋，而且在直播中可能會(huì)增加直播延時(shí)辕漂，因此在移動(dòng)端上一般不使用B幀。
關(guān)鍵幀緩存策略
一個(gè)典型的視頻幀序列為IBBPBBPBBP……
對(duì)于直播而言吴超，為了減少直播的延時(shí)钮热，通常在編碼時(shí)不使用B幀。P幀B幀對(duì)于I幀都有直接或者間接的依賴關(guān)系烛芬，所以播放器要解碼一個(gè)視頻幀序列隧期，并進(jìn)行播放飒责，必須首先解碼出I幀，其后續(xù)的B幀和P幀才能進(jìn)行解碼仆潮，這樣服務(wù)端如何進(jìn)行關(guān)鍵幀的緩存宏蛉，則對(duì)直播的延時(shí)以及其他方面有非常大的影響。
比較好的策略是服務(wù)端自動(dòng)判斷關(guān)鍵幀的間隔性置，按業(yè)務(wù)需求緩存幀序列拾并，保證在緩存中存儲(chǔ)至少兩個(gè)或者以上的關(guān)鍵幀，以應(yīng)對(duì)低延時(shí)鹏浅、防卡頓嗅义、智能丟包等需求。
延遲與卡頓的折中
直播的延時(shí)與卡頓是分析直播業(yè)務(wù)質(zhì)量時(shí)隐砸，非常關(guān)注的兩項(xiàng)指標(biāo)之碗。互動(dòng)直播的場景對(duì)延時(shí)非常敏感，新聞體育類直播則更加關(guān)注播放的流暢度季希。
然而褪那，這兩項(xiàng)指標(biāo)從理論上來說，是一對(duì)矛盾的關(guān)系——需要更低的延時(shí)式塌，則表明服務(wù)器端和播放端的緩沖區(qū)都必須更短博敬，來自網(wǎng)絡(luò)的異常抖動(dòng)容易引起卡頓；業(yè)務(wù)可以接受較高的延時(shí)時(shí)峰尝，服務(wù)端和播放端都可以有較長的緩沖區(qū)偏窝，以應(yīng)對(duì)來自網(wǎng)絡(luò)的抖動(dòng)，提供更流暢的直播體驗(yàn)武学。
當(dāng)然祭往，對(duì)于網(wǎng)絡(luò)條件非常好的用戶，這兩項(xiàng)是可以同時(shí)保證的劳淆，這里主要是針對(duì)網(wǎng)絡(luò)條件不是那么好的用戶，如何解決延時(shí)與卡頓的問題默赂。
這里通常有兩種技術(shù)來平衡和優(yōu)化這兩個(gè)指標(biāo)沛鸵。
一是服務(wù)端提供靈活的配置策略，對(duì)于延時(shí)要求更敏感的缆八，則在服務(wù)端在保證關(guān)鍵幀的情況下曲掰，對(duì)每個(gè)連接維持一個(gè)較小的緩沖隊(duì)列；對(duì)于卡頓要求更高的直播奈辰，則適當(dāng)增加緩沖隊(duì)列的長度栏妖，保證播放的流暢。
二是服務(wù)端對(duì)所有連接的網(wǎng)絡(luò)情況進(jìn)行智能檢測奖恰，當(dāng)網(wǎng)絡(luò)狀況良好時(shí)吊趾，服務(wù)端會(huì)縮小該連接的緩沖隊(duì)列的大小宛裕，降低延遲；而當(dāng)網(wǎng)絡(luò)狀況較差時(shí)论泛，特別是檢測到抖動(dòng)較為明顯時(shí)揩尸，服務(wù)端對(duì)該連接增加緩沖隊(duì)列長度，優(yōu)先保證播放的流暢性屁奏。
丟包策略
什么時(shí)候需要丟包呢岩榆？
對(duì)于一個(gè)網(wǎng)絡(luò)連接很好，延時(shí)也比較小的連接坟瓢，丟包策略永遠(yuǎn)沒有用武之地的勇边。而網(wǎng)絡(luò)連接比較差的用戶，因?yàn)橄螺d速度比較慢或者抖動(dòng)比較大折联，這個(gè)用戶的延時(shí)就會(huì)越來越高粒褒。
另外一種情況是，如果直播流關(guān)鍵幀間隔比較長崭庸，那么在保證首包是關(guān)鍵幀的情況下怀浆，觀看這個(gè)節(jié)目的觀眾，延遲有可能會(huì)達(dá)到一個(gè)關(guān)鍵幀序列的長度怕享。上述兩種情況执赡，都需要啟用丟包策略，來調(diào)整播放的延時(shí)函筋。
關(guān)于丟包沙合，需要解決兩個(gè)問題：
一是正確判斷何時(shí)需要進(jìn)行丟包；
二是如何丟包以使得對(duì)觀眾的播放體驗(yàn)影響最小跌帐。較好的做法是后端周期監(jiān)控所有連接的緩沖隊(duì)列的長度首懈，這樣隊(duì)列長度與時(shí)間形成一個(gè)離散的函數(shù)關(guān)系，后端通過自研算法來分析這個(gè)離散函數(shù)谨敛，判斷是否需要丟包究履。
一般的丟幀策略，就是直接丟棄一個(gè)完整的視頻幀序列脸狸，這種策略看似簡單最仑，但對(duì)用戶播放的影響體驗(yàn)非常大。而應(yīng)該是后臺(tái)采用逐步丟幀的策略炊甲，每個(gè)視頻幀序列泥彤，丟最后的一到兩幀，使得用戶的感知最小卿啡，平滑的逐步縮小延時(shí)的效果吟吝。
以上就是UCloud直播云：內(nèi)容緩存與傳輸策略優(yōu)化細(xì)節(jié)原理。關(guān)于終端優(yōu)化颈娜，請(qǐng)參閱即將發(fā)布的《關(guān)于直播剑逃，所有的技術(shù)細(xì)節(jié)都在這里了（四）》浙宜。
關(guān)于直播，所有的技術(shù)細(xì)節(jié)都在這里了（四）
2016年5月19日
上篇《關(guān)于直播炕贵，所有的技術(shù)細(xì)節(jié)都在這里了（三）》我們講述了直播后端系統(tǒng)的原理及優(yōu)化梆奈，那么直播推流、播放端是否就沒有可以優(yōu)化的點(diǎn)呢称开？ 答案是否定的亩钟。客戶端的優(yōu)化對(duì)直播秒開鳖轰、延遲體驗(yàn)的實(shí)現(xiàn)至關(guān)重要清酥，這里重點(diǎn)介紹移動(dòng)終端的情況。
解析優(yōu)化
參見之前介紹的DNS過程蕴侣，如下圖：
基于可控和容災(zāi)的需要焰轻，移動(dòng)端代碼一般不會(huì)hardcode 推流、播放的服務(wù)器IP地址昆雀，而選用域名代替辱志。在IP出現(xiàn)宕機(jī)或網(wǎng)絡(luò)中斷的情況下，還可以通過變更DNS來實(shí)現(xiàn)問題IP的剔除狞膘。而域名的解析時(shí)間需要幾十毫秒至幾秒不等揩懒，對(duì)于新生成熱度不高的域名，一般的平均解析延遲在300ms挽封，按上圖的各個(gè)環(huán)節(jié)只要有一個(gè)通路網(wǎng)絡(luò)產(chǎn)生波動(dòng)或者是設(shè)備高負(fù)載已球，會(huì)增加至秒級(jí)。幾十毫秒的情況是ISP NS這一層在熱度足夠高的情況下會(huì)對(duì)域名的解析進(jìn)行緩存辅愿。如下圖：
按我們上面分析的情況智亮，本省延遲大概是15ms左右，那么域名解析最低也可以做到15ms左右点待。但由于直播場景的特殊性阔蛉，推流和播放使用的域名使用的熱度較難達(dá)到ISP NS緩存的標(biāo)準(zhǔn)，所以經(jīng)常需要走回Root NS進(jìn)行查詢的路徑癞埠。
那客戶端解析優(yōu)化的原理就出來了：本機(jī)緩存域名的解析結(jié)果状原，對(duì)域名進(jìn)行預(yù)解析，每次需要直播推流和播放的時(shí)候不再需要再進(jìn)行DNS過程燕差。此處節(jié)省幾十到幾百毫秒的打開延遲遭笋。
播放優(yōu)化
直播播放器的相關(guān)技術(shù)點(diǎn)有：直播延時(shí)坝冕、首屏?xí)r間（指從開始播放到第一次看到畫面的時(shí)間）徒探、音視頻同步、軟解碼喂窟、硬解碼测暗。參考如下播放流程：
播放步驟描述：
根據(jù)協(xié)議類型（如RTMP央串、RTP、RTSP碗啄、HTTP等）质和，與服務(wù)器建立連接并接收數(shù)據(jù)；
解析二進(jìn)制數(shù)據(jù)稚字，從中找到相關(guān)流信息饲宿；
根據(jù)不同的封裝格式（如FLV、TS）解復(fù)用（demux）胆描；
分別得到已編碼的H.264視頻數(shù)據(jù)和AAC音頻數(shù)據(jù)瘫想；
使用硬解碼（對(duì)應(yīng)系統(tǒng)的API）或軟解碼（FFMpeg）來解壓音視頻數(shù)據(jù)；
經(jīng)過解碼后得到原始的視頻數(shù)據(jù)（YUV）和音頻數(shù)據(jù)（AAC）昌讲；
因?yàn)橐纛l和視頻解碼是分開的国夜，所以我們得把它們同步起來，否則會(huì)出現(xiàn)音視頻不同步的現(xiàn)象短绸，比如別人說話會(huì)跟口型對(duì)不上车吹；
最后把同步的音頻數(shù)據(jù)送到耳機(jī)或外放，視頻數(shù)據(jù)送到屏幕上顯示醋闭。
了解了播放器的播放流程后窄驹，我們可以優(yōu)化以下幾點(diǎn)：
首屏?xí)r間優(yōu)化
從步驟2入手，通過預(yù)設(shè)解碼器類型目尖，省去探測文件類型時(shí)間馒吴；
從步驟5入手，縮小視頻數(shù)據(jù)探測范圍瑟曲，同時(shí)也意味著減少了需要下載的數(shù)據(jù)量饮戳，特別是在網(wǎng)絡(luò)不好的時(shí)候，減少下載的數(shù)據(jù)量能為啟動(dòng)播放節(jié)省大量的時(shí)間洞拨，當(dāng)檢測到I幀數(shù)據(jù)后就立馬返回并進(jìn)入解碼環(huán)節(jié)扯罐。
延時(shí)優(yōu)化
視頻緩沖區(qū)或叫視頻緩存策略，該策略原理是當(dāng)網(wǎng)絡(luò)卡頓時(shí)增加用戶等待時(shí)間來緩存一定量的視頻數(shù)據(jù)烦衣，達(dá)到后續(xù)平滑觀看的效果歹河，該技術(shù)能有效減少卡頓次數(shù)，但是會(huì)帶來直播上的內(nèi)容延時(shí)花吟，所以該技術(shù)主要運(yùn)用于點(diǎn)播秸歧，直播方面已去掉該策略，以此盡可能去掉或縮小內(nèi)容從網(wǎng)絡(luò)到屏幕展示過程中的時(shí)間衅澈；（有利于減少延時(shí)）键菱。
下載數(shù)據(jù)探測池技術(shù)，當(dāng)用戶下載速度不足發(fā)生了卡頓今布，然后網(wǎng)絡(luò)突然又順暢了经备，服務(wù)器上之前滯留的數(shù)據(jù)會(huì)加速發(fā)下來拭抬，這時(shí)為了減少之前卡頓造成的延時(shí)，播放器會(huì)加速播放探測池的視頻數(shù)據(jù)并丟棄當(dāng)前加速部分的音頻數(shù)據(jù)侵蒙，以此來保證當(dāng)前觀看內(nèi)容延時(shí)穩(wěn)定造虎。
推流優(yōu)化
推流步驟說明：很容易看出推流跟播放其實(shí)是逆向的，具體流程就不多說了纷闺。
優(yōu)化一：適當(dāng)?shù)腝os（Quality of Service算凿，服務(wù)質(zhì)量）策略。
推流端會(huì)根據(jù)當(dāng)前上行網(wǎng)絡(luò)情況控制音視頻數(shù)據(jù)發(fā)包和編碼犁功，在網(wǎng)絡(luò)較差的情況下澎媒，音視頻數(shù)據(jù)發(fā)送不出去，造成數(shù)據(jù)滯留在本地波桩，這時(shí)戒努，會(huì)停掉編碼器防止發(fā)送數(shù)據(jù)進(jìn)一步滯留，同時(shí)會(huì)根據(jù)網(wǎng)絡(luò)情況選擇合適的策略控制音視頻發(fā)送镐躲。
比如網(wǎng)絡(luò)很差的情況下储玫，推流端會(huì)優(yōu)先發(fā)送音頻數(shù)據(jù)，保證用戶能聽到聲音萤皂，并在一定間隔內(nèi)發(fā)關(guān)鍵幀數(shù)據(jù)撒穷，保證用戶在一定時(shí)間間隔之后能看到一些畫面的變化。
優(yōu)化二：合理的關(guān)鍵幀配置裆熙。
合理控制關(guān)鍵幀發(fā)送間隔（建議2秒或1秒一個(gè)）端礼，這樣可以減少后端處理過程，為后端的緩沖區(qū)設(shè)置更小創(chuàng)造條件入录。
軟硬編解選擇
網(wǎng)上有不少關(guān)于選擇軟解還是硬解的分析文章蛤奥，這里也介紹一些經(jīng)驗(yàn)，但根本問題是僚稿，沒有一個(gè)通用方案能最優(yōu)適配所有操作系統(tǒng)和機(jī)型凡桥。
推流編碼：推薦Andorid4.3（API18）或以上使用硬編，以下版本使用軟編蚀同；iOS使用全硬編方案缅刽；
播放解碼：Andorid、iOS播放器都使用軟解碼方案蠢络，經(jīng)過我們和大量客戶的測試以及總結(jié)衰猛，雖然犧牲了功耗，但是在部分細(xì)節(jié)方面表現(xiàn)會(huì)較優(yōu)刹孔，且可控性強(qiáng)啡省，兼容性也強(qiáng)，出錯(cuò)情況少，推薦使用冕杠。
附軟硬編解碼優(yōu)缺點(diǎn)對(duì)比：
云端機(jī)型及網(wǎng)絡(luò)適配
上面分析了很多針對(duì)視頻編解碼的參數(shù)，但實(shí)際情況最好的編解碼效果是需要根據(jù)機(jī)型的適配的酸茴，由于iOS的設(shè)備類型較少分预，可以做到每個(gè)機(jī)型針對(duì)性的測試和調(diào)優(yōu)，但是對(duì)于Android就非常難做到逐款機(jī)型針對(duì)性調(diào)優(yōu)薪捍，并且每年都會(huì)出產(chǎn)不少的新機(jī)器笼痹，如果代碼中寫死了配置或判斷邏輯將非常不利于維護(hù)和迭代。
所以我們就誕生了一個(gè)想法酪穿，這些判斷邏輯或配置是否可以放在云上呢? ?這樣就產(chǎn)生了云端機(jī)型與網(wǎng)絡(luò)適配的技術(shù)凳干。
終端在推流、播放前會(huì)獲取通過協(xié)議上報(bào)當(dāng)前的機(jī)型配置被济、網(wǎng)絡(luò)情況救赐、IP信息。云端會(huì)返回一個(gè)已最適合的編解碼策略配置：走軟編還是硬編只磷、各項(xiàng)參數(shù)的配置经磅，就近推流服務(wù)的IP，就近播放服務(wù)的IP钮追。 終端獲取一次即可预厌，不需要每次推流、播放前都去獲取一次元媚。
這樣轧叽，在我們不斷的迭代和完善機(jī)型編解碼適配庫的同時(shí)，所有使用該技術(shù)的直播APP都將收益刊棕。
總結(jié)
分析很多直播后端炭晒、終端的關(guān)于低延遲、秒開的優(yōu)化技術(shù)甥角，在UCloud直播云上都已有了相關(guān)的實(shí)踐腰埂，都是一些較“靜態(tài)”的技術(shù)。實(shí)際提供穩(wěn)定蜈膨、低延遲屿笼、流暢的直播服務(wù)，是日常中非常大量細(xì)致的監(jiān)控翁巍、算法和動(dòng)態(tài)運(yùn)營的結(jié)果驴一，并不是實(shí)現(xiàn)了某些的技術(shù)點(diǎn)，就能坐享一套穩(wěn)定的直播服務(wù)灶壶，只能說是完成了萬里長城的第一道磚肝断。
