原文地址: https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41611.pdf
感想: 本文延續(xù)了谷歌一貫的發(fā)文作風(fēng), 先在產(chǎn)線(xiàn)上驗(yàn)證, 然后有效果后再發(fā)文章, 文中的所有機(jī)制在webrtc中都有, 但是實(shí)際在工程上的實(shí)現(xiàn)會(huì)有非常多的細(xì)節(jié), 在視頻的低延時(shí), 抗網(wǎng)損, 保質(zhì)量等方面都需要很多的考量和權(quán)衡. 以后會(huì)慢慢去梳理這些部分的邏輯, 分享給大家
摘要
WebRTC是一個(gè)開(kāi)源的實(shí)時(shí)交互式音頻和視頻通信框架。本文討論了WebRTC中用于處理視頻通信路徑中數(shù)據(jù)包丟失的一些機(jī)制。討論了各種系統(tǒng)細(xì)節(jié)，提出了一種基于時(shí)間層的自適應(yīng)混合NACK/FEC方法。結(jié)果顯示了該方法如何控制實(shí)時(shí)視頻通信的質(zhì)量權(quán)衡
介紹
WebRTC[1]是一個(gè)開(kāi)源項(xiàng)目，它使web瀏覽器能夠進(jìn)行實(shí)時(shí)音頻和視頻通信。
本文介紹了一些底層的視頻處理方面的WebRTC，使可靠的實(shí)時(shí)視頻傳輸在有損網(wǎng)絡(luò)中成為現(xiàn)實(shí)。眾所周知，為交互式實(shí)時(shí)應(yīng)用(如視頻會(huì)議)提供高用戶(hù)體驗(yàn)是很困難的。這些應(yīng)用受到突變的網(wǎng)絡(luò)條件(帶寬、丟包、網(wǎng)絡(luò)延遲)和低延遲實(shí)時(shí)編碼要求的限制。
存在各種方法[2]處理多媒體傳輸期間的分組丟失，例如基于否定確認(rèn)（NACK），前向糾錯(cuò)（FEC）[3] [4]和參考圖片選擇（RPS）[5]的分組重傳。 。 這些通常通過(guò)編解碼器的錯(cuò)誤恢復(fù)方法[2]進(jìn)行補(bǔ)充，例如內(nèi)部刷新和錯(cuò)誤隱藏。 對(duì)于具有嚴(yán)格延遲要求的實(shí)時(shí)應(yīng)用，可以使用混合NACK / FEC方案[6]來(lái)實(shí)現(xiàn)NACK方法的延遲成本和FEC方法的冗余成本之間的某種平衡。
本文介紹了WebRTC中當(dāng)前用于處理數(shù)據(jù)包丟失的一組保護(hù)工具。 尤其是，提出了一種具有時(shí)間層（TL）的自適應(yīng)混合NACK / FEC方法，作為一種平衡視頻質(zhì)量，渲染平滑度（播放抖動(dòng)）和端到端延遲的有用方案。 TL指WebRTC中使用的VP8 [7]編解碼器中的時(shí)間可伸縮性功能。 還討論了各種系統(tǒng)細(xì)節(jié)和組件，以突出我們方法的適應(yīng)性。
WebRTC中視頻處理的系統(tǒng)描述將在第2節(jié)中討論。第3節(jié)討論用于量化系統(tǒng)行為的仿真和度量。 3.1-3.3節(jié)包含有關(guān)混合NACK / FEC，F(xiàn)EC和TL的一些結(jié)果和討論。 結(jié)論見(jiàn)第4節(jié)。
系統(tǒng)描述
圖1顯示了WebRTC視頻處理系統(tǒng)圖。 進(jìn)入發(fā)送端的原始幀首先經(jīng)過(guò)預(yù)處理，然后以給定的目標(biāo)速率進(jìn)行編碼。 隨后，將幀打包，并且在適用時(shí)應(yīng)用FEC編碼器。 FEC是基于RFC 5109 [8]的XOR代碼。 在接收器端，打包的編碼數(shù)據(jù)由FEC解碼器處理，然后由抖動(dòng)緩沖器（JB）處理。 后者根據(jù)接收到的數(shù)據(jù)包構(gòu)造編碼幀，并估計(jì)視頻抖動(dòng)。 幀完成后，將其發(fā)送到解碼器，由解碼器輸出原始數(shù)據(jù)（YUV格式）。 JB還負(fù)責(zé)構(gòu)建作為重新傳輸請(qǐng)求基礎(chǔ)的丟失數(shù)據(jù)包列表。
我們將抖動(dòng)建模為包括兩個(gè)分量，一個(gè)是隨機(jī)分量，另一個(gè)是相對(duì)于視頻幀大小的分量[9]。 然后，我們收集幀捕獲時(shí)間和幀的接收時(shí)間的每幀統(tǒng)計(jì)信息，并將其建模為線(xiàn)性依賴(lài)于幀大小的差異。 這種估算抖動(dòng)的方法可以適應(yīng)幀大小和鏈接容量的變化，而這通常會(huì)影響視頻抖動(dòng)。 抖動(dòng)估計(jì)適用于由于FEC解碼而不是由于重傳而延遲的幀。
發(fā)送方的媒體優(yōu)化（MO）組件控制自適應(yīng)混合NACK / FEC。 MO定期接收網(wǎng)絡(luò)統(tǒng)計(jì)信息，并隨每個(gè)傳入的RTCP接收器報(bào)告（大約每秒）更新一次。 這些網(wǎng)絡(luò)統(tǒng)計(jì)信息包括可用帶寬，丟包率和往返時(shí)間（RTT）。 接收側(cè)帶寬估計(jì)器計(jì)算可用的網(wǎng)絡(luò)帶寬[9]。 MO還接收編碼器統(tǒng)計(jì)信息，例如傳入的幀速率和發(fā)送的實(shí)際比特率（視頻比特率和FEC / NACK保護(hù)開(kāi)銷(xiāo)率）。 MO關(guān)于混合NACK / FEC的主要功能是設(shè)置FEC保護(hù)量，并以新的源速率（可用帶寬減去估計(jì)的保護(hù)開(kāi)銷(xiāo)）更新編碼器。
系統(tǒng)行為和結(jié)果
我們采用了離線(xiàn)模擬工具對(duì)系統(tǒng)進(jìn)行了評(píng)估，該工具可以在受控環(huán)境中模擬各種網(wǎng)絡(luò)條件。 仿真工具充當(dāng)發(fā)送客戶(hù)端和接收客戶(hù)端之間的傳輸模塊，并且由一個(gè)通告網(wǎng)絡(luò)傳輸延遲的隊(duì)列組成。 數(shù)據(jù)包丟棄器放置在隊(duì)列之后，這可能造成使用GilbertElliot模型[10]從突發(fā)丟失模型得出的數(shù)據(jù)包丟失。 在以下結(jié)果中，僅將完整的VP8比特流提供給解碼器，因此對(duì)視頻進(jìn)行解碼時(shí)不會(huì)出現(xiàn)錯(cuò)誤/數(shù)據(jù)包丟失的情況，并且將接收器配置為等待所有必要的數(shù)據(jù)包。 因此，視頻質(zhì)量主要受回放的平滑度和可用比特率影響。
測(cè)量以下定義的以下性能指標(biāo)以表征系統(tǒng)的行為：
端到端延遲: 從文件讀取幀到在接收器將其呈現(xiàn)回文件之前所花費(fèi)的平均時(shí)間。
渲染標(biāo)準(zhǔn)偏差：渲染的兩個(gè)連續(xù)幀之間的時(shí)間增量的標(biāo)準(zhǔn)偏差。 為了獲得最佳的時(shí)間質(zhì)量，渲染增量應(yīng)接近捕獲的幀速率，且方差很小。
保護(hù)開(kāi)銷(xiāo)：定義為由于重傳和FEC而導(dǎo)致的平均開(kāi)銷(xiāo)百分比（相對(duì)于總比特率）。 這是所施加的視頻保護(hù)使壓縮視頻信號(hào)降級(jí)的量度。
下面報(bào)告的模擬結(jié)果是在會(huì)話(huà)(?)場(chǎng)景上進(jìn)行的，分辨率為640x360，分辨率為30 fps，動(dòng)作范圍為中低。 該序列長(zhǎng)約30秒，實(shí)驗(yàn)結(jié)果是多次運(yùn)行后取的平均值。
混合NACK/FEC
WebRTC使用自適應(yīng)混合NACK / FEC方法在時(shí)間質(zhì)量（渲染的平滑度），空間視頻質(zhì)量和端到端延遲之間獲得更好的折衷。 我們方法的自適應(yīng)方面是指發(fā)送方FEC量的動(dòng)態(tài)設(shè)置，以及接收方的播放延遲。
NACK / FEC混合方法的成本是FEC的開(kāi)銷(xiāo)損失，如圖2a所示。 除此之外，與僅NACK方法相比，它具有明顯的優(yōu)勢(shì)。 圖2b顯示，將NACK和FEC結(jié)合使用時(shí)，平均端到端延遲會(huì)減少，因?yàn)槠骄却貍鞯臅r(shí)間更少，盡管單個(gè)重傳的等待時(shí)間沒(méi)有改變。 如圖2c和d所示，渲染時(shí)間增量的標(biāo)準(zhǔn)偏差也顯著降低。
如第2節(jié)所述，在MO中根據(jù)接收到的網(wǎng)絡(luò)統(tǒng)計(jì)信息確定FEC量（保護(hù)級(jí)別）。 特別地，F(xiàn)EC的量取決于RTT。 當(dāng)RTT較低時(shí)，可以重發(fā)數(shù)據(jù)包而不會(huì)造成嚴(yán)重的凍結(jié)。 因此，F(xiàn)EC的數(shù)量可以減少，從而導(dǎo)致較小的延遲損失。 在大型RTT中，延遲對(duì)時(shí)間質(zhì)量的影響更大，因此不應(yīng)減少FEC的數(shù)量。 如圖2a所示，對(duì)于RTT / 2 <?50 ms，F(xiàn)EC開(kāi)銷(xiāo)減少了。
對(duì)于不同的d(add)值，取決于網(wǎng)絡(luò)傳輸延遲。 實(shí)線(xiàn)表示NACK，虛線(xiàn)表示混合NACK / FEC。 對(duì)于5％的數(shù)據(jù)包丟失率，突發(fā)長(zhǎng)度為1，為500kbps。 a）保護(hù)開(kāi)銷(xiāo)。 b）端到端延遲。 c）渲染標(biāo)準(zhǔn)偏差。 d）僅針對(duì)混合NACK / FEC渲染標(biāo)準(zhǔn)差
播放延遲是在JB中控制的，用于權(quán)衡時(shí)間質(zhì)量（渲染的平滑度）和端到端延遲。 目的是延遲回放，以減少在等待重發(fā)數(shù)據(jù)包時(shí)視頻被凍結(jié)的持續(xù)時(shí)間。 但是，當(dāng)RTT較大時(shí)，附加的播放延遲不太合適，因?yàn)閱蜗蜓舆t超過(guò)400 ms會(huì)嚴(yán)重?fù)p害通信[11]。 因此，應(yīng)根據(jù)不可恢復(fù)的丟包率u和估計(jì)的RTT選擇額外的播放延遲。 額外的播放延遲可以計(jì)算為
K是最大可接受的端到端延遲，RTT / 2是對(duì)網(wǎng)絡(luò)傳輸時(shí)間的估計(jì)，抖動(dòng)是估計(jì)的抖動(dòng)，Umin是數(shù)據(jù)包丟失的閾值。 與在合理的時(shí)間內(nèi)（例如十秒）計(jì)算的合理時(shí)間內(nèi)接收到的數(shù)據(jù)包數(shù)量相比，不可恢復(fù)的丟失的比例可以估計(jì)為NACK和不合理地延遲接收的數(shù)據(jù)包數(shù)量。 可以將不合理的延遲定義為至少比我們預(yù)期相關(guān)幀完成的時(shí)間晚RTT / 2。 在圖2b中可以看到增加的端到端延遲的成本，而在圖2c和2d中可以看到增加的回放延遲的收益。 圖2中的“自適應(yīng)”行對(duì)dadd使用上面的公式，其中K = 100 ms，Umin =0。其他行具有dadd = kRTT，其中k在{0，0.5，1}中。
多幀F(xiàn)EC
WebRTC中使用的FEC是XOR數(shù)據(jù)包級(jí)別的代碼[8]。 我們將代碼表示為（k，m），其中k是保護(hù)組中視頻數(shù)據(jù)包的數(shù)量，m是該保護(hù)組中FEC數(shù)據(jù)包的數(shù)量。 FEC的保護(hù)開(kāi)銷(xiāo)定義為PL = m /（k + m）。 保護(hù)組中使用的最大幀數(shù)λ也是代碼的特征。 此數(shù)字是在MO中根據(jù)接收到的網(wǎng)絡(luò)延遲和視頻幀速率來(lái)動(dòng)態(tài)確定的：λ?max（1，min（fRTT，λo）），其中f是幀速率，λo是固定上限。
多幀F(xiàn)EC可以降低低比特率的FEC開(kāi)銷(xiāo)，在這種情況下，一幀F(xiàn)EC的粒度非常?。疵繋倭康臄?shù)據(jù)包）。 多幀F(xiàn)EC的另一個(gè)特點(diǎn)是，它在恢復(fù)損失方面通常比1幀F(xiàn)EC更有效，尤其是對(duì)于突發(fā)損失。 也就是說(shuō)，給定兩個(gè)具有相似保護(hù)等級(jí)的代碼，較長(zhǎng)的代碼通常比較短的代碼具有較低的平均殘留損耗。 這是由于可以使用更長(zhǎng)的FEC代碼的生成器矩陣來(lái)恢復(fù)更多的損耗配置（參見(jiàn)圖3）。 然而，這種改善的恢復(fù)是以增加的FEC解碼延遲為代價(jià)的。
額外的開(kāi)銷(xiāo)閾值控制用于FEC的實(shí)際幀數(shù)。 多余的開(kāi)銷(xiāo)定義為實(shí)際開(kāi)銷(xiāo)（基于保護(hù)組中數(shù)據(jù)包的實(shí)際數(shù)量）減去目標(biāo)開(kāi)銷(xiāo)（由PL確定）。 因此，如果FEC生成器從MO接收到λ> 1，則FEC保護(hù)組中使用的實(shí)際幀數(shù)會(huì)增加（可能達(dá)到最大λ），直到多余的開(kāi)銷(xiāo)低于閾值。
圖4比較了1幀F(xiàn)EC和多幀F(xiàn)EC。 對(duì)于該比較，λ分別固定為1和6。 從圖4a和4b中可以看出，使用多幀F(xiàn)EC可以降低端到端延遲和渲染增量方差。 對(duì)于此損耗模擬，MO中設(shè)置的FEC保護(hù)級(jí)別應(yīng)使平均保護(hù)開(kāi)銷(xiāo)為?20/25％。 圖4c顯示了多幀F(xiàn)EC如何達(dá)到目標(biāo)保護(hù)開(kāi)銷(xiāo)，而1幀F(xiàn)EC過(guò)沖并因此產(chǎn)生了額外開(kāi)銷(xiāo)，特別是對(duì)于較低的比特率范圍（過(guò)多的開(kāi)銷(xiāo)在較高的比特率下減少，即，更多的數(shù)據(jù)包/幀） 。 在多幀情況下，較低的保護(hù)開(kāi)銷(xiāo)導(dǎo)致較高的PSNR /質(zhì)量。
每幀2個(gè)數(shù)據(jù)包，保護(hù)開(kāi)銷(xiāo)為33％的示例（FEC數(shù)據(jù)包跟隨其保護(hù)的源數(shù)據(jù)包）。 1幀F(xiàn)EC是每個(gè)幀中兩個(gè)源數(shù)據(jù)包的XOR，而3幀F(xiàn)EC具有上面所示的6x3生成器矩陣。 后者可以恢復(fù)更多的丟失配置，特別是使用（6,3）代碼可以完全恢復(fù)大小小于等于3的任何連續(xù)丟失。
結(jié)合Temporal Layers的混合NACK/FEC
上面討論的多幀F(xiàn)EC具有降低保護(hù)開(kāi)銷(xiāo)和改善對(duì)丟包率的恢復(fù)的潛力，但是當(dāng)RTT不明顯大于逆幀速率時(shí)，較長(zhǎng)的FEC解碼延遲會(huì)變得太昂貴。 混合NACK / FEC與分層編碼相結(jié)合，允許使用另一種機(jī)制來(lái)減少開(kāi)銷(xiāo)（例如，通過(guò)僅保護(hù)基本層幀），并提供了較低的端到端延遲與視頻質(zhì)量的附加折衷（較低的時(shí)空 解析度）。 在本文中，我們討論了如何結(jié)合混合NACK / FEC使用時(shí)間層（TL）。
VP8中的時(shí)間可伸縮性[7]能夠生成以速率為目標(biāo)的時(shí)間可分離流。 對(duì)于此處報(bào)告的結(jié)果，對(duì)于TL = 2，基礎(chǔ)層的速率分配為60％，對(duì)于TL = 3，基層的速率分配為40％（分別為2和3個(gè)時(shí)間層）。 時(shí)間模式結(jié)構(gòu)具有同步幀（每8幀放置一次），這些同步幀用于在接收器處啟用（不完整/丟失的）增強(qiáng)幀。
混合NACK / FEC + TL系統(tǒng)的操作如下：
UEP-FEC（不等錯(cuò)誤保護(hù)）用于僅對(duì)基礎(chǔ)層幀進(jìn)行保護(hù)的情況。 發(fā)送方僅重新傳輸屬于基礎(chǔ)層幀的數(shù)據(jù)包。
時(shí)間層ID和同步幀標(biāo)志嵌入每個(gè)數(shù)據(jù)包的編解碼器特定的RTP頭[12]中，并在接收器/抖動(dòng)緩沖器中提取.
完成了一種選擇性的NACKing，僅對(duì)與基礎(chǔ)層幀相對(duì)應(yīng)的丟失數(shù)據(jù)包進(jìn)行了NACK。 如果在增強(qiáng)層幀中檢測(cè)到丟失的數(shù)據(jù)包，則丟棄所有增強(qiáng)幀，直到接收到完整的同步幀。
圖5顯示了TL = 1、2、3的混合NACK / FEC的性能指標(biāo)。在這些比較中，F(xiàn)EC僅用在了最低層simulcast中。圖5a和5b顯示了較低的端到端延遲和渲染差異，以及圖5c中的較低保護(hù)開(kāi)銷(xiāo)方面的顯著收益。開(kāi)銷(xiāo)的減少是由于僅將FEC應(yīng)用于基本層幀。開(kāi)銷(xiāo)減少大致對(duì)應(yīng)于基礎(chǔ)層比特率：對(duì)于TL = 2，約為60％，對(duì)于TL = 3，約為40％。
使用TL的權(quán)衡有兩個(gè)組成部分：（1）在沒(méi)有丟包的情況下的壓縮效率損失（編解碼器損失），以及（2）在渲染的視頻中較低的時(shí)間分辨率（來(lái)自接收器丟失的增強(qiáng)幀）。掉落的增強(qiáng)幀造成的視覺(jué)質(zhì)量損失很難量化。關(guān)于TL> 1的編解碼器損失，至少在開(kāi)銷(xiāo)相對(duì)較高的情況下，我們可以預(yù)期，減少的FEC開(kāi)銷(xiāo)所帶來(lái)的收益將彌補(bǔ)壓縮效率的損失。這在圖6中提出，圖6顯示了時(shí)間層下的編解碼器損失。
圖中指示了兩組點(diǎn)：一組為?600kbps，另一組為降低的比特率，對(duì)應(yīng)于TL = 1時(shí)的保護(hù)開(kāi)銷(xiāo)為?33％，?（33 * 0.6）％，?（33 * 0.4）％ ，2、3。 33％是圖5c中TL = 1的示例開(kāi)銷(xiāo)（?600 / 700kbps）。
總結(jié)和展望未來(lái)
在本文中，我們介紹了用于處理WebRTC中數(shù)據(jù)包丟失的視頻處理工具的某些方面。性能指標(biāo)用于量化丟包和延遲對(duì)網(wǎng)絡(luò)的影響。提出了一種與TL相結(jié)合的自適應(yīng)混合NACK / FEC方法，以控制整體視頻質(zhì)量，播放抖動(dòng)和端到端延遲。尤其討論了自適應(yīng)播放延遲作為權(quán)衡渲染抖動(dòng)和延遲的一種機(jī)制，并提出了兩種方法（多幀F(xiàn)EC和TL）來(lái)降低保護(hù)開(kāi)銷(xiāo)成本。當(dāng)考慮突發(fā)損失情況和相對(duì)較長(zhǎng)的RTT時(shí)，結(jié)果表明這兩種方法都有可能改善所有三個(gè)系統(tǒng)指標(biāo)：更低的渲染抖動(dòng)，更低的端到端延遲以及更高或類(lèi)似的（空間）視頻質(zhì)量/ PSNR。可以從各種擴(kuò)展中獲得改進(jìn)的性能，例如跨時(shí)間層更好地使用選擇性NACKing，多幀F(xiàn)EC和UEP-FEC。這項(xiàng)工作的擴(kuò)展還包括改進(jìn)指標(biāo)，以包括例如更好的抖動(dòng)適應(yīng)程度[13]。
參考文檔
[1] http://www.webrtc.org/ ; http://code.google.com/p/webrtc/
[2] Y. Wang, S. Wenger, J.T. Wen, A.K. Katsaggelos, “Review of Error Resilient Coding Techniques for RealTime Video Communications,” IEEE Signal Proc. Magazine, vol. 17, no. 4, pp. 61-82, Jul. 2000.
[3] J, Korhonen, P. Frossard, “Flexible forward error correction codes with application to partial media data recovery”, Signal Processing: Image Communication 24, (2009), 229-242.
[4] F. Battisti, M. Carli, E. Mammi, and A. Neri, "A study on the impact of AL-FEC techniques on TV over IP Quality of Experience", EURASIP Journal on Advances in Signal Processing, 2011.
[5] S. Fukunaga, T. Nakai, and H. Inoue, “Error Resilient Video Coding by Dynamic Replacing of Reference Pictures”, Proceedings of IEEE Global Telecommunications Conf. (GLOBECOM), London, vol. 3, Nov. 1996, pp.1503– 1508.
[6] F. Zhai, Y. Eisenberg, T. N. Pappas, R. Berry and A. K. Katsaggelos, “Rate distortion optimized hybrid error control for real-time packetized video transmission,” IEEE Transactions on Image Processing, pp. 40-53, 2006.
[7] http://www.webmproject.org/; J. Bankoski, P. Wilkins and Y. Xu, “VP8 Data Format and Decoding Guide,” RFC6386 (Informational), Nov. 2011.
[8] Li, A., “RTP Payload Format for Generic Forward Error Correction,” RFC 5109 (Proposed Standard), Dec. 2007.
[9] H. Lundin, S. Holmer and H. Alvestrand, “A Google Congestion Control Algorithm for RealTime Communication on the World Wide Web,” IETF Informational Draft, April 2012.
[10] P. Ferre, D. Agrafiotis, T-K Chiew, A. Doufexi, A.R. Nix, D.R Bull, “Packet Loss Modelling for H.264 Video Transmission over IEEE 802.11g Wireless LANs”, in WIAMIS 2005.
[11] ITU-T G.114, February 1996.
[12] P. Westin, H. Lundin, M. Glover, J. Uberti and F. Galligan “RTP Payload Format for VP8 Video,” IETF Internet Draft, Jan 2013.
[13] S. Borer, “A model of jerkiness for temporal impairments in video transmission,” in Proc. Int. Workshop Quality Multimedia Exper. (QoMEX), Jun. 2010, pp. 218– 223.
