如何實(shí)現(xiàn)1080P延遲低于500ms的實(shí)時超清直播傳輸技術(shù)

最近由于公司業(yè)務(wù)關(guān)系，需要一個在公網(wǎng)上能實(shí)時互動超清視頻的架構(gòu)和技術(shù)方案。眾所周知，視頻直播用 CDN + RTMP 就可以滿足絕大部分視頻直播業(yè)務(wù)，我們也接觸了和測試了幾家 CDN 提供的方案，單人直播沒有問題，一旦涉及到多人互動延遲非常大，無法進(jìn)行正常的互動交談。對于我們做在線教育的企業(yè)來說沒有互動的直播是毫無意義的，所以我們決定自己來構(gòu)建一個超清晰（1080P）實(shí)時視頻的傳輸方案。

先來解釋下什么是實(shí)時視頻，實(shí)時視頻就是視頻圖像從產(chǎn)生到消費(fèi)完成整個過程人感覺不到延遲，只要符合這個要求的視頻業(yè)務(wù)都可以稱為實(shí)時視頻。關(guān)于視頻的實(shí)時性歸納為三個等級：

偽實(shí)時：視頻消費(fèi)延遲超過 3 秒，單向觀看實(shí)時，通用架構(gòu)是 CDN + RTMP + HLS，現(xiàn)在基本上所有的直播都是這類技術(shù)。

準(zhǔn)實(shí)時： 視頻消費(fèi)延遲 1 ~ 3 秒，能進(jìn)行雙方互動但互動有障礙。有些直播網(wǎng)站通過 TCP/UDP + FLV 已經(jīng)實(shí)現(xiàn)了這類技術(shù)，YY 直播屬于這類技術(shù)。

真實(shí)時：視頻消費(fèi)延遲 < 1秒，平均 500 毫秒。這類技術(shù)是真正的實(shí)時技術(shù)，人和人交談沒有明顯延遲感。QQ、微信、Skype 和 WebRTC 等都已經(jīng)實(shí)現(xiàn)了這類技術(shù)。

市面上大部分真實(shí)時視頻都是 480P 或者 480P 以下的實(shí)時傳輸方案，用于在線教育和線上教學(xué)有一定困難，而且有時候流暢度是個很大的問題。在實(shí)現(xiàn)超清晰實(shí)時視頻我們做了大量嘗試性的研究和探索，在這里會把大部分細(xì)節(jié)分享出來。

要實(shí)時就要縮短延遲，要縮短延遲就要知道延遲是怎么產(chǎn)生的，視頻從產(chǎn)生、編碼、傳輸?shù)阶詈蟛シ畔M(fèi)，各個環(huán)節(jié)都會產(chǎn)生延遲，總體歸納為下圖：

（點(diǎn)擊圖片可以全屏縮放）

成像延遲，一般的技術(shù)是毫無為力的，涉及到 CCD 相關(guān)的硬件，現(xiàn)在市面上最好的CCD，一秒鐘 50 幀，成像延遲也在 20 毫秒左右，一般的CCD只有 20 ~ 25 幀左右，成像延遲 40 ~ 50 毫秒。

編碼延遲，和編碼器有關(guān)系，在接下來的小結(jié)介紹，一般優(yōu)化的空間比較小。

我們著重針對網(wǎng)絡(luò)延遲和播放緩沖延遲來進(jìn)行設(shè)計(jì)，在介紹整個技術(shù)細(xì)節(jié)之前先來了解下視頻編碼和網(wǎng)絡(luò)傳輸相關(guān)的知識和特點(diǎn)。

一、視頻編碼那些事

我們知道從CCD采集到的圖像格式一般的 RGB 格式的（BMP），這種格式的存儲空間非常大，它是用三個字節(jié)描述一個像素的顏色值，如果是 1080P 分辨率的圖像空間：1920 x 1080 x 3 = 6MB，就算轉(zhuǎn)換成 JPG 也有近 200KB，如果是每秒 12 幀用 JPG 也需要近 2.4MB/S 的帶寬，這帶寬在公網(wǎng)上傳輸是無法接受的。

視頻編碼器就是為了解決這個問題的，它會根據(jù)前后圖像的變化做運(yùn)動檢測，通過各種壓縮把變化的發(fā)送到對方，1080P 進(jìn)行過 H.264編碼后帶寬也就在 200KB/S ~ 300KB/S 左右。在我們的技術(shù)方案里面我們采用 H.264 作為默認(rèn)編碼器（也在研究 H.265）。

1.1 H.264 編碼

前面提到視頻編碼器會根據(jù)圖像的前后變化進(jìn)行選擇性壓縮，因?yàn)閯傞_始接收端是沒有收到任何圖像，那么編碼器在開始壓縮的視頻時需要做個全量壓縮，這個全量壓縮在 H.264 中 I 幀，后面的視頻圖像根據(jù)這個I幀來做增量壓縮，這些增量壓縮幀叫做 P 幀，H.264 為了防止丟包和減小帶寬還引入一種雙向預(yù)測編碼的 B 幀，B 幀以前面的 I 或 P 幀和后面的 P 幀為參考幀。H.264 為了防止中間 P 幀丟失視頻圖像會一直錯誤它引入分組序列（GOP）編碼，也就是隔一段時間發(fā)一個全量 I 幀，上一個 I 幀與下一個 I 幀之間為一個分組 GOP。它們之間的關(guān)系如下圖：

PS：在實(shí)時視頻當(dāng)中最好不要加入 B 幀，因?yàn)?B 幀是雙向預(yù)測，需要根據(jù)后面的視頻幀來編碼，這會增大編解碼延遲。

1.2 馬賽克、卡頓和秒開

前面提到如果 GOP 分組中的P幀丟失會造成解碼端的圖像發(fā)生錯誤,其實(shí)這個錯誤表現(xiàn)出來的就是馬賽克。因?yàn)橹虚g連續(xù)的運(yùn)動信息丟失了，H.264 在解碼的時候會根據(jù)前面的參考幀來補(bǔ)齊，但是補(bǔ)齊的并不是真正的運(yùn)動變化后的數(shù)據(jù)，這樣就會出現(xiàn)顏色色差的問題，這就是所謂的馬賽克現(xiàn)象，如圖：

這種現(xiàn)象不是我們想看到的。為了避免這類問題的發(fā)生，一般如果發(fā)現(xiàn) P 幀或者 I 幀丟失，就不顯示本 GOP 內(nèi)的所有幀，直到下一個 I 幀來后重新刷新圖像。但是 I 幀是按照幀周期來的，需要一個比較長的時間周期，如果在下一個 I 幀來之前不顯示后來的圖像，那么視頻就靜止不動了，這就是出現(xiàn)了所謂的卡頓現(xiàn)象。如果連續(xù)丟失的視頻幀太多造成解碼器無幀可解，也會造成嚴(yán)重的卡頓現(xiàn)象。視頻解碼端的卡頓現(xiàn)象和馬賽克現(xiàn)象都是因?yàn)閬G幀引起的，最好的辦法就是讓幀盡量不丟。

知道 H.264 的原理和分組編碼技術(shù)后所謂的秒開技術(shù)就比較簡單了，只要發(fā)送方從最近一個 GOP 的 I 幀開發(fā)發(fā)送給接收方，接收方就可以正常解碼完成的圖像并立即顯示。但這會在視頻連接開始的時候多發(fā)一些幀數(shù)據(jù)造成播放延遲，只要在接收端播放的時候盡量讓過期的幀數(shù)據(jù)只解碼不顯示，直到當(dāng)前視頻幀在播放時間范圍之內(nèi)即可。

1.3 編碼延遲與碼率

前面四個延遲里面我們提到了編碼延遲，編碼延遲就是從CCD出來的 RGB 數(shù)據(jù)經(jīng)過 H.264 編碼器編碼后出來的幀數(shù)據(jù)過程的時間。我們在一個 8 核 CPU 的普通客戶機(jī)測試了最新版本 X.264 的各個分辨率的延遲，數(shù)據(jù)如下：

從上面可以看出，超清視頻的編碼延遲會達(dá)到 50ms，解決編碼延遲的問題只能去優(yōu)化編碼器內(nèi)核讓編碼的運(yùn)算更快，我們也正在進(jìn)行方面的工作。

在 1080P 分辨率下，視頻編碼碼率會達(dá)到 300KB/S，單個 I 幀數(shù)據(jù)大小達(dá)到 80KB，單個 P 幀可以達(dá)到 30KB，這對網(wǎng)絡(luò)實(shí)時傳輸造成嚴(yán)峻的挑戰(zhàn)。

二、網(wǎng)絡(luò)傳輸質(zhì)量因素

實(shí)時互動視頻一個關(guān)鍵的環(huán)節(jié)就是網(wǎng)絡(luò)傳輸技術(shù),不管是早期 VoIP，還是現(xiàn)階段流行的視頻直播，其主要手段是通過 TCP/IP 協(xié)議來進(jìn)行通信。但是 IP 網(wǎng)絡(luò)本來就是不可靠的傳輸網(wǎng)絡(luò)，在這樣的網(wǎng)絡(luò)傳輸視頻很容易造成卡頓現(xiàn)象和延遲。先來看看 IP 網(wǎng)絡(luò)傳輸?shù)膸讉€影響網(wǎng)絡(luò)傳輸質(zhì)量關(guān)鍵因素。

2.1 TCP 和 UDP

對直播有過了解的人都會認(rèn)為做視頻傳輸首選的就是 TCP + RTMP，其實(shí)這是比較片面的。在大規(guī)模實(shí)時多媒體傳輸網(wǎng)絡(luò)中，TCP 和 RTMP 都不占優(yōu)勢。TCP 是個擁塞公平傳輸?shù)膮f(xié)議，它的擁塞控制都是為了保證網(wǎng)絡(luò)的公平性而不是快速到達(dá)，我們知道，TCP 層只有順序到對應(yīng)的報文才會提示應(yīng)用層讀數(shù)據(jù)，如果中間有報文亂序或者丟包都會在TCP做等待，所以TCP的發(fā)送窗口緩沖和重發(fā)機(jī)制在網(wǎng)絡(luò)不穩(wěn)定的情況下會造成延遲不可控，而且傳輸鏈路層級越多延遲會越大。

關(guān)于TCP的原理：

http://coolshell.cn/articles/11564.html

關(guān)于TCP重發(fā)延遲：

http://weibo.com/p/1001603821691477346388

在實(shí)時傳輸中使用 UDP 更加合理，UDP 避免了TCP繁重的三次握手、四次揮手和各種繁雜的傳輸特性，只需要在 UDP 上做一層簡單的鏈路 QoS 監(jiān)測和報文重發(fā)機(jī)制，實(shí)時性會比TCP好，這一點(diǎn)從 RTP 和 DDCP 協(xié)議可以證明這一點(diǎn)，我們正式參考了這兩個協(xié)議來設(shè)計(jì)自己的通信協(xié)議。

2.2 延遲

要評估一個網(wǎng)絡(luò)通信質(zhì)量的好壞和延遲一個重要的因素就是 Round-Trip Time（網(wǎng)絡(luò)往返延遲）,也就是 RTT。評估兩端之間的 RTT 方法很簡單，大致如下：

發(fā)送端方一個帶本地時間戳 T1 的 ping 報文到接收端；

接收端收到 ping 報文，以 ping 中的時間戳 T1 構(gòu)建一個攜帶 T1 的 pong 報文發(fā)往發(fā)送端；

發(fā)送端接收到接收端發(fā)了的 pong 時，獲取本地的時間戳 T2，用 T2 – T1 就是本次評測的 RTT。

示意圖如下：

欲知詳情，請下載word文檔 下載文檔