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

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

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

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

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

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

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

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

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

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

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

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

一、視頻編碼那些事

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

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

1.1 H.264 編碼

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

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

1.2 馬賽克、卡頓和秒開(kāi)

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

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

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

1.3 編碼延遲與碼率

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

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

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

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

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

2.1 TCP 和 UDP

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

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

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

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

http://weibo.com/p/1001603821691477346388

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

2.2 延遲

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

發(fā)送端方一個(gè)帶本地時(shí)間戳 T1 的 ping 報(bào)文到接收端；

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

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

示意圖如下：

欲知詳情，請(qǐng)下載word文檔 下載文檔