互聯(lián)網(wǎng)多媒體內(nèi)容傳輸從大方向上可以分為下載傳輸和流式傳輸，而流式傳輸又可以分為順序流式傳輸和實時流式傳輸，換句話來說就是點播(Video on Demand)和直播(Live Streaming)，顧名思義，前者的媒體內(nèi)容是提前存儲在服務(wù)器上供客戶端請求播放，而后者是實時產(chǎn)生并分發(fā)給客戶端播放。

?本文是網(wǎng)易視頻云骨灰級研發(fā)工程師羅偉基于HTTP的流媒體點播技術(shù)入門，講述了一些基本的概念以及這一技術(shù)的變革演進(jìn)。

●●●

HTTP流媒體點播技術(shù)優(yōu)勢

互聯(lián)網(wǎng)上傳播音視頻內(nèi)容最早從上世紀(jì)90年代開始，RTP等專有協(xié)議的提出就是定義音視頻的包格式以獲得更低的網(wǎng)絡(luò)傳遞開銷。不過現(xiàn)如今的互聯(lián)網(wǎng)世界，CDN扮演著非常重要的角色，而絕大部分CDN廠商是不支持RTP等協(xié)議的。基于HTTP的流媒體點播技術(shù)則占據(jù)著主流，其有幾點優(yōu)勢：

• 防火墻友好；

• 客戶端控制媒體流的訪問，服務(wù)端不需要為每一個客戶端連接維護(hù)媒體session狀況

• 采用標(biāo)準(zhǔn)的HTTP服務(wù)器即可，支撐大規(guī)模客戶端訪問不需要額外的服務(wù)器技術(shù)資源開銷，最重要的就是CDN技術(shù)的良好支持優(yōu)化。

? ? ? ? ? ? ? ? ? ? ? ? ? ?

●●●

HTTP流媒體技術(shù)變革

HTTP流媒體技術(shù)的變革大致經(jīng)過了以下四個階段：

最初，我們只能先下載完整視頻文件到本地磁盤后，然后才能播放觀賞。這意味著你必須等待視頻下載操作的完成，嚴(yán)格來講，根據(jù)我們第一段的劃分，這不能稱作為流媒體傳輸，不過我們還是列出來，以作對比。

在上面簡單下載文件的基礎(chǔ)上，一個明顯的提升就是漸進(jìn)式下載技術(shù)。這種情況下不需要完整下載視頻文件，可以邊下載邊播放，這就要求視頻的元數(shù)據(jù)信息得放在視頻文件的開頭。但是，我們只能在已經(jīng)下載的那一部分自由拖拽播放，而未下載的部分是不能播放的。

在漸進(jìn)式下載的基礎(chǔ)上，pseudo-streaming(偽流)出現(xiàn)了，其增強(qiáng)了seek播放功能，也就是支持直接切到未下載的地方進(jìn)行觀看，所以也可以稱之為漸進(jìn)式播放。?

其實，到pseudo-streaming 這一步，流媒體播放的技術(shù)已經(jīng)很成熟了，而且目前絕大多數(shù)的視頻網(wǎng)站都是這種技術(shù)，比如Youtube、優(yōu)酷、騰訊視頻等。如果，要在這個基礎(chǔ)上再一步的優(yōu)化，可以從哪些方面呢？比較容易想到的就是帶寬優(yōu)化，能夠鏈路感知，這就是下面的自適應(yīng)比特率流。其原理就是，同一視頻內(nèi)容會有不同的碼率版本，客戶端播放器會動態(tài)地根據(jù)網(wǎng)絡(luò)質(zhì)量切換請求帶寬匹配的的視頻片段。

自適應(yīng)碼率流媒體技術(shù)，業(yè)內(nèi)比較常見的實現(xiàn)是Apple的HTTP Live Streaming (HLS)以及Adobe的HTTP Dynamic Streaming (HDS)，下圖簡單展示了HLS的文件結(jié)構(gòu)，可以看到master playlist包含了兩種不同碼率的播放列表，當(dāng)然如果你只有一種版本，那么就不需要master playlist了。基于HTTP的自適應(yīng)碼率流媒體是有國際標(biāo)準(zhǔn)的，那就是3GPP組織和MPEG小組所提出的MPEG-DASH(DynamicAdaptive Streaming over HTTP)。

??

●●●

點播流媒體服務(wù)器工作原理

目前，很常見的一種搭建方式就是基于nginx，而nginx本身對音視頻媒體的處理就有一定的支持，官方就有flv和mp4的插件，即ngx_http_flv_module和ngx_http_mp4_module。前者支持以字節(jié)偏移的漸進(jìn)式seek播放，后者支持以時間偏移的漸進(jìn)式seek播放。

要想達(dá)到這種漸進(jìn)式播放的目的，大部分情況下，我們是要對服務(wù)端的媒體文件進(jìn)行一定的處理的。首先播放之前，服務(wù)端需要先返回一定的視頻元數(shù)據(jù)信息，其次我們需要知道媒體時間和媒體數(shù)據(jù)的映射關(guān)系。為什么呢？

目前大部分的視頻編碼都采用H264標(biāo)準(zhǔn)，而H264的不同視頻幀采用了不同的壓縮編碼方式，其中I幀的作用很大，其通常是每個?GOP（Group of Picture）的第一個幀，我們簡單點說，I幀依靠自身就可以解碼出完整圖像，而其后面幀的解碼則需要依賴I幀，這意味著什么？

是的，這決定了我們在拖拽播放的時候，播放器會seek到最近的I幀處，所以有時候會有一個現(xiàn)象，就是你拖到一個精確的時間點，但是播放器卻在另一個靠近的時間點開始播放，這就是因為那個時間點是I幀所在之處。?

播放器的seek播放通常是讓用戶選擇時間偏移，而服務(wù)端最終對文件的請求處理只能是字節(jié)偏移，所以問題來了，我們要有一個時間偏移和字節(jié)偏移的映射表，嚴(yán)格一點說，是每一個I幀的時間偏移與字節(jié)偏移映射。

問題又來了，這個映射是放在客戶端還是服務(wù)端處理呢？當(dāng)然是都可以。如果客戶端發(fā)出字節(jié)偏移請求，那么服務(wù)端就很輕松，只需要提供HTTP range訪問的功能，但是client端需要提前知道時間與字節(jié)的映射關(guān)系，比如flv格式的metadata就提供了這個信息，有的flv文件沒有加入metadata，這時候就需要用相應(yīng)的flv工具（比如flvmeta）去處理成這樣的格式，這樣客戶端的播放器就可以直接發(fā)送字節(jié)偏移量了。MP4則不需要這么處理，因為MP4格式本身就要求帶這樣的信息，其記錄metadata的Movie Box (moov)中的Media Information Box (minf)就存儲了媒體時間和媒體數(shù)據(jù)的映射關(guān)系。如果客戶端只發(fā)出時間請求，那么服務(wù)端就得將時間偏移請求轉(zhuǎn)換為字節(jié)偏移請求，然后處理并響應(yīng)請求。

——【特別推薦】——

這里藏著我給你的福利↓

總結(jié)

以上是生活随笔為你收集整理的HTTP流媒体播放技术发展以及nginx点播源站的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。