作為實時音視頻行業，我們對為什么不能零延遲推送視頻提出很多理由，其中主要集中在網絡容量或間歇性，擴展低延遲解決方案的成本，甚至局限性的現成處理器實時處理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中。]

LiveVideoStack?秋季招聘

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

總結

以上是生活随笔為你收集整理的实现视频和音频的零延迟是标准的零和博弈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。