歲歲年年人不同——LVS2019多媒體會議見聞（一）

2017年參加了在北京舉辦的第一屆LiveVideoStack多媒體技術大會，去年沒能參加，今年則遠赴上海蔘加了第三屆大會。會議的票價幾乎每年上漲一千元，今年8月在北京還有一場，全價票已經達到了3000元的水平，令人咂舌。要不是抽到了一張免費門票，這次我大概也不會來上海蔘加這次會議。

先說結論，通過這次參會，我掌握瞭如何快速分辨一場演講水不水的技巧：如果一場演講的嘉賓來自你沒聽過的一家公司，並且這家公司又恰巧在大會贊助商名單上，那麼大概率會是一場比較水的演講；如果在同一時間段有兩場演講的時間衝突，那麼優先選擇演講嘉賓來自大廠的那一個，這樣水掉的概率會比較小。

好了，說回會議現場，看到人頭攢動，布展的贊助商也比當年多了不少，不禁要感慨，有錢的個人or公司還是多啊。

今年的聯席主席是來自上海交大的宋利教授，宋教授的學術水平毋庸置疑，在交大官網的個人頁面上有所介紹（可能因爲真的十分厲害，交大官網上把宋教授的簡介重複粘貼了兩遍==）。宋教授的發言很簡短有趣，主要推薦了兩本書：《系統化思維導論》和《像外行一樣思考，像專家一樣實踐》，都是幫助我們重塑思維模式的經典書籍，值得閱讀。

首先帶來主題演講的是騰訊VP劉杉女士，劉女士的履歷十分閃耀，大家一搜便知。劉女士帶來的主題演講題目是《從視頻編解碼標準生態的歷史看未來》，標題很大，但內容其實就兩大塊：視頻壓縮編碼知識科普與未來展望。

視頻壓縮編碼這塊，劉女士講的內容在任何一本教科書上都能找到，對這塊不熟的朋友，也可以參考我的文章：x264源碼分析與應用示例（一）——視頻編碼基本流程和HEVC碼率控制算法研究與HM相應代碼分析（一）——HEVC標準及編碼流程介紹。

未來展望這塊，主要提及了VVC（Versatile Video Coding），劉女士向我們透露了三點信息：VVC的V1版本預計於2020年底完成；相比於HEVC， VVC預計可以節省30%以上的碼率；VVC標準組正在考慮神經網絡在視頻編碼中的應用。

第二個主題演講由LiveVideoStack的老朋友Akamai首席架構師Will Law帶來，這老哥好像經常出沒於各種大會，不過人家講的東西確實乾貨多，不服不行。演講題目是《電視的未來》，這裏說的電視是指OTT，未來則是指3-5年之後。

Will主要立了如下幾個flag：

未來OTT直播業務的端到端延遲範圍在1-10s以內。
我們都知道，影響直播業務端到端延遲的一大因素就是媒體分片的時長，Will每次演講都要提到的CMAF chunk就是基於這一原理達到降低端到端延遲的目的。CMAF不是一個全新的概念，想要了解更多，可以點擊這裏。當然，Will也指出，儘管CMAF chunk能降低OTT直播業務的端到端時延，但它也不是萬能的，比如實時語音通話這種業務，還是要用webrtc，這種實事求是不吹牛的態度值得我們學習~
OTT直播業務在不同設備之間的同步將做到1s以內
同一個直播流，不同網絡環境下的不同設備在觀看時很難保持相互之間的同步，比如你家鄰居都看到比賽的進球瞬間了，你卻還沒有。而通過設置同步時延門限值+外部時鐘信息+自動調節播放速度，就有可能在不同設備間保持一定程度的同步。
8k內容將在2022年得到普及
當年我們總覺得4k很遙遠，現在很多視頻網站都提供4k清晰度選項了。8k也是一樣，現在我們覺得很遙遠，其實也將很快得到普及。現在傳輸HEVC編碼的8k視頻大約要64Mbps的帶寬，到2022年，隨着新編碼方案的提出，有望用40-50Mbps的帶寬即可傳輸8k內容。即使在網速相對落後世界的我國，也有很多地方早已達到這樣的傳輸帶寬需求，所以8k內容的普及並非癡人說夢。
HDR的生態將逐漸完善，並且dolby vision將在動態元數據方向成爲主導
從下圖就能看到，現在很多OTT設備都同時支持多種HDR方案，這種現狀還將持續下去。
多種編碼格式的媒資管理將成爲常態
未來的視頻編碼格式有更多選擇，AV1/HEVC/VVC將成爲主流，H264將僅作爲向下兼容的選項存在。Will本人也表達了VVC的悲觀態度，認爲VVC也會像HEVC那樣面臨license的問題。Will還介紹了一個新東西：MPEG-5 EVC（Essential Video Codec），根據Will的介紹這是一個MPEG新提出的壓縮方案，簡單來說它爲了規避HEVC的license問題，抽取除了HEVC中不受License影響的技術，在添加一些新的技術，最後也達到了優於HEVC的表現。詳情可以參考這裏。

除了上面幾個flag外，Will還立了幾個網絡傳輸方面的flag，例如視頻內容從源到端的傳輸方式將發生改變、HTTP3將佔據30%以上的份額、CDN定價的方式將發生改變等等，這裏不一一展開說了，下圖展示了Will立的所有flag，我們2022年再來看結果如何~

第三位主題演講的嘉賓是一位操着倫敦腔英語的小哥，來自初創企業MUX，小哥獨自一人第一次前來中國，誠意滿滿。演講主題是《視頻API的發展》，主要介紹視頻雲服務商如何設計API。但是小哥明顯高估了聽衆的英語水平，連個翻譯也沒請，ppt文字又很多，估計許多人都沒聽懂。
因爲演講內容跟我的工作關係不大，我也沒仔細聽，曬一張最後的總結圖吧

上午的演講到這裏基本就結束了。

下午主要聽得是客戶端與前端這個主題分會場的演講，下面詳細說一下。
第一場演講來自美攝，美攝是一家脫胎於新奧特的公司，主要提供視頻編輯SDK服務。廣電圈的朋友一定都對新奧特很熟悉，來自美攝的講師也很有廣電技術人員的樸實風格，幾乎是把團隊內部wiki文檔和SDK文檔（我後來在美攝SDK官網上找到了他PPT上的一些圖）全搬過來講了，從非常細節的角度介紹了美攝視頻編輯SDK的架構：

在下面的數據流圖中可以看到，在美攝SDK中以時間線來管理所有的媒體軌道和添加的各類特效、字幕等，並根據需求決定最後是輸出到預覽窗口還是本地文件。

線程模型上，下圖中的每一個模塊都在自己單獨的線程中，每個線程完成自己的工作後通知其他線程，進行下一步的工作

到目前爲止應該說都還是比較常規的視頻編輯SDK設計思路，到video processor組件這裏就有點意思了，提到了graph的概念。根據講師的介紹，在美攝的視頻處理組件中不同於傳統非編軟件按層次疊加的思路，而是採用了graph的思想，graph中每一個節點（可以理解爲一個視頻算法）都可以有多個輸入和輸出。不過從講師給的圖中倒是沒明顯看出graph的感覺，感覺還是傳統的非編軟件設計思路，也許是我理解的不夠透徹。

講師還着重介紹了一下美攝SDK特效的可擴展性，這裏主要是通過資源包的形式來實現

資源包的加載流程如下所示

除此之外，講師還介紹了一下美攝現在的AI智能剪輯功能，不過還比較初級，只是識別視頻中的內容主體，將主體抽取出來，再套用固定的剪輯模板。當然這樣的智能剪輯功能已經可以滿足很多人的需求了，不過我心目中的智能剪輯應該是能達到自動組合視頻主體和空鏡，自動匹配音樂節奏，脫離固定模板的程度。

第二場演講來自騰訊音樂，介紹了在全民K歌中的互動直播技術創新與優化。先來看一下全民K歌的總體架構，分爲三層：底層模塊+基礎能力模塊+業務需求模塊。

首先第一點提到的是如何做到低延遲的音視頻傳輸

主要利用的是騰訊私有的UDP協議，並且結合了FEC/ARQ來提升網絡抗性

與此同時，爲了提升弱網環境下的視頻流暢度，使用了多級流控的方法

除了以上兩點外，騰訊的小哥哥還提到了一個有趣的case：有時候視頻卡頓是因爲網絡選擇了錯誤的IP，比如上海的用戶卻走了香港IP，爲了解決類似問題，設計了IP競速策略，來優化上下行接入導致的卡頓問題。

在介紹瞭如何做到低延遲音視頻傳輸後，接下來介紹了一些音頻上的優化。對於一款K歌應用來說，好的音頻體驗應該能做到如下幾點

先來看一下全民K歌的音視頻數據核心處理流程

基於以上流程，可以做到全流程分析並優化音頻卡頓的問題，這裏比較有意思的一點是在網絡卡頓時可以通過放慢音樂播放的速度來迷惑觀衆，達到提升用戶體驗的效果。這一點也許也對播放器開發人員有啓發。

在音頻卡頓問題之外，對於一款K歌應用還有一個非常重要的指標是耳返延遲與音伴同步。在ios設備上可以自己做一些系統優化，在android設備上則需要聯合手機廠商一起做合作優化。一般來說，伴奏與人聲之間的偏移要在40ms以內才能達到同步的效果，這裏有一個有趣的問題：如何量化伴奏和演唱人聲之間的延遲呢？其實可以讓左聲道只放伴奏，右聲道只放人聲，然後取兩個聲道的頻譜看偏移量來作爲延遲的量化方法。

除了音伴同步之外，還有一個歌詞伴奏之間的同步問題。對於這一問題，也有如下的解決方案。

介紹了網絡優化和音頻優化之後，騰訊的小哥哥又介紹了一下如何從研發流程和質量監控的角度提升用戶體驗。不過這裏數據上報的時間粒度會不會太小了一點，恐怕值得商榷。

上面介紹的都是優化方案，在創新業務上，主要介紹了以下幾點。
首先是連麥，其實這個也不算創新業務了，不過小哥哥倒是詳細對比了各種連麥方案，全民K歌最後使用的是方案三，雖然流量損耗大，但是靈活性更高

最終形成的組件化架構設計如下

第二項創新業務是實時在線合唱，要說明的是，這裏只是做到了二人合唱，還做不到多人合唱。還是一樣，介紹了各種合唱方案的區別，最終選擇了方案二。

在這一場景下的音視頻處理流程如下

最後一項業務創新是歌詞動效，騰訊這裏是利用libass來實現的，並且做了一些優化，達到可以應用的程度

第三場演講來自網易，主題是移動端播放器優化實踐，主要介紹的是如何做到降低卡頓率和提升起播速度。這裏要說明的是，網易的播放器是基於ijkplayer研發的。
首先來說卡頓優化，卡頓的原因總共有三種：緩存不足；性能不足（解碼能力不足或渲染能力不足）；時間戳混亂。
先來說緩存問題，緩存不足的原因有以下幾點：發送出來的視頻流就已經丟掉了；CDN轉發過程中丟幀或者不及時；本地帶寬不夠。
針對以上三點，第一個卡頓優化方案就是智能選擇CDN，這一點和全民K歌使用的IP競速方案頗爲相似。

如果選擇了一圈，最後CDN的質量還是不夠好，怎麼辦呢？首先要有一套完整的埋點統計方案，基於統計結果可以在服務端給出CDN黑名單，在客戶端可以做CDN切換，如下

再來說本地性能優化。針對渲染性能不足和解碼性能不足的問題，網易給出的解決方案如下，其中均勻丟幀的原理在於人眼其實對連續丟幀更爲敏感。當然，下面提到的諸如metal渲染、硬解碼這些，要分機型予以應用。

當然，解決卡頓問題還可以採用碼率切換的方法，這一點就是老生常談了。
接下來說起播優化，相信大家也都知道，起播優化就是對起播流程中的每一個環節進行優化，那麼來看看起播流程中都有哪些環節

首先是CDN調度，採用了預調度的方式來優化

接下來是建連優化

最後就來到了解析、解碼、渲染優化階段，除了前面說到的硬解、均勻丟幀之外，還可以通過一些小技巧提高解析速度。

然後針對具體的點播業務，也介紹了一些秒開優化的方法。其中一個場景就是列表滾動的短視頻，爲了達到秒開需要做預加載，在這裏有兩種方案。在第一種方案中使用多個播放器實例，第二個方案中則由應用實現拉流，構建DataSource，使用同一個播放實例，網易採用的是方案二。

第一天的最後一場演講來自解決方案專場的《5G時代超高清技術實踐與探索》，講師來自當虹科技，當虹科技脫胎於虹軟，是深耕廣電行業的一家公司。如果這場演講是在去年，你可能還覺得這裏會講4k，到了今年，已經是8k的世界了

相應的，5G也完全具備傳輸8k內容的能力

說到這裏，你可能還覺得都是老生常談，紙上談兵，根本沒有實際應用。那就來看看下面這張圖，反正我是挺意外的

視頻方面如此，音頻方面也有新的方向，尤其是全景聲的運用

基於以上背景，講師介紹了5G+超高清視頻時代的視頻處理建議：
第一點是多codec的支持，這一點不必多說，想想AVS3和AV1就明白了。
第二點是在生產端，會在全鏈路打通對超高清視頻處理的支持

第三點是AI技術在編解碼領域的應用，其實去年netflix的文章，還有這次大會的其他一些演講，都有提到這塊內容

第四點是超分辨率技術的應用，這也是一個從去年甚至前年就開始被廣泛討論的一個點

第五點是VR產業的第二春，這個我倒持懷疑態度。
第六點是HDR/SDR同播以及動態HDR的支持，這一點也是現在已經形成的趨勢。