VP9編碼：迄今的嘗試

文 / 常謙

原文連接 / https://blog.hotstar.com/vp9-...

圖片源於Unsplash上Tim Mosholder拍攝

兩年前，咱們開始在點播內容中使用VP9編碼，而且觀察到它在視頻質量和碼率這兩方面比H264有明顯的提高。但與此同時，咱們也遇到了一些挑戰，今天在這裏跟你們討論一下。

探索

咱們使用的VP9編碼器是libvpx。在新的編碼服務上線一段時間後，咱們發現經過添加一些特徵保留過濾器，視頻主觀質量變化不大卻能編壓縮得更小一些，。讓咱們在分發一些流行節目分發中時明顯地節省帶寬成本。

咱們還發現，一些VP9編碼的內容在某些具備高動態場景和黑暗場景的內容上效果不盡如人意，所以咱們決定暫停這類內容的VP9編碼。而後咱們發如今某些內容的mpd文件中，240p分辨率的峯值碼率高於360p分辨率。因爲上述問題，咱們暫停了VP9編碼，並更深刻地進行了分析和調查。最後，咱們提出了VP9編碼的改善方案。

編碼

在這一部分中，咱們將討論兩個在網絡論壇上不常討論的問題：2pass碼率控制和多線程編碼速度瓶頸。

碼率控制方式

與x264相似，libvpx有1pass ABR，穩定質量，2pass ABR和帶碼率限制的穩定質量碼控方法。

libvpx碼率控制方法

在x264編碼中，常常會使用帶峯值碼率限制的CRF。而在libvpx CRF模式下，編碼器會嘗試達到穩定圖像質量，同時將平均比特率保持在比特率限制限制在目標值如下。

這與x264 CRF的速率碼率控制方法不一樣。在x264中，咱們可使用VBV buffer和VBV maxrate實現編碼輸出碼率峯值碼率的控制，從而能夠直觀地調節設置DASH mpd文件中各分辨率的峯值碼率高低。可是在libvpx CRF模式下沒有這些選項，僅能夠限制輸出的平均碼率，因此這意味着DashDASH mpd文件中各分辨率峯值碼率是不肯定的。在HLS/DashDASH自適應碼率切換中，峯值碼率是重要的參考依據。高分辨率視頻峯值碼率越高，其播放的頻率越低少。

另外一件不多被說起的事情是，咱們能夠在CRF編碼中使用2pass。因爲1pass CRF在x264中獲得了普遍使用，所以一開始咱們並無嘗試在libvpx中使用2pass CRF。然而，2pass CRF在libvpx中的性能比1pass CRF好得多。它能夠提升某些複雜場景的質量。咱們將在稍後討論細節。

多線程編碼速度

對於VOD編碼來講，咱們傾向於使用慢速設置的方式slow preset以得到更好的質量和更小的體積。在x264 / x265中，咱們可使用10個或更多線程來加速1080p視頻的編碼。可是，咱們不能沒法在libvpx中使用那麼多線程，並且在slowpreset預設下，1080p VP9編碼時間比x264長得多。

通過一些瞭解後，咱們發現libvpx可使用的最大線程數與tile數量有關。最大tile數又取決於分辨率。下表顯示了各分辨率的最大tile。

VP9各分辨率的最大tile

對於1080p內容，圖像視頻寬度爲1920像素，最大tile僅爲4。所以libvpx1080p的編碼速度成爲了咱們VOD服務的瓶頸。幸運的是，libvpx v1.7中引入了-row-mt選項，較以前版本有較大提高。可是對於須要快速上線的視頻內容來講，libvpx仍然不能知足咱們的要求，所以咱們須要GOP級別並行化來進一步加速。

Packaging HLS/DashDASH打包

選擇Bento4仍是Shaka打包？

Bento4用做H264 / H265 的HLS / DASH打包中很是流行。但對於VP9來講，咱們還有一個選擇：Shaka Packager。在選擇之初咱們進行了一些調研，在Bento4官方討論中，其開發人員提到Bento4專一於基於ISO標準的各種流格式，而Webm不屬於這一類。此外，咱們嘗試Bento4生成一些VP9 + AAC流，卻沒法在咱們的Chrome瀏覽器中正常播放和運行。相反，Shaka Packager能夠涵蓋咱們全部的使用場景。所以，咱們決定在VP9打包封裝中使用Shaka Packager。

Shaka Packager能夠輸出VP9 + AAC編碼的fMP4 DASH流和VP9 + Opus編碼的Webm DASH流。它也能夠很好地支持AV1 + AAC和AV1 + Opus。

在默認狀況下，Shaka Packager還會啓用動態MPD。它能夠大大提升客戶端下載和CDN上傳的速度，從而使咱們的文件管理更容易。

Webm仍是fMP4？

如上所述，咱們能夠將Webm或fMP4用於VP9視頻。不幸的是，根據Shaka Packager官方文檔，Opus對ISO-BMFF的支持仍處於試驗階段。因此一開始咱們選擇了帶有VP9+Opus編解碼器的Webm容器。在發佈幾個月後，咱們分析發現，相對於H264節省的總流量是低於咱們的預期的。

Shaka Packager支持的容器格式和編碼

通過實驗，咱們發現Webm容器封裝後產生了大約20–30kbps的開銷。這對於高分辨率視頻影響不大。可是對於180p視頻，若是音視頻的比特流爲100kbps，則轉換爲fMP4 DASH格式後的大小約爲102kbps。可是，當咱們將其轉換爲Webm DASH格式時，它的大小約爲120–130kbps。Webm容器中的開銷多了約爲20kbps，對於低分辨率內容來講仍是太大。所以，咱們決定在將來使用fMP4容器。

將fMP4容器與VP9 + AAC編解碼器一塊兒使用的另外一個優勢是易於維護多種編碼格式的視頻。咱們一般會先爲每一個內容編一份H264+AAC的流，若是VP9也適用AAC編碼，咱們直接能夠把已編好流的AAC音軌複製或連接到VP9 MPD文件，而無需從新編碼音頻。每次咱們收到某個一種內容的新語言音頻時，咱們只須要處理一次（AAC，fMP4）並將該音軌複製或連接到多個視頻格式的流 (H264/H265/VP9) 中。這樣咱們並不須要考慮其餘音頻編碼（Opus）格式的處理。

咱們的改進

回到前面的問題，以前咱們發現某些MPD文件中360p峯值碼率值低於240p。這對播放行爲形成了流乾擾，致使以至當網絡變好時候，某些用戶反而從360p切回240p。此外，以前的VP9編碼在某些一些複雜場景下的圖像質量較差不理想。通過一些實驗，咱們發如今上述狀況下2pass CRF的表現比1pass CRF好得多。

下圖是咱們對同一視頻進行2pass CRF與1pass CRFVP9編碼的比較。它們使用相同的CRF值和碼率限值。咱們能夠看到1pass CRF的MPD峯值碼率依次爲350kbps、500kbps、450kbps、650kbps，在240p附近出現了一個異常點。相反，2pass CRF MPD峯值碼率隨着分辨率單調增長，是合理的。

DASH文件中各分辨率峯值碼率(kbps)

咱們還計算了2pass CRF和1pass CRF輸出的VMAF值。對比結果以下:

從以上數據能夠看出，2pass CRF在輸出質量上更穩定，在複雜場景下表現更好。

VP9真的過期了嗎?

人們可能會說，咱們已經有了HEVC和AV1編解碼器，爲何咱們還須要VP9，是否是已通過時了？除了節省成本外，VP9目前至少還具備如下優勢。

首先，Chrome類瀏覽器不支持HEVC解碼，而VP9內容視頻能夠經過使用硬件加速在一些主流設備上播放。

其次，HEVC和AV1內容在一些低端Android設備上沒法很好地播放。對於1080p+或膠片噪聲視頻，VP9的性能接近HEVC，。在某些狀況下，VP9的性能有時甚至優於HEVC。

最後，VP9的當前編碼成本比AV1低得多。與AV1相比，VP9能夠節省不少編碼時間和計算成本。對於觀看時間不長的視頻，AV1多碼率編碼帶來的成本增長可能會比AV1其節省的流量費用還要多。在這種狀況下，VP9多是更好的選擇。

總結

在此博客中，咱們帶領您體會分享了咱們從VP9入門到如今的過程，介紹了咱們遇到的挑戰以及爲改善最終用戶體驗而開發的解決方案。就像咱們在Hotstar所作的一切同樣，這些學習經驗成果正在被應用借鑑到咱們其餘視頻編解碼器，平臺和場景中。

咱們的團隊一直在探索新的創新方式，以不斷提升咱們在音頻、視頻處理和交付各個方面的性能和效率。