Demuxed：編解碼器和壓縮的未來
Demuxed視訊工程師年會生產了來自Akamai、YouTube、Mux和其它許多人必看的演講內容，資深多媒體技術諮詢師Jan Ozer對會議中感興趣的部分內容進行了回顧與總結。LiveVideoStack對文章進行了翻譯。
文/ Jan Ozer
譯/ 元寶
原文
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Demuxed-18-Highlights-The-Future-of-Codecs-and-Compression-128609.aspx
Demuxed是由視訊工程師們舉辦的視訊工程師年會。該會議於10月17日和18日在舊金山舉行，共有31名演講者以快速的方式進行了演講，演講時間從10分鐘到30分鐘不等。用一個老套但恰當的比喻，這種體驗就像從消防水管中喝水：幾乎不可能實時理解和消化。我參加了第一天的演講，並通過Twitch.tv上的視訊庫觀看了第二天的幾場演講。
總的來說，視訊是各主題的寶貴資訊來源。在這個故事中，我將回顧一些我覺得最有趣的演講，這些演講顯然對我來說是獨一無二的。在瀏覽下面的列表之前，我強烈建議您回顧一下完整的演講者和主題列表（https://demuxed.com/）。你可能會發現除了下面我所討論的，還會想看更多的演講，這些演講都是按照演講順序列出的。
Demuxed 第一天
會議以Fubo.TV的Billy Romero和Thomas Symborski的一場名為“用HDR播放2018年FIFA世界盃”的演講下拉開帷幕。演習的目的是提供一個四級HEVC編碼階梯，範圍從2160p（16Mbps）到720p（3.5Mbps），全部採用HDR10 HDR元資料（圖1）。整個工作流程基於雲，並涉及在AWS C5.18 X-Large例項上對雲中的70 Mbps輸入源進行轉碼。
圖1.使用HDR10進行FIFA世界盃4K傳送時使用的例項詳細資訊和編碼梯形圖。
在演講中，主持人為尋求產生類似體驗的視訊工程師提供了藍圖，涵蓋了採集，編碼器選擇，打包和儲存以及客戶端和播放器考慮因素的網路設定，包括向亞馬遜Fire TV / Android TV，Roku，Chromecast Ultra和Apple TV裝置提供使用ExoPlayer，AVF，Roku，Shaka和Bitmovin播放器的經驗。最終，主持人建議與會者“快速失敗，快速學習，專注於使用者體驗”。
下一個演講是來自Mux的Ben Dodson和Nick Chadwick的“Per-Title(按標題)編碼後要做什麼”。在快節奏的演講中，Dodson和Chadwick回顧了Per-Title編碼的歷史，以及許多基礎理論和挑戰。然後，這對組合詳細說明了Mux如何使用機器學習構建自己的Per-Title編碼工具，以及Per-Title編碼如何擴充套件到Per-Scene(按場景)編碼，從而支援實時的Per-Title編碼。這是一個密集且技術上具有挑戰性的簡報，任何一個設計Per-Title或Per-Scene編碼器的人都會發現它是無價的。
感知視訊質量是我們工作的核心，Twitter的Sebastiaan Van Leuven的演講“移動裝置的主觀視訊質量評估”就直接解決了這個問題。在他十分鐘的演講中，Van Leuven首先回顧了兩種常用的測量視訊質量的技術，單刺激和雙刺激平均意見得分（MOS）。簡而言之，單刺激顯示單個樣本並要求在五個等級上進行評級，而雙刺激顯示原始視訊然後是編碼樣本，並請求相似的等級。雖然易於部署，但兩種測試方法在精度和一致性方面得分都很低，不同的測試人員對同一視訊的評分和相同的測試人員在不同的日期對同一視訊進行評級。
為了提高一致性和可靠性，Twitter開發了一個自適應配對比較（APC），它顯示兩個樣本，並詢問受試者哪個更好，就像驗光師問:“哪個看起來更好，左邊還是右邊?”這種測試方法可以產生更準確和可重複性的結果，但也可能非常耗時。關於Twitter方法的新穎之處在於使用粒子濾波模擬的主動學習過程，該模擬簡化了樣本選擇。這個簡短的演講提供了一個概述，Van Leuven補充了一個部落格文章的連結(https://blog.twitter.com/engineering/en_us/topics/insights/2018/videoqualityonmobile.html)。
使用dav1d加速AV1播放
開放媒體聯盟（AOM）AV1編解碼器於2018年中期推出，但硬體加速播放預計要到2020年中期才能實現。這使得軟體解碼器效率對於未來24個月的部署絕對至關重要。使用AOM解碼器libaom進行AV1解碼的許多初始測試，包括我自己的（http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx），都表明AV1解碼速度慢且效率低下。出於這個原因，AOM贊助了由VideoLAN，VLC和FFmpeg社群開發的一種名為dav1d的新型開源AV1解碼器。
在他們的題為“引入dav1d”的演講中，“一個新的AV1解碼器”，VideoLAN的Jean-Baptiste Kempf和兩個Oriole的Ronald Bultje描述了該專案的目標，包括更小的原始碼，更小的二進位制可執行檔案，以及比libaom更小的執行時記憶體佔用。在演講中，Bultje回顧了迄今為止dav1d的效能，並預測完全實現後，它將產生與H.264，HEVC和VP9類似的解碼效能。雖然這與硬體支援的編解碼器的解碼效率不匹配，但它肯定會擴充套件AV1的使用範圍，遠遠超出libaom可以採用的範圍。根據這篇部落格文章（http://www.jbkempf.com/blog/post/2018/Introducing-dav1d），dav1d目前適用於x86，x64，ARMv7，ARMv8硬體，可在Windows，Linux，macOS，Android和iOS上執行。
正如RealEye Media的David Hassoun在他的演講中指出的那樣，“多CDN跳轉開始，不要把所有位元放在一個籃子裡”，使用單個CDN交付流量意味著一個單點故障，無論何時流交付是關鍵任務，這都是不可接受的風險。正如Hassoun也提到的，單一的CDN也可能不能為許多使用者提供最好的體驗，也可能沒有成本效益。
得出這些觀點後，Hassoun確定了使用多個CDN的常見問題，例如實時流的同步起源，流量路由，接收QoS和QoE的可操作的實時資料以及跨CDN訪問安全性。然後，他提出了這些問題的多個解決方案，以及如何構建多個CDN支援，一直到清單檔案的建立。在分配的十分鐘內覆蓋了大量的內容，對於任何考慮嘗試多個CDN交付的人來說，這個演示都是必須的(圖2)。
圖2.向動態主播放列表新增多個CDN支援。
減少Glass-to-Glass延遲
Glass-to-Glass的延遲是許多現場活動製作人一直關注的問題。雖然有幾種專有方法可以減少實時延遲，例如Wowza Streaming Cloud的超低延遲服務，但這種方法可能無法滿足大型事件所需的規模。
Akamai的Will Law在他的演講題為“Chunky Monkey, Using Chunked-Encoded Chunked-Transferred CMAF to Bring Low Latency Live to Very Large Scale Audiences.”中全面描述了Chunked CMAF。圖3說明了這種方法。最重要的是傳遞分段的傳統方式，它一直等到它完全定型並存儲起來。底部顯示了以塊的形式打包的相同媒體樣本，可以在完整片段編碼和儲存之前傳送，從而大大減少延遲。
圖3.頂部是完成後交付的單個段。在底部是相同的樣本打包在塊中交付chunk塊。
雖然這種方法可以減少延遲並簡化網路吞吐量，但它也會引起許多問題，例如如何估算頻寬以及如何解決HLS和DASH之間的時序差異。Law討論了這些問題的不同解決方案，並總結了用於分塊CMAF的標準化工作，以及用於實現該方法的商業供應商和開源工具。
最後一個演講是“Fabio Sonnati的'Time Machine'，'如何在回放過程中感知重構編碼過程中丟失的部分細節。”作為背景，Sonnati是數字視訊編碼的先驅，其關於每個標題編碼和FFmpeg的文章為包括我自己在內的許多從業者提供了重要的基礎。這是我第一次親自見到Fabio並看到他講話。
在他的演講中，Sonnati探討了在播放過程中是否有可能重建壓縮過程中丟失的部分質量。他首先確定了編碼過程中產生的經典編碼偽像，其中包括精細細節和膠片顆粒的損失，條紋以及對比度和平面度的降低。鑑於我們知道這些發生，Sonnati詳細說明了我們如何在解壓過程中解決這些問題（圖4），並展示了幾個通過部署這些技術實現VMAF質量顯著提高的實驗。
圖4.在解壓縮和顯示期間修復與編碼相關的問題。
在操作上，Sonnati聲稱這些增強功能可以在使用WebGL的現代瀏覽器中實現，包括在可以提供最大利益的移動裝置上。但是，在廣泛部署之前，必須解決效能調優和邏輯方面的考慮。
Demuxed第二天
如上所述，我只參加了會議的第一天，因此整天有兩個觀察來自存檔視訊，我主要關注與編碼相關的演講上。我觀看的第一個演講是Mux創始人Jon Dahl的演講題為“視訊，進化和引力：科學如何影響數字視訊”。正如標題所示，Dahl探討了人類生理學和物理學如何為視訊編碼和製作的許多基礎做出貢獻，包括寬高比、幀速率和色彩管理。
在解決的眾多問題中，Dahl用“Jon’s Law”量化了為什麼許多攝像師(包括這位作者)討厭垂直方向的視訊，“Jon’s Law”假定“垂直方向的適當性隨著變化的數量呈指數級下降”。這就解釋了為什麼在人像模式下拍攝的靜止影象看起來如此棒，而體育賽事的垂直影象片段看起來卻如此糟糕。最後，Dahl提出，所有的視訊製作者都可以從學習人類感知背後的科學中獲益，從而更好地指導他們的創造性和發展努力。
接下來是John Bartos關於低延遲HLS的演講，這是對Will Law關於分塊CMAF的討論的一個很好的補充。除了是JW Player的高階軟體工程師之外，Bartos還是開源播放器HLS.js的核心維護者之一，HLS.js是一個JavaScript HLS客戶端，它在瀏覽器中使用媒體源擴充套件來播放HLS和其他ABR格式。Bartos描述了他希望如何在不使用WebRTC或RTMP等技術“顛覆”視訊堆疊的情況下將HLS播放延遲從30秒減少到大約2秒。
簡而言之，低延遲HLS的工作原理是通過在清單檔案中釋出低延遲段，然後通過如上所述的Law的演講中的分塊傳輸編碼來傳輸它們。然後，伺服器將分段塊從程式碼轉換器推送到客戶端以進行回放。雖然這聽起來很簡單，但所需的程式碼轉換器/伺服器/客戶端整合使這項技術更好地通過標準實現，Bartos最後列出了一些參與建立低延遲HLS標準的公司。
我觀看的下一個環節是康卡斯特的Alex Gilardi，題為“在多幀率編碼中迴圈利用的優點””。高階問題是，在生成編碼階梯時，大多數編碼器對每個層執行某種程度的分析，這是一種浪費，因為源視訊對於所有層都是相同的。
在回收過程中，Galardi指的是在低解析度編碼期間收集的分析資訊，這些資訊可以用於更高解析度的編碼，圖5中的流程表明瞭這一點。在某些情況下，必須對較低解析度的資訊進行細化，以應用於較高解析度的檔案，這一事實使這種回收複雜化。在他的演講中，Galardi討論了三種不同的改進方案，其中最快的一種在使用HEVC編解碼器編碼高解析度檔案時，速度提高了2.43x，而沒有質量損失。請注意，雖然這種方法減少了編碼所花費的總CPU週期，但與並行編碼器相比，它會增加端到端延遲，因為較低解析度的檔案需要在較高解析度的檔案之前進行編碼。此模式使此方法對於實時編碼不切實際。
圖5.重用分析資訊以加速編碼階梯的生成。
Comcast使用HEVC證明了這種方法，它也應該適用於其他編解碼器，如AV1和VP9。在他的最後一張幻燈片中，Galardi包含了實現這種方法所必需的FFmpeg指令碼，這無疑會簡化實驗。
部署主觀視訊質量評估
引起我注意的下一個演講是來自英特爾的Vasavee Vijayaraghavan，他的演講題目是“衡量感知視訊質量及其原因”。Vijayaraghavan首先描述了SSIM和PSNR等客觀指標，它們是可自動化的，因此易於使用。然而，她指出，這些指標往往與人類視覺系統不準確相關，這限制了它們的效用。
相反，產生平均意見得分（MOS）的主觀評價是耗時和昂貴的，但卻是人類評級的最佳預測指標。在英特爾進行的4K編碼測試中，Vijayaraghavan發現高於MOS等級4.5的分數對於觀眾來說是難以察覺的，並且建議設定位元率以產生4.5或大約13 Mbps的最大MOS等級（圖6）。如下所示，與更高的資料速率編碼相比，這仍然帶來了非常顯著的頻寬節省。
圖6.英特爾發現高於4.5的MOS評級沒有產生明顯的改善。
在生產環境中，Vijayaraghavan建議通過從最常用的內容型別中選擇有代表性的視訊，在不同的視訊質量點進行編碼，並測量MOS分數，實現每個類別的編碼方案。一旦確定了適當的最大速率，就可以建立適當的編碼階梯，並將其應用於該類別中的所有視訊。但是，她警告說，必須對每個內容類別和編碼器/編解碼器分別執行這種分析。
我觀看的最後一個演講是來自YouTube的Stephen Robertson，他本應該講ABR在生產中的機器學習。然而，顯然，YouTube上的機器學習尚未投入生產，因此Robertson做了一個關於多個主題的巡迴演講，包括在YouTube上實施機器學習的挑戰以及一些非常有趣的視訊質量研究。
在更實際的層面上，他開始講述YouTube在10月中旬每秒分發大約1 GB的AV1編碼視訊，他預計到10月底它將增加到超過1 TB /秒。他確實分享說AV1不是最具成本效益的方法，但YouTube正在部署AV1，以表明他們對編解碼器“極其認”並“致力於其成功”。
總體而言，各種主題和演講者使Demuxed成為所有視訊製作人的寶貴資源。同樣，我建議您瀏覽一下演講列表（https://demuxed.com/），看看是否有適合您實踐的演講。
精品文章推薦
技術趨勢：
技術乾貨：