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

詳情請戳：http://m.51huadong.com/2016/vod.asp

上行匯聚

目前傳統(tǒng)直播 CDN 上行一般使用 RTMP 協(xié)議，當(dāng)然也有⼀些使用 UDP(UDP 方式由于需要 SDK 配合，目前行業(yè)內(nèi)有人在做，但是需要綁定 SDK)。另外國外還有使用 http-ts 的方式進(jìn)行推流的，可參見 nginx-rtmp 項(xiàng)目大神開源的 nginx-ts-module。目前使用這種方式，關(guān)鍵問題在于端的支持問題，而該開源項(xiàng)目目前只支持 HLS 和 Dash 的播放。

除了主播推流以外，還有一種方式是從匯聚點(diǎn)到業(yè)務(wù)方源站去拉流的方式。

下行分發(fā)

目前下行分發(fā)一般使用的協(xié)議，rtmp，http-flv，hls 三種協(xié)議。這三種協(xié)議的優(yōu)劣，網(wǎng)上已經(jīng)有很多文章， 一般從終端兼容性，延遲，首屏幾個(gè)維度去考慮，這里就不再進(jìn)行比較。

rtmp 和 http-flv

由于 rtmp 協(xié)議在發(fā)送數(shù)據(jù)前交互次數(shù)較多，比較追求首屏的直播平臺一般都會(huì)選擇 http-flv 協(xié)議作為下行分發(fā)協(xié)議，線上環(huán)境測試效果平均會(huì)增加 100-200 ms 左右的時(shí)間，網(wǎng)絡(luò)越差，這個(gè)值越大。 rtmp 和 http-flv 的延遲可以做到 3s 以內(nèi)，但是由于網(wǎng)絡(luò)環(huán)境的復(fù)雜，過低的延遲會(huì)導(dǎo)致卡頓率的提升，所以 一般 CDN 會(huì)在用戶接入時(shí)，給用戶多發(fā)幾秒鐘的數(shù)據(jù)(⼀般是 5-8s)，填充播放端緩沖區(qū)，來抗網(wǎng)絡(luò)端的抖動(dòng)。 細(xì)節(jié)技術(shù)會(huì)在后⾯面的⽂文章中介紹。

hls

hls 對 Android 端和 IOS 端支持較好，并且對 P2P 的支持也較好，一般對延遲要求不高的直播平臺(如體育賽事)會(huì)選用這個(gè)協(xié)議。 hls 的延遲一般和切片大小有關(guān)，一般切片是 6-8s 一個(gè)片，這個(gè)大小對一般主播推流 GOP 適配好。過高會(huì)導(dǎo)致延遲加⼤大，過低，可能切片里就沒有關(guān)鍵幀。一般 m3u8 文件里會(huì)有 3 個(gè) ts 文件，播放器會(huì)在下完兩個(gè)片以后開始播放，并且同時(shí)下第三個(gè)片。因此一般 hls 的時(shí)延在 15s 左右。

當(dāng)然如果用戶調(diào)小 GOP(1s)，CDN 端將切片方式配置為按 GOP 切片的方式，HLS 實(shí)際也可以做到 5s 以內(nèi)延遲的。當(dāng)然壞處就是會(huì)導(dǎo)致卡頓率變高。

其它協(xié)議

dash 和 hds

類似 hls 的還有 dash 和 hds。dash 在國外用得比較多，實(shí)際原生的 nginx-rtmp 就支持 dash，只不過國內(nèi)用得比較少。hds 是 adobe 自己搞的切片協(xié)議，一般鮮有開源項(xiàng)目支持(SRS 支持，但是應(yīng)該沒有商用 CDN 使用)。

http-fmp4

由于 Adobe 宣布退出 Flash，目前也有平臺在研究⼀些替代技術(shù)，如 B 站開源的 flv.js，就是在頁面上使用 js 將 flv 轉(zhuǎn)封裝為 fmp4，然后可以使用 H5 進(jìn)行觀看。

目前個(gè)人也在研究在 CDN 端加入 http-fmp4 的支持，其實(shí)問題還是挺多的。fmp4 雖然可以支持流式播放， 但是與 flv 和 ts 這種天生就為流式傳輸而生的協(xié)議不同，fmp4 實(shí)際上還是問題比較多的。

fmp4 的視頻頭是放在 moov 中的(stsd box 下)，在直播中會(huì)遇到變碼率的情況，重發(fā)視頻頭，這種對于 fmp4 實(shí)際上是不支持的。

一個(gè) moof 放幾幀數(shù)據(jù)的問題，由于 mp4 的 box 是按照 box 長度 + box 標(biāo)簽 + box 內(nèi)容，所以必須知 道后面所有數(shù)據(jù)幀的長度，才能打包一個(gè) moof。這樣勢必就需要收到好多幀，才能打一個(gè) moof 包，這種方式實(shí)際對直播來說是不好的(dash 不存在這個(gè)問題)。當(dāng)然也可以⼀個(gè)數(shù)據(jù)幀打一個(gè) moof 包，但是取決于是否接受每幀前面加一個(gè) moof 的開銷。

補(bǔ)充：nginx-rtmp 中的 dash 打包也是使用的 fmp4 方式。一般是一個(gè) GOP 或者 10M 數(shù)據(jù)打成一個(gè) moof。

UDP

UDP 方式，和前面提到的上行使用 UDP 分發(fā)⼀樣，下行使用 UDP 同樣存在著標(biāo)準(zhǔn)化問題，同樣存在 SDK 配合問題。當(dāng)然，對于直播來說，追求卡頓率，延遲的極致，UDP 后續(xù)必然是一種趨勢。后⾯我們會(huì)在互動(dòng)直播中詳細(xì)討論。

轉(zhuǎn)碼

CDN 一般會(huì)提供轉(zhuǎn)碼服務(wù)，一般按照分類可分為在線轉(zhuǎn)碼和離線轉(zhuǎn)碼兩部分。

在線轉(zhuǎn)碼

一般我們會(huì)把截圖，水印，直播轉(zhuǎn)碼歸為在線轉(zhuǎn)碼，直播轉(zhuǎn)碼又分為主動(dòng)轉(zhuǎn)碼和被動(dòng)轉(zhuǎn)碼兩種．

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

水印，就是在主播的視頻中加入直播平臺的標(biāo)簽，類似于電視臺的臺標(biāo)。這種方式可能是按需的，如一 些主播使用直播平臺提供的直播工具，在推流出來前就可以打上水印，但是一些主播使用 OBS 推流， 就需要 CDN 來加水印�？梢酝ㄟ^加參數(shù)的方式，告訴 CDN 是否需要加水印。

主動(dòng)轉(zhuǎn)碼，即用戶推流到 CDN 后就按照客戶需求將源流轉(zhuǎn)為幾路子碼流，播放端可以根據(jù)網(wǎng)絡(luò)情況選擇播放碼率(如標(biāo)清，高清，超清等)。這種方式，由于子流已經(jīng)轉(zhuǎn)出，能夠保證首路播放的首屏?xí)r間。 但是，并不是所有主播都有人觀看，實(shí)際大的直播平臺，有很大比例的主播是沒有觀眾的，轉(zhuǎn)碼又是⼀ 種很耗資源的業(yè)務(wù)，因此主動(dòng)轉(zhuǎn)碼對 CDN 的計(jì)算資源消耗是很大的。

被動(dòng)轉(zhuǎn)碼，即有觀看子碼流再轉(zhuǎn)碼，這種方式會(huì)大大降低計(jì)算資源的消耗，一般大的直播平臺都會(huì)選用被動(dòng)轉(zhuǎn)碼的方式，因?yàn)閷τ诖笾鞑ィ�第一個(gè)人的首屏影響可以忽略不計(jì)。

對于直播轉(zhuǎn)碼一般還會(huì)有階梯轉(zhuǎn)碼，如根據(jù)主播碼率決定要轉(zhuǎn)幾檔。對于被動(dòng)轉(zhuǎn)碼，可以選擇只轉(zhuǎn)出常用的幾種碼率，對于不常用的碼率選擇按需的方式。這些都是 CDN 對直播資源的優(yōu)化處理方式。

離線轉(zhuǎn)碼

離線轉(zhuǎn)碼在直播中主要是對直播錄制文件的處理。

直播轉(zhuǎn)點(diǎn)播，和直播不同，點(diǎn)播一般更常用的協(xié)議是 mp4 和 hls，而直播一般錄制使用的是 flv 和 hls。 因此需要在錄制后將錄制文件轉(zhuǎn)封裝成 mp4 或 hls。

輪播，類似于電視臺體育賽事錄播功能，將直播內(nèi)容進(jìn)行剪輯后，在某個(gè)時(shí)間段(一般是主播下播時(shí)間) 循環(huán)播放，一般使用錄制文件轉(zhuǎn)推直播流的方式。

延播，一些直播內(nèi)容，業(yè)務(wù)方需要進(jìn)行審核，審核完成以后再直播出來，如果有問題，及時(shí)掐斷，有問題的內(nèi)容就不會(huì)再播放出來。這個(gè)時(shí)間一般在 10 分鐘以上，一般直播引擎使用內(nèi)存進(jìn)行數(shù)據(jù) cache， 因此對這種長時(shí)間的延播，一般也是使用定時(shí)將錄制文件重新轉(zhuǎn)成直播流的方式。

FLV+H.265(HEVC)

官方標(biāo)準(zhǔn) FLV 實(shí)際是不支持 H.265 的，但是目前很多直播平臺為降低帶寬成本，CDN 也應(yīng)業(yè)務(wù)需求推出了 FLV+H.265 的支持，一般定義的 CodecID 是 12，轉(zhuǎn)碼需要對 ffmpeg 進(jìn)行修改，參考實(shí)測效果，H.265 的轉(zhuǎn)碼比 H.264 大很多，對終端的要求也比較高，目前應(yīng)用還不是很廣泛，應(yīng)該還處于技術(shù)孕育階段。

錄制

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

為什么不用 mp4，主要取決于 mp4 的封裝結(jié)構(gòu)和直播特性的兼容問題： 一般支持 mp4 的 fast-open，會(huì)把 moov 頭放在文件前面，mdat 放在后面。由于 mp4 對各平臺 H5 支持的緣故，現(xiàn)在視頻平臺一般會(huì)把 mp4 作為點(diǎn)播的源的封裝格式。播放器只要下載完 moov 頭，就可以根據(jù) moov 中 stco 標(biāo)記的每⼀幀的位置對視頻進(jìn)行拖動(dòng)。但是，在直播中，數(shù)據(jù)幀是實(shí)時(shí)增加的，這樣就導(dǎo)致 moov 頭會(huì)一直變，而無法確認(rèn)后面數(shù)據(jù)幀的偏移位置，這樣就無法確認(rèn) moov 頭到底有多大，那緊接著 moov 的 mdat 在整個(gè) mp4 中的偏移量就無法確定，那如何去確認(rèn) moov 中 stco 的偏移量。因此 CDN 一般錄制更常用的就是對流式傳輸比較親和的 flv 和 hls。

當(dāng)然，mp4 也可以像 HLS ⼀樣分片存， 但是我們更傾向于后兩種方式。而對直播轉(zhuǎn)點(diǎn)播 mp4，通常都是在完成直播后再全部轉(zhuǎn)封裝為 mp4，或者播 放超過⼀段時(shí)間后轉(zhuǎn)一個(gè) mp4 文件，如 1 小時(shí)。

時(shí)移

目前時(shí)移多使用 HLS 的方式，也有人用 flv 的，但是需要對 flv 進(jìn)行大文件分片。在直播中，時(shí)移一般需要配合錄制⼀起使用。

鑒權(quán)

鑒權(quán)分為上行鑒權(quán)和下行鑒權(quán)。

直播的鑒權(quán)一般有以下幾種：

referer 鑒權(quán)，這種主要是下行 http 用，根據(jù) referer 白名單或黑名單方式。比較容易破解。

簽名算法的方式，上行和下行皆可使用。一般是直播平臺根據(jù)用戶的 key 和 timestamp 參數(shù)，加上用戶 的 secret 算出⼀個(gè) signature，和用戶帶上來的 signature 進(jìn)行比較。timestamp 保證 signature 在⼀定 時(shí)間(一般是分鐘級別)范圍內(nèi)有效。當(dāng)然直播平臺不可能把 key 放到客戶端代碼中，一般直播平臺會(huì)有 ⼀套從服務(wù)端獲取 signature 的方法。

回源鑒權(quán)，上行和下行皆可使用。當(dāng)請求到 CDN 后，CDN 向業(yè)務(wù)平臺 API 服務(wù)器進(jìn)行請求，由業(yè)務(wù)平臺判斷是否放行。下行為保證首屏，一般會(huì)使用異步的方式，即向業(yè)務(wù)平臺 API 服務(wù)器發(fā)送鑒權(quán)請 的同時(shí)先放行播放端。拿到鑒權(quán)結(jié)果后，如果是禁播，再通過禁播接口對觀眾進(jìn)行斷流處理。

一般 CDN 可以支持以上一種或多種鑒權(quán)進(jìn)行使用。

其它業(yè)務(wù)

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

天下數(shù)據(jù)視頻直播服務(wù)器解決方案，高效解決直播技術(shù)難題；全球cdn節(jié)點(diǎn)等眾多優(yōu)勢功能選擇，打造高效直播流媒體解決方案！

本文鏈接：http://m.51huadong.com/cloundnews/11001919.html