CDN 分發(fā)網(wǎng)絡在直播中的應用

傳統(tǒng)直播一般是基于CDN網(wǎng)絡分發(fā)可以支持大規(guī)模并發(fā)(并發(fā)數(shù)取決于CDN網(wǎng)絡容量)CDN的大文件，小文件分發(fā)不同，由于主播分布區(qū)域分散，一般除了提供播放端的下行分發(fā)網(wǎng)絡外，還提供上行主播推流匯聚網(wǎng)絡。只有一些直播內容資源集中的業(yè)務方，會要求直播CDN直接回到自己的源站。

詳情請戳：

上行匯聚

傳統(tǒng)傳統(tǒng)直播CDN上行一般使用RTMP當然也有協(xié)議⼀些使用UDP(UDP需要方法SDK合作，業(yè)內有人在做，但需要綁定SDK)。此外，它還在國外使用http-ts推流的方式可以參見nginx-rtmp項目大神開源nginx-ts-module。目前，關鍵問題在于終端支持，而開源項目只支持HLS和Dash的播放。

除了主播推流，還有一種從聚集點到業(yè)務方源站拉流的方式。

下行分發(fā)

目前下行分發(fā)一般使用的協(xié)議，rtmp，http-flv，hls三種協(xié)議。網(wǎng)上有很多關于這三種協(xié)議優(yōu)缺點的文章，一般從終端兼容性、延遲、第一個屏幕維度考慮，這里不再比較。

rtmp和http-flv

由于rtmp協(xié)議在發(fā)送數(shù)據(jù)之前交互次數(shù)較多，追求第一屏的直播平臺一般會選擇http-flv作為下行分發(fā)協(xié)議，在線環(huán)境測試的平均效果將增加100-200ms網(wǎng)絡越差，值越大。rtmp和http-flv延遲可達3s但由于網(wǎng)絡環(huán)境復雜，延遲過低會導致卡頓率提高，所以一般CDN用戶接入時，會多發(fā)幾秒鐘的數(shù)據(jù)(⼀般是5-8s)，填充播放端緩沖區(qū)，抵抗網(wǎng)絡端抖動。細節(jié)技術會在后⾯面的⽂；文章介紹。

hls

hls對Android端和IOS端支持好，對P2P該協(xié)議也得到了很好的支持。該協(xié)議通常用于對延遲要求較低的直播平臺（如體育賽事）。hls延遲一般與切片尺寸有關，一般為6-8s一部電影，這個大小是普通主播推廣的GOP適配好。過高會導致延遲加⼤；大，太低，切片中可能沒有關鍵幀。一般m3u會有三個文件ts文件，播放器；下兩片后開始播放，同時下第三片。因此一般hls的時延在15s左右。

當然，如果用戶減少GOP(1s)，CDN根據(jù)切片方式配置切片方式GOP切片的方式，HLS實際上也可以做到5s內部延遲。當然，缺點是卡頓率會增加。

其它協(xié)議

dash和hds

類似hls的還有dash和hds。dash在國外使用較多，實際上是原生的nginx-rtmp就支持dash，但國內使用較少。hds是adobe自己的切片協(xié)議，一般很少有開源項目支持(SRS支持，但是應該沒有商用CDN使用)。

http-fmp4

由于Adobe宣布退出Flash，研究中也有平臺⼀；B站開源等替代技術flv.js，在頁面上使用js將flv轉封裝為fmp然后就可以用了H5進行觀看。

個人也在研究CDN端加入http-fmp支持4，其實問題還是挺多的。fmp雖然4可以支持流式播放，但與flv和ts這種自然的流式傳輸協(xié)議是不同的，fmp其實問題還是比較多的。

fmp放置4個視頻頭moov中的(stsdbox下)，在直播中會遇到變碼率，重新發(fā)送視頻頭，這對于fmp4實際上是不支持的。

一個moof因為放幾幀數(shù)據(jù)的問題，mp4的box是按照box長度 box標簽 box因此，在打包之前，必須知道所有數(shù)據(jù)幀的長度moof。這必然需要收到很多幀才能個moof包，這種方式其實對直播不好(dash沒有這個問題)。當然也可以⼀；一個數(shù)據(jù)幀moof但這取決于是否接受每幀前添加一個moof的開銷。

補充：nginx-rtmp中的dash包裝也包裝fmp四種方式。一般是一個GOP或者10M數(shù)據(jù)打成一個moof。

UDP

UDP方法，上述上述上行使用UDP分發(fā)⼀；樣品，向下使用UDP標準化問題也存在，也存在SDK配合問題。當然，對于直播來說，追求卡頓率和極端延遲，UDP后續(xù)必然是一種趨勢。⾯；我們將在互動直播中詳細討論。

轉碼

CDN一般提供轉碼服務，按分類可分為在線轉碼和離線轉碼兩部分。

在線轉碼

一般來說，我們將截圖、水印、直播轉碼分為在線轉碼，直播轉碼分為主動轉碼和被動轉碼。

直播截圖一般用于一些審核業(yè)務，如直播鑒黃。還有直播平臺上主播封面的貼圖(這種貼圖一般會定期更新)。

水印是在主播的視頻中添加直播平臺的標簽，類似于電視臺的標簽。這種方法可能是按需的。例如，一些主播可以在推出前使用直播平臺提供的直播工具打印水印，但一些主播使用水印OBS需要推流CDN加水印。你可以通過添加參數(shù)告訴我CDN是否需要加水印。

主動轉碼，即用戶流向CDN后就按照客戶需求將源流轉為幾路子碼流，播放端可以根據(jù)網(wǎng)絡情況選擇播放碼率(如標清，高清，超清等)。這樣，由于子流已轉出，可以保證首路播放的首屏時間。然而，并非所有的主播都被觀看。在實際的大型直播平臺上，很大一部分主播沒有觀眾，轉碼也是⼀；資源消耗量大的業(yè)務，主動轉碼CDN計算資源消耗量很大。

被動轉碼，即觀看子碼流再轉碼，將大大降低計算資源的消耗。一般來說，大型直播平臺會選擇被動轉碼，因為對于大型主播來說，第一人的第一屏影響可以忽略不計。

對于直播轉碼，一般會有階梯轉碼，比如根據(jù)主播的代碼率決定轉幾檔。對于被動轉碼，可以選擇只轉出幾個常用的代碼率，根據(jù)需要選擇不常用的代碼率。這些都是CDN優(yōu)化直播資源。

離線轉碼

直播中離線轉碼主要處理直播錄制文件。

與直播不同，點播通常更常用的協(xié)議是mp4和hls，直播一般用于錄制flv和hls。因此，錄制后需要將錄制文件轉包mp4或hls。

輪播類似于電視臺體育賽事的錄播功能。剪輯直播內容后，在一定時間內(通常是主播的下播時間)循環(huán)播放，錄制文件一般用來推直播流。

對于一些直播內容，業(yè)務方需要審核，審核完成后再直播。如有問題，及時切斷，有問題的內容不再播放。這個時間一般在10分鐘以上。一般直播引擎使用內存進行數(shù)據(jù)cache，因此，對于這種長期的延遲，錄制文件通常被定期轉換為直播流。

FLV H.265(HEVC)

官方標準FLV實際上是不支持的H.但目前很多直播平臺都是為了降低帶寬成本，CDN還應推出業(yè)務需求FLV H.支持265，一般定義CodecID是12，轉碼需要正確ffmpeg修改，參考實測效果，H.265的轉碼比H.264大很多，對終端的要求也比較高，目前應用不是很廣泛，還處于技術孕育階段。

錄制

直播錄制一般可以使用flv和hls兩種，nginx-rtmp的record模塊支持flv的錄制，hls模塊支持hls錄制(配置不清除分片)。

為什么不用mp主要看mp4.包裝結構與直播特點的兼容性：一般支持mp4的fast-open，會把moov頭放在文件前面，mdat放在后面。由于mp4對各平臺H由于5的支持，視頻平臺通常會支持它mp4作為點播源的封裝格式。只需下載播放器moov頭，可以根據(jù)moov中stco標記的每⼀；幀的位置拖動視頻。但在直播中，數(shù)據(jù)幀實時增加，導致數(shù)據(jù)幀實時增加moov頭部會一直變化，后面數(shù)據(jù)幀的偏移位置無法確認，因此無法確認moov頭到底有多大，moov的mdat在整個mp4中的偏移量無法確定，如何確認？moov中stco的偏移量。因此CDN一般來說，對流傳輸更為親和flv和hls。

當然，mp4也可以像HLS⼀；樣分片存儲，但我們更傾向于后兩種方式。直播轉點播mp4.通常在完成直播后轉包裝mp四、或播放超過⼀mp4文件，如1小時。

時移

目前時移多用HLS也有人用flv是的，但需要對flv大文件分片。在直播中，時移通常需要配合錄制⼀；開始使用。

鑒權

鑒權分為上行鑒權和下行鑒權。

直播鑒權一般有以下幾種:

referer鑒權主要是下行http用，根據(jù)referer白名單或黑名單。更容易破解。

上下都可以使用簽名算法。一般來說，直播平臺是基于用戶的key和timestamp加上用戶的參數(shù)secret算出⼀個signature，帶給用戶signature進行比較。timestamp保證signature在⼀；定時間(一般為分鐘級)范圍內有效。當然，直播平臺不可能key在客戶端代碼中，一般直播平臺都會有⼀signature的方法。

回源鑒權，可上下使用。當請求到達時CDN后，CDN向業(yè)務平臺API服務器；請求由業(yè)務平臺判斷是否放行。下行為保證了第一個屏幕，一般采用異步的方式，即向業(yè)務平臺API服務器；發(fā)送鑒權請同時放行播放端。獲得鑒權結果后，如果是禁播，觀眾將被禁播接口切斷。

一般CDN可以支持以上一種或多種鑒權進行使用。

其它業(yè)務

其他業(yè)務還包括斷流、禁播、開停播通知、觀看⼈；人數(shù)統(tǒng)計等。

騰佑科技視頻直播服務器解決方案，高效解決直播技術問題；全球cdn節(jié)點等諸多優(yōu)勢功能選擇，打造高效直播流媒體解決方案！