實現視頻和音頻的零延遲是標準的零和博弈

 

做爲實時音視頻行業，咱們對爲何不能零延遲推送視頻提出不少理由，其中主要集中在網絡容量或間歇性，擴展低延遲解決方案的成本，甚至侷限性的現成處理器實時處理4K Ultra HD或高動態範圍（HDR）內容方面。本文將從根本上分析涉及編解碼器自己以及圍繞可伸縮流視頻出現的打包和分段問題。

文 / Tim Siglin

譯 / 屈健寧

原文/ https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Achieving-Zero-Latency-for-Video-and-Audio-Is-a-Zero-Sum-Game-134201.aspx

咱們對於爲何視頻不能及時、以未壓縮的質量交付作出了不少解釋。其中許多解釋都是合理的，這些問題主要集中在網絡容量或間歇性、擴展低延遲解決方案的成本、甚至侷限性的現成處理器實時處理4K Ultra HD或者高動態範圍（HDR）內容方面。

可是從根本上講，這個問題比任何一個問題都要深刻，涉及編解碼器自己以及圍繞可伸縮流視頻出現的打包和分段問題，這二者都會增長固有的延遲。自HDS，HLS甚至DASH問世以來，咱們中的一些人一直在抱怨這些延遲。向OTT實時流傳輸的轉移已將這些延遲或同步性推到了最前沿，正如一位行業同事在StreamingMedia East 2019上提到的那樣，這種延遲是同步的。

爲了更好地解決流媒體的延遲問題，讓咱們使用這篇文章來探索提供視頻和音頻的方法，這些視頻和音頻絕對、確定地必須在如今就存在(套用曾經流行的聯邦快遞(FederalExpress)口號)。

這不是一個理論上的練習，而是能夠在InfoComm等貿易展覽會上的對話中獲得證實的方法，企業正在尋求在本地（經過使用圖像放大或IMAG）提供音視頻內容同時還能夠遠程運做（跨校園或遠程學習學生）的無延遲解決方案。

這些受教育程度高的用戶，因爲操做的複雜性和成本效益的緣由，不想部署兩種解決方案。這兩種方案裏，一種是本地交付的零延遲解決方案，另外一種是很是低延遲的解決方案—用於遠程用戶，但願演示者和其本地受衆進行交互。

編解碼器能夠挽救這個問題嗎？

在零延遲本地交付用例中，標準的分段打包流式傳輸方法很是失敗，但問題早在打包步驟以前就出現了，而且問題就出如今了音視頻流式傳輸的核心：編碼器。不過，這不只是編碼器的問題，由於隨着時間的流逝，其中許多問題已經被優化併爲咱們的行業標準編解碼器帶來進一步提高。問題的主要部分在於編解碼器自己，以及零延遲編碼和傳送的整體缺陷。

有關實時流編碼和交付的討論一般包括經典的三足凳插圖，或者本文的受訪者將其所稱的決策的「編解碼器三角形」。爲了使流解決方案正常工做，三個「分支」或三角形「邊」必須保持平衡。這三個方面分別是速度，質量和帶寬。有些人用「成本」一詞代替「帶寬」，但都強調一個事實，即帶寬越高，消費者和公司的成本就越高。

大規模流傳輸以節省帶寬爲前提。這樣，對於點播內容，重點則放在速度和質量的交集上以保留帶寬。爲了在最低帶寬下得到最佳質量，視頻點播編碼器能夠花費更多的時間（例如，花費2個小時來編碼1個小時的視頻文件）以建立高完成度的產品，爲給定編解碼器施加相應帶寬以使其達到最佳性能。

 

質量，延遲和帶寬的競爭需求在此編解碼器三角形中獲得了說明。雖然HEVC下降了對帶寬的需求，但這是以質量和延遲爲代價的，所以大多數零幀延遲解決方案都選擇了更高帶寬的幀內（I幀）選項，例如基於標準的Motion JPEG或內部專用的壓縮編解碼器SDVoE。（圖片由SDVoE Alliance提供。）

爲了在有限的帶寬上實現保證質量的要求，流媒體行業大量地使用幀間壓縮，具體爲將一組圖片（GoP）彙集在一塊兒並跨時間壓縮，而後僅對GoP中相鄰圖像之間的差別進行編碼。這些少於總數的圖像幀稱爲P或B幀；每一個GoP中的初始幀稱爲關鍵幀或I幀。

幾乎全部幀間壓縮解決方案，包括H.264（AVC）和H.265（HEVC），都使用IPB方法，在節省帶寬方面，其效果使人印象深入。與僅使用I幀的方法相比，在許多狀況下，使用P和B幀，在30-60幀的單個GoP中能夠看到多達70％的聚合帶寬節省。

然而，對於實時流傳輸，使用P和B幀可能會致使嚴重中斷。回到三足凳，重點轉移到了及時編碼和交付之上。而且在實時流場景中，速度是最相當重要的，而質量和帶寬是次要的。

實際上，爲了在零延遲下實現真正的實時編碼（咱們稍後再定義），計時窗口很是短：以60fps（例如1080p60或4K60）在相機上拍攝的實時內容須要一幀每0.016秒或每16毫秒（ms）壓縮並傳送一次。

甚至還不是所有：雖然必須每16毫秒顯示一幀，但傳輸過程和打包過程同樣，也須要一些時間才能將編碼的視頻移動到以太網數據包中以便經過IP網絡進行傳輸。這意味着，若是要以零延遲傳送視頻，則一般必須在傳送時間的一半內（即，在8毫秒範圍內）對視頻幀進行編碼。

這個問題讓咱們想起了幀間流視頻的致命弱點：P和B幀。因爲編碼器須要比較GoP中的多個幀以節省帶寬，所以使用這些P或B幀會固有地增長額外的延遲。

那麼，如何解決速度，質量和帶寬（成本）之間的平衡？考慮一下多是什麼，讓咱們首先研究一個可能須要零延遲的典型用例。

「零延遲」

在現實環境中，任何等待時間都足以引發視覺不適。在某些狀況下，咱們可能都遇到了視覺上的不適，並且在這種狀況下，演示者可能就在觀衆面前，而且被投影到同一房間的大屏幕上。

若是演示者舉起手，而且編碼器甚至須要十幾個或更多額外的幀來進行編碼，結果將是她的動做與投影屏幕上出現的信號之間出現兩次一秒的延遲。

更糟糕的是，若是演示者使用的是投影到大屏幕上的計算機，那麼若是演示者嘗試在大屏幕上使用計算機鼠標進行交互時，可能會致使大約三幀的延遲時間從而讓觀衆出現視覺不適。

所以，既然這會讓本地觀衆和演示者都感到不適，那麼爲何要使用徹底壓縮呢？

在過去的十年中，這是視聽（AV）行業提出的論點，由於它試圖達到一種技術進步的水平，從而能夠在IP上以零延遲發送視頻信號。零延遲的需求也是致使安裝在大型演講廳，運動場和音樂場所中的幾乎全部IMAG解決方案仍主要在非打包的點對點解決方案上運行的緣由。

AV行業和流媒體行業都使用術語「延遲」來描述延遲。可是，在流媒體行業使用「低延遲」或「超低延遲」分別描述長達5秒的延遲和長達1秒的延遲的狀況下，視音頻行業開始大膽地斷言：零延遲。

 

IP上的AV-over解決方案（例如SDVoE）容許同步視頻數據的多播傳輸，咱們能夠將其與基於硬件的窗口和縮放單元結合使用，以在多個同類HDTV之間建立單個大視頻圖像的效果。與傳統的視頻牆縮放不一樣，AV-over-IP解決方案除了端點縮放器外，不須要昂貴的矩陣開關。（圖片由SDVoEAlliance提供。）

在某些方面，這種「零延遲」參考源於必要性，由於多輸入，多輸出視頻開關（雖然有點相似於老式電話總機，但被稱爲矩陣開關）可以傳遞矩陣。在多達128個同時輸出的配置中，一個或多個輸出的輸入的延遲時間小於1ms。

切換開關

這些點對點解決方案在1990年代首次起做用的方式是使用五線RGBHV電纜，這種五線電纜分別提供三種顏色（紅色，綠色，藍色）和兩種類型的圖像同步（水平和垂直同步）。可是電纜很貴（每英尺幾美金），並且終端是很笨重的BNC鏈接器。即便是一個簡單的16輸入，16輸出（16x16）矩陣開關的背面也將須要160個BNC鏈接器，而且這些裝置的排列範圍高達128x128（很容易達到標準冰箱的大小），以容納1,250多個單獨的BNC鏈接器。

這些RGBHV（及隨後的HDMI）矩陣開關的優點在於，隔行掃描的內容能夠經過電纜徹底不延遲地複製。從本質上講，矩陣開關只是一個很是昂貴的信號加強器和分配放大器的組合，它位於一條長視頻電纜的中間，可用於將信號發送到100英尺而不會下降信號質量。

這裏有一個簡短的註釋：從RGBHV到HDMI電纜的切換增長了一點點扭曲，由於HDMI內容主要是逐行格式的（幀以單張圖像形式呈現），而不是隔行掃描（圖像是一系列隔行掃描的奇偶行）。雖然HDMI能夠支持1080i和1080p，可是RGBHV電纜只能支持1080i。權衡漸進內容（例如720p，1080p，2160p）意味着須要將術語從零等待時間轉變爲零幀等待時間。儘管某些解決方案仍要求零等待時間，可是任何漸進式內容都必須傳輸整個幀而不是一部分幀。

可是，一旦信號須要移到演講廳以外，就連標準的RGBHV或HDMI視頻電纜也沒法使用-在某些狀況下，例如100英尺以上的HDMI電纜就不存在了-所以，一種新的解決方案是必需的。幾年前，從端點到矩陣的交付形式已從昂貴的專用視頻電纜過渡到成本低得多的結構化佈線。無屏蔽的四對Cat5e或Cat6電纜，端接至RJ-45或以太網鏈接器（或無屏蔽的雙絞線或UTP），可以傳輸長達100米（m）或330英尺的基帶視頻信號，而且在通常狀況下這些都是挺廉價的。

在視頻矩陣處切換至UTP輸入和輸出，即便電纜未傳送IP信號，AV集成商也可使用建築物中現有的銅線Cat5e和Cat6佈線，但即便銅線Cat6佈線也限於100m的傳輸距離。可是，這種UTP佈線的使用爲從多個教室將視頻收集到集中式矩陣交換機提供了可能性。可是基本前提保持不變：點對點輸入和輸出進入非IP視頻矩陣交換機。

移動到utp致使了一些有意的營銷混亂(好比AV-overCat5或hdbaseT)，由於IT專業人士看到了佈線，可能會認爲這是標準的基於IP的視頻傳輸。這種混亂也致使了幾年的意外事故，例如，與傳統的PoweroverEthernet(POE)插口相比，帶有非標準功率插孔的AV-超Cat5e電纜-無心中插入了IT部門的以太網交換機，並最終被燒壞。

「 HDBaseT並非知足流媒體需求的解決方案，」Arista總裁Paul Shu說。Arista是一家爲醫療保健，酒店業和其餘關鍵任務垂直市場提供工業計算解決方案的公司。「 HDBaseT旨在解決某些專業AV應用程序遇到的距離挑戰，這是一種將距離擴展到HDMI不能達到的範圍的解決方案。」

以太網軟件定義視頻（SDVoE）聯盟主席賈斯汀·肯寧頓（Justin Kennington）解釋了對這些RGBHV電纜以及後來的Cat5e或Cat6的結構化佈線所交付的子幀交付時間的指望有多麼嚴格：Kennington表示：「在現有技術可以真正複製其性能以前，咱們沒法離開溫馨，熟悉的矩陣開關。」HDBaseT矩陣開關能夠在數十微秒內[提供視頻]，遠遠低於閾值。人類的感知力。」

 

SDVoE的零幀延遲編碼器能夠縮小輸入的視頻圖像的比例，從而使多個編碼器的視頻圖像能夠顯示在單個屏幕上。這種多對一顯示方案被稱爲多視圖合成，利用以太網傳輸的優點來消除對昂貴的矩陣交換機的需求。（圖片由SDVoE Alliance提供。）

根據Kennington的說法，財務情況將推進這一趨勢-他估計，基於IP的技術能夠知足相同的UTP或HDMI電纜的框架的零成本要求，48端口10G以太網交換機的成本約爲5,000美圓，而48x48視頻矩陣交換機的成本約爲59,000美圓。

FPGA到補救（FPGA to the Rescue）

在流媒體行業開始考慮收益以前至少三年，AV行業就採用了一種解決方案，即便用現場可編程門陣列（FPGA）來提供大規模並行編碼。AptoVision是一家在封裝FPGA和以太網物理組件（網絡和芯片製造術語方面稱爲「phys」）方面具備專業能力的公司，開發了現在在視音頻市場中稱爲SDVoE的編碼技術。

「SDVoE端到端的延遲大約是100微秒或0.1毫秒，」肯寧頓說。他指出SDVoE是如何與HDBaseT的速度相媲美的，同時也容許經過低成本的以太網交換機將內容打包並以IP的形式交付，他補充道，「SDVoE的構建方式是由於這是匹配矩陣交換機的視頻性能所必需的。」

考慮到H.264(AVC)和H.265(HEVC)在FPGA編碼方面的進展，流行業中的一些人可能會爭辯說，逐幀或I幀avc或hevc可能適用於這些零幀延遲的用例，但專業AV集成商認爲標準的流視頻編解碼器不符合用例要求。

「SDVoE壓縮編解碼器，若是啓用，會增長五行延遲，」肯寧頓說。「在4KUHD，60赫茲是7.5微秒，即便I幀也只有AVC/HEVC等等。」

肯寧頓在這方面是正確的，由於MPEG編解碼器原本就是爲跨多個幀節省帶寬而設計的，而專爲零幀等待時間設計的編解碼器則能夠對16ms（或16,000微秒）如下的視頻進行很好的編碼。

IDK Corp.（HQ）執行董事兼專業視聽設備製造商IDKAmerica首席執行官巖崎良平（Ryohei Iwasaki）進一步解釋了爲何市場上不只僅有基於標準的MPEG編解碼器的空間，「由於IDK認爲這些編解碼器的用途和目的是不一樣的，因此在SDVoE和H.264 / 265之間切換。

巖崎繼續說：「咱們決定採用10Gbps AV解決方案，由於[a] 4K信號具備18GB，」他指的是未經壓縮的4K60 8位視頻信號在14Gbps範圍內的事實，但考慮到HDMI經過HDMI電纜傳輸4K60信號所需的字位轉換（8b/ 10b）。

Iwasaki說：「咱們爲未來測試了許多其餘編解碼器的功能和可擴展性，而且IDK認爲SDVoE能夠知足如今的大多數專業視音頻客戶的需求，所以它是如今能夠適用的一種。」

以太網交換機不是在8b /10b字位轉換中測量的-實際上，一個1Gbps以太網交換機使用4b / 5b並以1.25Gbps的速率實際傳輸，但做爲1Gbps交換機銷售，以免任何混淆-這意味着壓縮是至關合理的：使用SDVoE方法流式傳輸的4K60 8位信號的亮度（約1.4：1）。

Kennington說，SDVoE在開發SDVoE FPGA-10G phys軟件包時還考慮了其餘編解碼器。「當奠基了成爲SDVoE的基礎時，咱們確實調查了現有的編解碼器（包括MPEG和JPEG等）。咱們發現，它們都以節省帶寬的名義作出了太多妥協。」

正如Kennington所說：「JPEG樣式的編解碼器試圖作出與咱們相同的折衷方案：下降壓縮效率，以換取更好的延遲和/圖像質量。可是咱們發現它們還須要作不少功課。」

而後，Kennington經過基於JPEG的編解碼器選項的核心，對這些高分辨率、零幀延遲的用例進行了研究，指出「基於離散餘弦變換的原始JPEG受到振鈴和塊僞影的影響。「並且，」他繼續說，「基於小波的JPG2000有其自身的問題，特別是在高分辨率計算機圖形和某些顏色過渡方面，其中亮度相對恆定而且色度正在變化。」

這些亮度和色度問題是某些DCT編碼方法固有的。實際上，DCT能夠被認爲是老舊的方法，由於它距JPEG靜態圖像壓縮的出現已有30年了。

Kennington還指出，至少從峯值信噪比（PSNR）質量指標的角度來看，SDVoE解決方案的性能要優於JPEG。「咱們的PSNR編解碼器分數一般比JPEG更好。」他舉了一個例子：「在遊艇俱樂部的圖像中，咱們的分數爲57dB，而所示的最高質量JPEG示例爲45.5dB。」

 

對於要求在選擇將哪一個視頻源發送到一個或多個輸出監視器方面具備靈活性的傳統AV集成，它最主要的成原本自用於管理傳入和傳出視頻信號的昂貴矩陣開關。IP-AV等解決方案（如SDVoE）容許從編碼器進行多播傳輸，用成本更低的10Gb以太網交換機代替了矩陣交換機。（圖片由SDVoE Alliance提供。）

儘管H.264和H.265的命運不必定與JPEG相同，但它們確實具備類似之處，這可能使它們不太適合用做IP over AV集成市場的高分辨率I幀編解碼器。

肯寧頓說：「能夠對標準化的MPEG編解碼器進行調整以減小延遲，但這是以圖像保真度爲代價的，反之亦然。」

廉價的帶寬

雖然使用10Gbps以太網交換機來實時播放4K608位甚至10位內容的概念聽起來有些過頭，但Kennington解釋了使用編解碼器三角形的緣由。「在專業視音頻中，咱們根本不須要優化幀間壓縮便可節省的帶寬。」他繼續指出，大多數IP視音頻解決方案均以1Gbps甚至10Gbps的速度運行，而不是標準的2.5Mbps或6Mbps用於從Netflix發送流式視頻。

關於4K60內容的「至關輕」的壓縮（本質上是1.4：1的壓縮比），肯寧頓還回答了我對數據速率低於10Gbps的視頻的疑問：「SDVoE的編解碼器甚至不使用壓縮除非須要。因爲1080p608位流每秒只有3吉比特，所以咱們以原始數據速率傳輸時沒有任何損失。一樣適用於6Gbps的4K30。咱們僅壓縮高於10Gbps原始數據速率的信號，例如4K60。並且，咱們只壓縮適合10G以太網所需的最小壓縮量。」

這就天然引發了一個問題，即爲何專業視音頻市場已經開始使用10G交換機進行視頻流傳輸。畢竟，10G交換機仍然比1G交換機貴得多。Kennington認爲，這一切都歸功於AV集成商可以可視化「圖像質量，延遲和帶寬之間的權衡」。

視音頻集成中最便宜的部分是帶寬，它至少位於一個物理位置（例如學校或大學校園）內。肯寧頓（Kennington）解釋說，這就是AV與長距離流傳輸不一樣的地方：「[n] pro AV，延遲要求基本上是根據具體狀況肯定的。圖像質量要求不斷提升-更高的分辨率，更高的幀速率，更高的色位深度-可是帶寬是獨一無二的，由於以太網交換機上的帶寬愈來愈便宜。因此咱們使用它更優！」

肯寧頓（Kennington）贊成在以太網上處理內容的其餘方法是有效的，並補充說：「我不敢說Netflix並不成功！」但他指出，這些方法「會形成延遲損失並以某種方式損害圖像質量。專業視聽市場沒法輕易接受。」

有妥協方法嗎？

IDK的Iwasaki指出，須要在SDVoE編解碼器的極高數據傳輸率與將視頻流從一個城市或內容發送到另外一個城市的典型實時流媒體需求之間達成妥協：「某些客戶須要更長的視頻流距離，例如從日本到美國的距離。在這種狀況下，客戶須要使用[其餘]編解碼器（例如H.264/ 265）來最小化帶寬。IDK也正在爲此準備一個能夠橋接SDVoE和H.264的設備。」

Iwasaki補充說，橋接單元仍然是一個概念，而且爲了不級聯問題並保持適當的色彩空間，SDVoE視頻將被解碼回基帶視頻，而後在H.264中從新編碼以進行標準流傳輸。

巖崎說：「在今年的InfoComm上，咱們將擁有一個原型概念編碼器，該編碼器能夠捕獲，流式傳輸來自接收器單元的圖像並能夠經過管理系統進行控制。這些概念可幫助但願將實時解決方案和實際輸出流信號集成在一塊兒的人們。目前惟一的方法是將信號解碼到基帶一次（在H.264和SDVoE編碼之間）。也許SDVoE聯盟未來會提供直接的從新編碼功能。」

Iwasaki還指出，如今尚沒法在SDVoE編解碼器中錄製演示文稿，而且SDVoE聯盟的Kennington表示SDVoE編解碼器僅用於實時傳輸場景。這就是基於標準的編解碼器（例如H.264或H.265）能夠發揮做用的地方。

Iwasaki認爲：「若是客戶但願具備針對這些信號的記錄或網絡流功能，咱們將使用H.264 / 265，由於它能夠經過高壓縮率來減小信號的帶寬。」

Iwasaki認爲，丟失延遲與錄製的內容無關，可是對於高分辨率內容，使用基於MPEG的視頻編解碼器的視頻質量丟失仍然很明顯。

新的平衡方式？

肯寧頓還建議，對於流媒體行業來講，這多是一種新的三足凳圖。衡量本身在編碼和傳輸方面的適當平衡：「在討論質量和帶寬時，延遲，價格和功耗顯得很大。」

要達到零幀延遲，須要大量的計算能力，而且Kennington指出，現有的基於標準的MPEG編解碼器具備價格和功耗問題，而不只僅是基本的質量和延遲問題。

肯寧頓說：「這些算法的計算複雜度也高得多，這對成本和功耗都有影響，特別是在實時編碼器中。我知道的惟一用於實時HEVC編碼的芯片是Socionext的，價格超過1,000美圓，功耗超過35瓦，咱們的合做夥伴製造商的端點售價爲1,000至2,000美圓。」雖然肯寧頓並不想在這個會議上講述完整的細節，可是他的確表示過：「在價格和功率上比這個要高出85%。」

在咱們接近尾聲的時候，這裏有一個提示，即AV和流媒體產業正處於平行的道路上。在許多方面，這兩個行業僅經過一種稍微不一樣的語言和圍繞特定用例的不一樣方法而區分開來。

視音頻行業對典型的流媒體（尤爲是被編碼成成千上萬個2-10秒HLS細分的經典視頻點播高級資產）的延遲理解有點缺陷。在像InfoComm這樣的AV行業活動中走到展廳，您常常會聽到零延遲支持者談論按需編碼，這種編碼須要服務器機架和長達一週的編碼時間才能「正確處理」質量編碼。

然而，視音頻行業至關質疑H.264和H.265的功效，由於它們均基於DCT，所以引入了許多問題，發現編解碼器在嘗試與零幀延遲跳動競爭時會十分被動。

是時候採用一種新的編解碼方法了嗎？用一個編解碼器來處理本地傳遞的零幀延遲，以及對於很是低延遲的遠程傳遞的可伸縮性？答案是確定的，「是的」，而咱們做爲流媒體行業，最好在這個IP視頻傳輸的新時代增強咱們的遊戲，以下降延遲、價格和功耗。

[本文做爲「零和博弈」出如今2019年7月/ 8月的StreamingMedia Magazine中。]