文/ Jan Ozer
譯/ 元寶
原文
https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=131182每年在參加NAB的時候我都對産品沒有抱什麼期望，日程安排也都是比較随意，而不是經過精心組織安排的。會場到處都是我想要見的公司和朋友，還有其他一些公司，他們的營銷人員很積極，會恰好在合适的時間打來電話。另外，在我空閑時間的時候，我也會在展廳裡看看有哪些吸引我目光的公司。是以，本篇文章是有關于“Jan在NAB所看到的内容”，而不是“展會上所有與流媒體相關的重要進展”。
每個知道編碼階梯是什麼的人都應該先閱讀第一部分；然後，我會将這些技術分成幾個部分，這樣您就可以快速浏覽并檢視哪些部分可能與您相關。希望這對你是有所幫助的。
新的提升
2015年12月14日，Netflix通過引入按标題編碼的方法來替代了固定編碼階梯，該編碼方式根據每個視訊的獨特内容為每個視訊建立特定的階梯。在NAB 2019，按标題編碼被上下文感覺編碼的概念所淘汰，上下文感覺編碼結合了視訊的獨特内容、網絡和裝置使用統計資料，根據觀衆實際觀看視訊的方式，為每個視訊建立一個優化品質的階梯。實際上，上下文感覺編碼可以降低編碼、存儲和帶寬成本，并提高使用者的觀看體驗。
這個概念很簡單：QoE信标和網絡日志提供了一些細節，比如觀看者的有效可用帶寬、他們用來觀看視訊的裝置以及在編碼階梯上的檢視分布。您的編碼階梯應該同時考慮這些資料和内容。
第一個将這個概念産品化的是Brightcove及其上下文感覺編碼(CAE)。在一篇題為《優化大規模多螢幕視訊傳輸》的白皮書中，Brightcove的作者為三家不同的營運商建立了同一視訊的編碼階梯，第一家營運商主要面向移動使用者，第二家營運商主要面向PC和電視使用者，第三家營運商專門面向通過電視觀看視訊的高帶寬使用者。圖1顯示了為每個營運商建立的編碼梯形圖，同樣也是為相同的内容建立的。
圖1. Brightcove的Context Aware Encoding（CAE）根據裝置和網絡統計資訊為相同的内容生成三個不同的梯形圖。
本文将這些梯形圖與Apple HLS 創作規範中推薦的HLS編碼梯形圖進行了比較，并說明了三個自定義梯子如何減少再現和整體存儲的數量，以及如何減少帶寬和提高體驗品質。它為CAE提供的價值是提供了引人注目的畫面。
Brightcove已部署CAE超過一年了，而在NAB至少有兩家公司——Epic Labs和Mux，透露了他們類似想法的版本。Epic Labs在一個名為LightFlow的産品中提供其版本，并且至少有一個高容量使用者，而Mux則在4月份添加了Audience Adaptive Encoding 到它的編碼堆棧中。
圖2.回報到Epic Labs的LightFlow系統的帶寬和裝置資料。
有關Brightcove和Epic Labs産品的更多資訊，您可以觀看我對Epic Labs創始人兼首席執行官Alfonso Peletier的采訪。
您現在可以使用現有的編碼工具和工作流做些什麼呢？除了與這些公司簽約之外，您還可以仔細檢視觀衆最常使用的裝置分辨率以及通常消耗的編碼階梯的梯級，然後進行一些正常的調整。許多主要服務于北美、歐洲和遠東國家的組織會發現，大多數觀衆都是在觀看最熱門的兩到三條流，而且它們可以在不降低QoE品質的前提下，從自己的梯子底部剪切下一兩段。相反地，那些主要服務于較低比特率的檢視器的最好方法是将它們的大部分梯級集中在這個範圍内的檢視器上。快速浏覽圖1可以為這些工作提供指導。
在我看來，無論以什麼名義，将網絡和裝置資料合并到編碼梯形公式中是我在NAB看到的最重要的技術。但還有許多其他亮點，這裡隻是一個簡短的概要。
什麼是Twitch？
Twitch.tv是一個進步顯著且非常成功的營運商，通過貢獻文章文章以及在會議中發表演講，他們一直在與流媒體觀衆分享其專業知識。Twitch的明星之一是沈悅時，首席研究工程師（7級）兼項目工程經理。在一次采訪中，悅時分享了Twitch采用VP9和AV1的計劃，以及為什麼在向成千上萬的實時觀衆流式傳輸時絕對需要進行恒定比特率編碼。
在VOD編碼方面
我與Telestream開始了我的NAB，與市場總監Ken Haren讨論了Vantage Cloud端口。在較高的層次上，該端口使Vantage客戶能夠将許多以前隻能在本地使用的工作流部署到雲上，這是一個關鍵的好處，因為越來越多的公司将夾層資産存儲在雲上。
在我的下一站Capella Systems，我讨論了Cambria FTC的主要新功能，這是該公司的旗艦VOD編碼器。與Telestream一樣，Capella向Cambria添加了雲功能，特别是能夠啟動運作Cambria的AWS執行個體，并将編碼分發給這些執行個體，就像在本地編碼場上運作的任何其他Cambria執行個體一樣。Capella建立了AMI預置，使用者可以在Cambria中啟動和控制它。它非常适合将溢出編碼需求推送到雲，同時将正常負載以最經濟的方式編碼到現有系統。
另一個新功能是能夠導入基本流并以DASH或HLS格式打包它們。這允許生産者對其内容進行一次編碼，并根據需要将其打包以用于其他分發目标。這種先編碼後打包的兩步工作流程比針對每種輸出格式從零開始編碼要有效得多。
周三，我采訪了Encoding.com創始人兼首席執行官Greggory Heil。除了讨論最近釋出的全球格式報告，Heil還強調了一些新特性，比如編碼和解碼Apple ProRes、輸出Dolby Vision的能力，以及Ludicrous HLS将源檔案分割成更小的片段來加速編碼。作為對上述按上下文讨論的一個有趣的對比，在采訪之後，我問Heil為什麼Encoding.com還沒有提供按标題編碼。他回答說，雖然按标題編碼肯定都在他們的路線圖上，但它在使用者中并不是一個非常受歡迎的功能。
我與AWS Elemental進行了簡短的會面，讨論了AWS MediaConvert的加速編碼。它與Encoding.com的Ludicrous HLS一樣，将視訊分段提供給多個編碼器，進而将編碼速度提高至多25倍。
我還與雲編碼器Qencode的首席執行官Murad Mordukhay進行了交談。Qencode提供一種按标題編碼的形式，定價非常有吸引力，比如SD編碼每分鐘0.004美元。該服務支援所有相關的輸入和輸出格式，包括AV1，任何尋求雲編碼工具的公司都值得一看。
基于硬體的編碼和解碼
硬體轉碼是一個令人感興趣的話題，我将在Streaming Media East上發表關于這個話題演講。NETINT是一家提供超高密度解決方案的公司，它展示了基于公司自己的Codensity G4 SSD控制器SoC(系統在一個晶片上)的Codensity T400視訊轉碼器，能夠在高達單個4K / 60p或8x 1080p流的情況下進行可擴充的H.264 / H.265轉碼。Codensity晶片使用現在許多企業級存儲伺服器中常見的NVMe連接配接來實作高密度解決方案。
我還會見了Softiron産品戰略顧問Anil Saw，他展示了他們的高密度HyperCast編碼器，它是圍繞Socionext的MB86M30 SoC建構的。HyperCast可以在1RU形式因子中支援多達32個SoC，每個SoC可以編碼多達一個4K60流或四個1080p60流，每個流最多包含六個視訊和兩個音頻輸出。NETINT和Softiron都面向電信、有線、衛星和雲視訊服務提供商。
NGCodec開發、營銷和銷售基于Xilinx FPGA的硬體編碼器。在NAB，NGCodec示範了實時的HEVC和AV1轉碼，他們聲稱比其他基于硬體的H.265和VP9編碼器提供了30%的更好的壓縮。值得注意的是，這是Twitch TV在其基于硬體的VP9代碼轉換中使用的技術。
AV1實時編碼是一項技術預覽，并且隻支援i-Frame。另外還有一種新的HEVC雙密度編碼，它使每個FPGA的輸出容量翻倍。NGCodec編碼可作為AWS服務使用，使其易于通路。我與公司總裁Oliver Gunasekara進行了交談，并就Intel / Netflix新發表的SVT/AV1編解碼器發表了一些直接的評論。
同樣在硬體方面，Beamr展示了基于Intel圖形技術GPU的硬體加速CABR（内容自适應比特率編碼）。在較高的層次上，Beamr将自己的速率控制機制插入到Intel GPU的HEVC編碼管道中，是以Beamr可以在Intel CPU進行HEVC編碼時進行速率控制。這加快了Beam的内容自适應編碼性能，但品質可能與Beamr自己的基于軟體的HEVC編碼器的品質相比對。
有趣的是，英特爾似乎正在通過其SVT-AV1公告以及相關的HEVC、VP9和H.264編解碼器來遠離硬體編碼。Beamr正在進入這個領域，應該能夠通過Beamr CABR SDK 将内容自适應功能擴充到任何GPU、CPU、FPGA或其他采用H.264或HEVC編碼的硬體。
所有上述公司都使用硬體編碼以進行分發。在貢獻方面，我與LiveU工程副總裁Daniel Pisarski談論了HEVC如何在LiveU生态系統中工作以及5G何時會貢獻相關的内容。簡而言之，HEVC很快就成為了LiveU使用者所青睐的格式，盡管所有的傳輸都必須通過LiveU的雲服務進行路由，在雲服務中，信号從裝置上的各種數據機組裝到H.264上，然後被轉換成H.264，最後流到最終目标。Pisarski預計5G将在未來12到24個月内變得重要。
品質和QoE監控
SSIMWave是SSIMPlus名額的開發者，該名額是用于VOD和實時監控的功能強大且輕量級的名額，并提供特殊的裝置支援。在NAB會議上，我了解到該公司參與了ASC運動成像技術委員會的HDR評估工作組。目的是評估在HDR制作工作流程中使用的不同技術和格式如何保留“原始創作意圖”，和“校準SSIM結構相似度視覺感覺品質名額的HDR，寬顔色，超高分辨率的視訊材料，基于專業電影攝影師和色彩師的回報，以及制作和進行顔色分級的材料。
從本質上說，通過這些金眼睛的輸入，SSIMplus将在HDR輸出的準确性方面得到“訓練”，這應該使其成為HDR生産的首選名額。為HDR評估建立的幾個源/編碼比較螢幕已經成為SSIMWave零售産品，包括用于比較源和編碼輸出之間的顔色相關差異的極好的螢幕。
我和QoE供應商的同僚們一起度過了愉快的30分鐘，他們都是工作上友好共事的人，這是名副其實的。我和Jonathan Shields談到了NPAW産品線，包括他們在視訊中的反流失和CDN切換工具。我們還花了一些時間讨論哪些視訊釋出者已經采用了QoE解決方案，哪些還沒有，但應該采用QoE解決方案。基本上，Shields創造了一個強有力的案例，如果視訊對一個行動至關重要，那麼QoE也應該如此。
Finishing Up
還有這樣的一些公司，他們的産品并不完全符合任何類别。其中一個是Mediamelon，它的SmartPlay Streaming是一種針對按标題編碼的傳遞端優化器。也就是說，該服務測量ABR組中流的品質，并且隻有當它實際增加了觀察者所感覺到的品質時，才配置設定更高的帶寬流。是以，可能以1080p@3Mbps檢索簡單場景，而以1080p@5Mbps接收更高動作場景。系統還可以在複雜場景之前下載下傳視訊，以避免在受限條件下緩沖較大尺寸的片段。
我們以QBR的名義對産品進行了評審。雖然QBR運作良好，但它有一個嚴重的弊端，隻有當梯子中的所有梯級都以相同的分辨率編碼時，它才會工作，這與大多數推薦的方法相反。不過這個問題已經得到了很好的解決，公司進一步完善了其内部度量标準，并使用這個标準來度量編碼階梯中的流的品質。
這個名為MediaMelon iMOS的名額運作速度比實時更快，這很好，但我想知道評分與VMAF的關系有多密切，在評估完整編碼梯子時，VMAF是我最信任的名額。MediaMelon提供了如圖3所示的比較，它顯示了這兩個名額之間的合理相關性。是以，如果您相信VMAF，那麼iMOS應該能夠很好地預測您的觀衆實際感覺到的品質，這意味着SmartPlay流媒體應該能夠有效地為您服務。
圖3. Mediamelon的按标題傳遞端應該能夠通過使用該名額預測品質來減少下載下傳帶寬
SmartPlay流媒體是一種提高帶寬效率的方法，無需按每個标題或每個上下文技術重新編碼整個庫。它也可以與每個标題系統一起使用，以節省帶寬，不過，如果将内容編碼到一個典型的固定比特率階梯，您可能會獲得最大的收益。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/90252764「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。