原文地址: https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41611.pdf
感想: 本文延續(xù)了谷歌一貫的發(fā)文作風(fēng), 先在產(chǎn)線上驗(yàn)證, 然后有效果后再發(fā)文章, 文中的所有機(jī)制在webrtc中都有, 但是實(shí)際在工程上的實(shí)現(xiàn)會(huì)有非常多的細(xì)節(jié), 在視頻的低延時(shí), 抗網(wǎng)損, 保質(zhì)量等方面都需要很多的考量和權(quán)衡. 以后會(huì)慢慢去梳理這些部分的邏輯, 分享給大家
摘要
WebRTC是一個(gè)開源的實(shí)時(shí)交互式音頻和視頻通信框架雏门。本文討論了WebRTC中用于處理視頻通信路徑中數(shù)據(jù)包丟失的一些機(jī)制征冷。討論了各種系統(tǒng)細(xì)節(jié)，提出了一種基于時(shí)間層的自適應(yīng)混合NACK/FEC方法齐唆。結(jié)果顯示了該方法如何控制實(shí)時(shí)視頻通信的質(zhì)量權(quán)衡
介紹
WebRTC[1]是一個(gè)開源項(xiàng)目壁查，它使web瀏覽器能夠進(jìn)行實(shí)時(shí)音頻和視頻通信球切。
本文介紹了一些底層的視頻處理方面的WebRTC缰盏，使可靠的實(shí)時(shí)視頻傳輸在有損網(wǎng)絡(luò)中成為現(xiàn)實(shí)。眾所周知酷窥，為交互式實(shí)時(shí)應(yīng)用(如視頻會(huì)議)提供高用戶體驗(yàn)是很困難的。這些應(yīng)用受到突變的網(wǎng)絡(luò)條件(帶寬伴网、丟包蓬推、網(wǎng)絡(luò)延遲)和低延遲實(shí)時(shí)編碼要求的限制。
存在各種方法[2]處理多媒體傳輸期間的分組丟失澡腾，例如基于否定確認(rèn)（NACK）沸伏，前向糾錯(cuò)（FEC）[3] [4]和參考圖片選擇（RPS）[5]的分組重傳。 动分。 這些通常通過編解碼器的錯(cuò)誤恢復(fù)方法[2]進(jìn)行補(bǔ)充毅糟，例如內(nèi)部刷新和錯(cuò)誤隱藏。 對(duì)于具有嚴(yán)格延遲要求的實(shí)時(shí)應(yīng)用刺啦，可以使用混合NACK / FEC方案[6]來實(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é)論見第4節(jié)。
系統(tǒng)描述
圖1顯示了WebRTC視頻處理系統(tǒng)圖殷绍。 進(jìn)入發(fā)送端的原始幀首先經(jīng)過預(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ì)信息，并將其建模為線性依賴于幀大小的差異郑兴。 這種估算抖動(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ù)開銷率）。 MO關(guān)于混合NACK / FEC的主要功能是設(shè)置FEC保護(hù)量螃诅，并以新的源速率（可用帶寬減去估計(jì)的保護(hù)開銷）更新編碼器啡氢。
系統(tǒng)行為和結(jié)果
我們采用了離線模擬工具對(duì)系統(tǒng)進(jìn)行了評(píng)估，該工具可以在受控環(huán)境中模擬各種網(wǎng)絡(luò)條件术裸。 仿真工具充當(dāng)發(fā)送客戶端和接收客戶端之間的傳輸模塊倘是，并且由一個(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ù)開銷：定義為由于重傳和FEC而導(dǎo)致的平均開銷百分比（相對(duì)于總比特率）锦茁。 這是所施加的視頻保護(hù)使壓縮視頻信號(hào)降級(jí)的量度攘轩。
下面報(bào)告的模擬結(jié)果是在會(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的開銷損失袖迎，如圖2a所示冕臭。 除此之外，與僅NACK方法相比燕锥，它具有明顯的優(yōu)勢(shì)辜贵。 圖2b顯示，將NACK和FEC結(jié)合使用時(shí)脯宿，平均端到端延遲會(huì)減少念颈，因?yàn)槠骄却貍鞯臅r(shí)間更少，盡管單個(gè)重傳的等待時(shí)間沒有改變连霉。 如圖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開銷減少了戈鲁。
對(duì)于不同的d(add)值，取決于網(wǎng)絡(luò)傳輸延遲嘹叫。 實(shí)線表示NACK婆殿，虛線表示混合NACK / FEC。 對(duì)于5％的數(shù)據(jù)包丟失率罩扇，突發(fā)長(zhǎng)度為1婆芦，為500kbps。 a）保護(hù)開銷喂饥。 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超過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ù)開銷定義為PL = m /（k + m）凭峡。 保護(hù)組中使用的最大幀數(shù)λ也是代碼的特征。 此數(shù)字是在MO中根據(jù)接收到的網(wǎng)絡(luò)延遲和視頻幀速率來動(dòng)態(tài)確定的：λ?max（1决记，min（fRTT摧冀，λo）），其中f是幀速率系宫，λo是固定上限索昂。
多幀F(xiàn)EC可以降低低比特率的FEC開銷，在這種情況下扩借，一幀F(xiàn)EC的粒度非常薪凡摇（即每幀少量的數(shù)據(jù)包）。 多幀F(xiàn)EC的另一個(gè)特點(diǎn)是潮罪，它在恢復(fù)損失方面通常比1幀F(xiàn)EC更有效康谆，尤其是對(duì)于突發(fā)損失。 也就是說嫉到，給定兩個(gè)具有相似保護(hù)等級(jí)的代碼沃暗，較長(zhǎng)的代碼通常比較短的代碼具有較低的平均殘留損耗。 這是由于可以使用更長(zhǎng)的FEC代碼的生成器矩陣來恢復(fù)更多的損耗配置（參見圖3）何恶。 然而孽锥，這種改善的恢復(fù)是以增加的FEC解碼延遲為代價(jià)的。
額外的開銷閾值控制用于FEC的實(shí)際幀數(shù)细层。 多余的開銷定義為實(shí)際開銷（基于保護(hù)組中數(shù)據(jù)包的實(shí)際數(shù)量）減去目標(biāo)開銷（由PL確定）惜辑。 因此，如果FEC生成器從MO接收到λ> 1疫赎，則FEC保護(hù)組中使用的實(shí)際幀數(shù)會(huì)增加（可能達(dá)到最大λ）韵丑，直到多余的開銷低于閾值。
圖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ù)開銷為?20/25％创坞。 圖4c顯示了多幀F(xiàn)EC如何達(dá)到目標(biāo)保護(hù)開銷碗短，而1幀F(xiàn)EC過沖并因此產(chǎn)生了額外開銷，特別是對(duì)于較低的比特率范圍（過多的開銷在較高的比特率下減少题涨，即偎谁，更多的數(shù)據(jù)包/幀） 总滩。 在多幀情況下，較低的保護(hù)開銷導(dǎo)致較高的PSNR /質(zhì)量巡雨。
每幀2個(gè)數(shù)據(jù)包闰渔，保護(hù)開銷為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ù)開銷和改善對(duì)丟包率的恢復(fù)的潛力虱痕，但是當(dāng)RTT不明顯大于逆幀速率時(shí)，較長(zhǎng)的FEC解碼延遲會(huì)變得太昂貴辐赞。 混合NACK / FEC與分層編碼相結(jié)合部翘，允許使用另一種機(jī)制來減少開銷（例如，通過僅保護(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ù)開銷方面的顯著收益苫费。開銷的減少是由于僅將FEC應(yīng)用于基本層幀。開銷減少大致對(duì)應(yīng)于基礎(chǔ)層比特率：對(duì)于TL = 2双抽，約為60％百框，對(duì)于TL = 3，約為40％牍汹。
使用TL的權(quán)衡有兩個(gè)組成部分：（1）在沒有丟包的情況下的壓縮效率損失（編解碼器損失）铐维，以及（2）在渲染的視頻中較低的時(shí)間分辨率（來自接收器丟失的增強(qiáng)幀）。掉落的增強(qiáng)幀造成的視覺質(zhì)量損失很難量化慎菲。關(guān)于TL> 1的編解碼器損失嫁蛇，至少在開銷相對(duì)較高的情況下，我們可以預(yù)期露该，減少的FEC開銷所帶來的收益將彌補(bǔ)壓縮效率的損失睬棚。這在圖6中提出，圖6顯示了時(shí)間層下的編解碼器損失解幼。
圖中指示了兩組點(diǎn)：一組為?600kbps抑党，另一組為降低的比特率，對(duì)應(yīng)于TL = 1時(shí)的保護(hù)開銷為?33％撵摆，?（33 * 0.6）％底靠，?（33 * 0.4）％ ，2特铝、3暑中。 33％是圖5c中TL = 1的示例開銷（?600 / 700kbps）。
總結(jié)和展望未來
在本文中鲫剿，我們介紹了用于處理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）來降低保護(hù)開銷成本请琳。當(dāng)考慮突發(fā)損失情況和相對(duì)較長(zhǎng)的RTT時(shí)粱挡，結(jié)果表明這兩種方法都有可能改善所有三個(gè)系統(tǒng)指標(biāo)：更低的渲染抖動(dòng)，更低的端到端延遲以及更高或類似的（空間）視頻質(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.
