H.264 或者說 MPEG-4 AVC 是目前使用最廣泛的高清視頻編碼標準，和上一代 MPEG-2、h.263/MPEG-4 Part4 相比，它的壓縮率大為提高，例如和 MPEG-2 相比，同樣的壓縮后畫面品質，h.264 的碼率通常只需要一半，這意味著存儲空間和網絡傳輸時間/帶寬大為節省。

h.264 是由 ITU-T Study Group 16 (VCEG) 和 ISO/IEC JTC 1 SC 29 / WG 11 (MPEG)這兩個組織共同合作制定的，除了提供相應的技術文檔外，他們還為業界提供了一個名為 JM Software 的 h.264 參考版編碼/解碼器，不過這個 JM Software 只是一個學術上的參考化實作（例如其他 h.264 編碼器弄出來的視頻流必須能被這個 JM Software 中的解碼器正常解碼出來），并非一個實用化的產品，所以無論是性能還是壓縮效果都比較一般，更多的只是證明 h.264 是可行的。

h.264 雖然擁有諸多出色的特質，受到大家的歡迎，但是它存在的授權金問題倒是讓不少廠商望而卻步。直到 2010 年面對 WebM 等新標準競爭和一些口頭威脅，MPEG 才正式宣布永遠免收基于 Internet 的最終用戶視頻授權金，至此以后各個視頻網站終于開始廣泛接納 h.264 作為最主要的網絡視頻編碼標準。

對于許多人來說，視頻編碼或者說視頻轉碼其實是息息相關的，視頻聊天、網絡視頻共享無不和視頻編碼有關，當然這其中視頻編碼的動作可能會被軟件巧妙的掩蓋起來，讓你不容易察覺。

在 2000 年科網股爆煲之前，就有不少網站開始大力推動網絡視頻，這時期的實時播放網絡視頻質量極差，很多時候只能看到人影晃動，連眼耳口鼻都分不清楚，體驗極差。隨著互聯網和硬件技術的提升，現在的網絡視頻甚至可以做到 4K 級別，可以說對于習慣于上網的人來說，網絡視頻已經是不可或缺的普通消費品。

h.264 雖然是目前最流行的網絡視頻編碼標準，但是它的運算復雜度一般要高于上一代的視頻標準（例如 h.263 或者說 MPEG Part4），這意味著對處理器的性能要求更高。有見及此，幾乎所有的嵌入式設備（例如手機等）中的處理器都會集成硬件化的 h.264 編解碼器，獲得性能/耗電上的平衡。

而在 PC 臺式機上，視頻編碼在較長的一段時間里被認為是專業領域的事，這時期的視頻編碼器硬件化或者說硬件加速都是局限于一些專業采集卡或者非編卡上。隨著網絡速度的提升，人們的交流、分享意識已經不再局限于以往的文本、圖片、聲音，各個硬件廠商開始重視這個變得越來越熱門的應用。

舉個例子，Intel 這幾年一直在推動的 WiDi 技術屬于一種實時有損壓縮無線顯示連接技術，能夠透過實時 h.264 壓縮將主機處理后的畫面透過 WiFi 無線網絡發送到支持 WiDi 的顯示器上。從市場角度而言，WiDi 當然算不上成功，但是它在利用視頻壓縮技術方面的確為我們提供了活生生的例子。

NVIDIA 這邊在 GTC 2012 上也展示了第二代的虛擬 GPU（VGX）技術，其中涉及到在 OSX、Android 等非 Windows 操作系統上提供 Windows 主機實時游戲畫面的技術，顯然就是利用了 Kepler 架構 GPU 中集成的 NVENC 硬件 h.264 編碼器，才能實現低延遲傳輸畫面。

h.264 提供了有損和無損兩種壓縮方式。其中的無損壓縮雖說是無損，但是由于 h.264 的色彩空間主要是 YUV（當然 h.264 也"可以"提供 RGB 支持）而非顯存中保存的 RGB 或者 sRGB 數據，這就涉及到色彩空間轉換問題。也就是說，如果需要把 Fraps 保存的視頻畫面轉換為 h.264 視頻的話，很難做到真真意義上的無損。

此外，目前并沒有支持無損壓縮的 h.264 硬件編解碼器，而且無損壓縮方式的壓縮率比有損方式低很多（一般需要每秒上百兆到數百兆的碼率），因此目前的 h.264 實際應用普遍還是采用有損方式。

既然都是用有損壓縮的話，那么衡量編碼器高低指標除了速度以外，還必須兼顧壓縮率，這里的壓縮率當然是同碼率下的壓縮后畫面品質，因為這事關網絡帶寬和畫面呈現的延遲問題。

對于普通玩家來說，除了網絡視頻對話外，還有把自己平時生活、玩耍的經歷制作成視頻或者是把一些機頂盒錄制的視頻傳輸到網絡上分享等常見用途，這時候如果編碼器的壓縮率更高的話，就意味著同樣畫質下的上傳的時間更短。

如何在壓縮性能和壓縮品質之間取舍？我們嘗試為大家進行一次量化的分析，希望能給各位帶來一點參考。

常見編碼器介紹——x264

雖然 Joint Video Team 做的 JM Software 是一個包含了編碼器、解碼器在內的免費源代碼開放軟件，但是由于速度實在慘不忍睹，所以在現實中沒有人會將其用于實際的編碼工作。

在 2003 年年底，法國人 Laurent Aimar 從零開始編寫一個名為 x264 的開源 h.264 編碼器。到了 2004 年年中，Laurent Aimar 被 ATEME 公司收編，自此以后，x264 的開發主導工作由 Loren Merritt 接管。如今 x264 的開發主要由 Loren Merritt、Jason Garrett-Glaser、Steven Walters、Anton Mitrofanov、Henrik Gramner 以及 Daniel Kang 進行，其中 Jason Garrett-Glaser 是 x264 的領銜開發者。

依照 Loren Merritt 在 2006 年發表的 x264 論文，當時的 x264 0.47.534 已經能在 5% 碼率差別和 50 倍速度的情況下，提供和 JM 編碼器 10.2 相當的 PSNR（一種最常使用的畫面品質評價指標）。

憑借開源、免費的優勢，目前 x264 已經成為各個壓片組的唯一 h.264 編碼器，大家在網絡上能下載的各類 h.264 視頻絕大部分都是由 x264 壓制的。不過與之相比的是，x264 在商業中的應用并不多，只有極少數的藍光節目視頻是用 x264 編碼，當然在現實中也許有不少“其他”編碼器可能或多或少參考了 x264，只是我們還不得而知。

由于 x264 是開源軟件，因此在這幾年里一直都有不同的編譯版本和修改版或者說分支，其中之一就是利用 OpenCL 這個 API 嘗試實現在 GPU 這類處理器上實現海量線程并行加速。對 x264 使用 OpenCL 進行硬件加速的嘗試有幾個項目，而在“官方”這邊，目前主要是針對 x264 中的 lookahead 操作模塊做硬件加速。

Lookahead 操作屬于 x264 中的一個復雜模塊，作用是對主編碼器模塊尚未分析的幀進行編碼成本估算。例如自適應 B 幀定位、顯式權重預測、受限緩存碼率控制（buffer-constrained ratecontrol）的位元分配等等，都會用到 lookahead 操作的結果。基于速度考量，x264 的 lookahead 是在一半分辨率上操作的，采用的是簡化版運動向量預測和幀間分析。

按照 Jason Garrett-Glaser（x264 首席開發員）和 Steve Borho（Mulricore Ware 方案架構師）在 AMD Fusion Developer Summit 2012 上的介紹，當時的 x264 OpenCL 在 Tahita（RADEON HD 7970）上達到兩倍性能，而畫面品質和 C 語言版 x264 相當。

雖然 OpenCL x264 有一定的性能提升，但是 x264“官方”認為這個東西目前還有很多地方未完善。即使是同一個 GPU 廠商提供的 OpenCL 驅動，也會出現不同版本有差異性，從而導致 OpenCL 程序出現無法執行的問題，因此并未將這個“部件”加入到正式版中。

目前有名為 x264pro 的第三方插件為 Adobe 軟件實現 x264 支持

x264 的官方版本是命令行執行文件，目前有許多其他的編碼器前端都把 x264 打包在自己的軟件包里，例如 MEncoder、MeGUI、MediaCoder 等，當然它們打包的方式不盡相同。

例如 MEncoder 是一個獨立的執行文件，x264 就包裹在這個單一的執行文件中，而 MEncoder 本身不僅僅包含有 x264。

MeGUI 則是一個圖形界面，x264 作為“工具”需要在安裝 MeGUI 后透過互聯網在線下載。

MediaCoder 也是一個圖形界面，它的 x264 似乎是 MediaCoder 作者自己修改編譯過的，x264 包含于 MediaCoder 安裝包里。

首先要說明，CUDA Encoder 和 NVENC 是兩個不同的東西，前者是采用 GPU 的通用計算單元進行編碼加速，后者則是增加了專門的硬線化編碼電路作編碼加速，不妨先回顧一下。

在 2008 年，一家名為 Elemental Technologies 的公司向業界推出了基于 CUDA 加速計算的視頻編碼器——Badaboom，可以在具備 Streaming Mulitprocessor 特性 1.1 的 NVIDIA GPU 上提供 h.264 編碼加速。

到了 2009 年，NVIDIA 公司開始在驅動中集成視頻編碼加速模塊，開發人員可以從 NVIDIA 開發者網站上免費下載相關的開發文檔資料調用這個加速模塊。

在這以后，軟件市場上出現了一大票的 CUDA 視頻加速軟件，例如：MediaCoder、Cyberlink Media Espresso、MainConcept CUDA h.264/AVC Encoder、ArcSoft Media Converter、DVDFab Video Converter、Tipard Video Converter、Freemake Video Converter、WinAVI Video Converter、4Videosoft Video Converter、Expression Encoder 4 Pro SP1、Leawo Total Media Converter 等等，這就不一一列舉了。

在今年發布的 Kepler 家族 GPU 中，NVIDIA 集成了專用的 h.264 硬件編碼器——NVENC，這和之前的 CUDA 編碼器有很大的不同，因為之前的 CUDA 編碼器是由 GPU 的通用計算執行部分 h.264 算法來實現加速。而 NVENC 則主要由專門為 h.264 算法定制的硬件單元來執行編碼操作，主要的好處是在進行編碼操作的時候性能/耗電比要比 CUDA Encoder 高很多。

就目前所了解，NVENC 的細節資料并未完全公開，NVIDIA 只是告知大家 NVENC 能實現 4K 分辨率、支持 h.264 High Profile 4.1、3D 視頻流壓縮。

迄今為止，支持 NVENC 的編碼器只有 Cyberlink 的 Media Espresso 轉碼器媒體測試專用版。

NVIDIA CUDA Encoder 推出后曾經引起了不少的轟動，不過 Intel 方面倒是表現得很淡定，因為就他們的研發實力而言，完全有能力在下一代產品中推出具針對性的產品，回敬 CUDA Encoder 的答案就是在 Sandy Bridge 架構 CPU 中引入了的 MFX（Multi-Format Codec Engine，多格式編解碼器引擎）視頻處理引擎。

第一代 MFX 是從 Sandy Bridge 上引入的，現在的 Ivy Bridge 和下一代的 Haswell 也分別具備第二和第三代 MFX， Ivy Bridge 的第二代 MFX 主要是改進了性能，而 Haswell 的第三代 MFX 除了速度比?Ivy Bridge 更快外，在同碼率畫面品質方面也會有 11% 的改進。

MFX 包含了解碼器、編碼器和視頻效果處理器三部分，其中編碼器屬于二工位混合式的硬件編碼器。

Intel 將編碼器的動作分為兩組，即 ENC 和 PAK，其中 ENC 包括了碼率控制、運動估算、幀間估算、模式抉擇；而 PAK 包括了運動補償、幀間預測、前向量化、像素重構、熵編碼。

ENC 操作由 GPU 的可編程 EU 矩陣執行，PAK 則是 MFX 的硬件流水線執行，兩組動作對不同的幀同時執行，可以藉此達到最高性能。

MFX 令人印象深刻的還有它的解碼器性能。例如我們測試的 16 分鐘 1080p 片段，在基于 GF110/GF104 的 GTX 580/GTX 560 Ti 上解碼性能為 94.2 fps，基于GK104 的 GTX 680 是 158fps，而在 Sandy Bridge/ Ivy Bridge 的 i7-2600K/3770K 上解碼性能居然分別高達讓人瞪目乍舌的 460fps、606fps。

硬件解碼性能的強大，除了說明 GPU 能應付更復雜的視頻解碼外，還意味著可以在轉碼的時候更多地解放 CPU 負荷。

現在的情況可能還是有些尷尬，因為 NVIDIA 的 NVENC、AMD 的 VCE 目前都屬于專用 API 階段。換句話說，只有極少數簽署了保密協議的軟件廠商獲得了軟件開發資料。

故此，目前所見只有特定版本的 CyberLink Media Espresso、ArcSoft Media Converter 提供了 NVENC、VCE 支持，ArcSoft Media Converter 我們目前還無法獲得，而支持 NVENC 的 CyberLink Media Espresso 版本還不支持 VCE。

實際上這些專用 API 對應的轉碼器目前基本沒公開過，只是曾在 AMD 或者 NVIDIA 的 ftp 上提供下載，因此這次測試缺乏AMD的VCE 的對比。

不過隨之而來的另一個問題是，我們這次要做的是量化測試，除了速度外，還包括畫面品質。

Media Espresso 缺乏隨意定制的碼率設置，它只是依據分辨率提供幾個“經驗”上認為達到一定品質所需的幾個碼率選項。例如 1920x1080p24，最低碼率是 6Mbps，然后是 8Mbps、10Mbps、13Mbps，缺乏足夠的可定制性。

為了制作 RD （碼率-失真度或者說率失真）曲線，我們需要可以自定義碼率的編碼器，不過能支持 NVIDIA NVENC 或者 AMD VCE 的軟件目前都不具備此能力，因此 RD 曲線部分只能在 x264、CUDA encoder、Intel QuickSync 上提供。

我們使用 MeGUI 執行 x264、MediaCoder 執行 CUDA Encoder/Intel QuickSync 的編碼結果來繪制 RD 曲線，測試片段為電影《飛砂風中轉》中的一個 16 分鐘片段，分辨率為 1920x1080p24，碼率從 1000Kbps 到 9000Kbps，碼率控制模式為恒定碼率，步進為 1000Kbps（從實用角度而言 1000Kbps 步進是略顯大了些，但是繪制 RD 曲線的話是足夠的了）。

上圖就是我們的 MeGUI 采用的 1PASS Max Speed 預配置（源自 Doom9.org 的 Sharktooth，你可以在這里：http://forum.doom9.org/showthread.php?t=139765 下載并導入到 MeGUI 內）。不過我們做了一些簡單的更改，包括 AVC profile 設置為 High Profile、Level 設置為 4.1、Target Playback Device 為 DXVA，編碼模式為 ABR（平均碼率），而 x264 自身的預配置保持不變（即采用 Medium），啟用了 CABAC，deblocking 各向設置為 0。

從畫面品質角度考慮的話，這個設置對 x264 來說當然是暴斂天物（沒能充分壓榨 x264 的壓縮率），但是我們在這里希望的是在盡可能快的速度下進行編碼然后和 CUDA Encoder、Intel QuickSync 這類硬件加速的編碼方案對比，所以速度在這里是我們必須考慮的。

我們為了方便探究一下在偏向畫面品質較佳的情況下，x264 能做到什么樣子，例如上圖我們采用了 CRF=18 的 1pass fast 預設置壓片，由于 CRF 模式是依據特殊的經驗判別（這個操作被稱作 RDO（率失真優化），在 JM 中是采用誤差方差和（即 SSE）或者絕對誤差和（即 SAD）等均方誤差（即 MSE），x264 提供了 PSNR、SSIM 等多種導向優化模式）方式來判斷每幀畫面的碼率，力求各幀畫面的品質基本保持在同一水平，因此這個模式下的碼率是不確定的。

根據我們的測試，在 CRF=18（CRF 值越小畫面品質越高，0 的話對于 YUV 色彩空間視頻來說相當于無損模式，但是從壓縮率角度看，CRF 小于 18 基本上沒有意義） 的時候，壓出來的片段碼率在 7.5Mbps 左右。

從專業角度而言，MeGUI 是一個出色的 x264 圖形界面，但是因為涉及到 Avisynth 腳本，使用上需要有一定經驗。

作為國產軟件，MediaCoder 是第一個實現批量 CUDA 硬件加速編碼的軟件包，它有非常不錯的圖形界面，CUDA 硬件加速編碼器的各種高級選項都能直接訪問。

在今年三月份，MediaCoder 也實現了基于 Intel QuickSync 硬件編碼的支持，界面同樣非常友好，能直接支持 Sandy Bridge、Ivb Bridge 的硬件解碼、編碼模塊實現轉碼加速。

MediaCoder 兼具專業、易用性于一身，同時提供了最新技術的支持，是頗具使用價值的軟件，我們希望 MediaCoder 能在 NVIDIA 年底的 NVENC SDK 發布后也一并提供相應的支持。

Cyberlink 的 Media Espresso 是常見的商業化編碼器軟件之一，提供了 CUDA Encoder、Intel QuickSync 等硬件加速支持，此外目前有特別的媒體版實現了 NVENC、VCE 支持，不過 VCE 版本目前尚未得見。

Media Espresso 雖然是商業軟件，但是它有多個方面都存在不足，例如缺乏幀精確、全定制的碼率設置、更深入的編碼器參數設置，對于有一定經驗的用戶來說，它和許多開源軟件相比是比較令人失望的。

畫面品質評價可以分為主觀和客觀兩種，像單盲、雙盲都是屬于主觀方式，不同人的感觀和接受度都可能會得出不同的評價結果；而客觀方式則是需要一些數學的手段來進行評估，只要算法、圖片一樣，拿到任何一臺電腦上計算出來的指標都是一樣的。

不過量化對比本身不是萬能，它有一些缺陷。我們這里既然要進行畫面品質的量化對比，自然需要借助一些工具和客觀的指標。

目前評價畫面品質的最常見保真度指標就是 PSNR 和 MSE，這里 PSNR 是峰值信噪比的英文首字母縮寫，MSE 是均方差的英文首字母縮寫，之所以這兩個指標最常見是因為方程式比較簡單，能快速計算。

但是 PSNR 是簡單的基于對數據的逐個字節對比而不考慮這些數據呈現的是什么，對像素的空間關系完全沒有判別能力，無法反映出人類視覺系統對復雜畫面差別的感知。

上圖是一篇論文中的圖片，它們的 PSNR 值都一樣，但是以我們人類驟眼看來，圖 A 的畫面才是合理、正確的，圖 B 則存在明顯的瑕疵。如果仔細看的話，可以看到圖 A 的水面噪點相對較多，類似這樣的情況就是導致存在大塊瑕疵的圖 B 在 PSNR 值上和圖 A 相當的原因。

簡而言之，PSNR 值對我們人類來說有時候是不能反映主觀視覺感觀的，甚至完全不著邊際，而且不同視頻源、畫面源的 PSNR 絕對值并不能對等地反映畫面品質。例如不同畫面源的處理后，畫面PSNR值如果都是30dB ，并不代表視覺感官上它們的效果接受度都是一樣的，可能一個較差，一個較好。

MSE 的情況類似，事實上它是 PSNR 的底子，所以對塊狀的敏感度不如噪點的敏感度高。也就是說，一張加上了少量噪點的處理后畫面在 MSE 值上可能會低于有若干塊狀瑕疵的處理后畫面，但是從人類的角度看，少量噪點的畫面往往在感官上看上去比塊狀瑕疵的畫面更好。

在 2004 年，Zhou Wang 等人提出了一種基于結構相似度的圖像質量評價方式——SSIM，SSIM 認為光照對于物體結構來說是獨立的，亮度和對比度的變化會造成光照的改變，因此可以將亮度和對比度從圖像的結構信息中分離出來，然后結合結構信息對畫面質量進行評估，就能得出接近于人類視覺系統的畫面品質評價指標。

SSIM 值是一個固定范圍內的小數，即 0 至 1，數值越高意味著畫面質量越高，在畫面質量相等的時候，SSIM=1，完全不相關的話，SSIM=0。SSIM 問世后，由于復雜度較低、具有很強的實用價值，引起了許多科研人員、開發者的關注，許多論文、應用都引入了 SSIM 或者變種。

我們這里說的圖像質量評估方式都是在有參考圖像的情況下進行的，和 PSNR 不同的是，SSIM 的絕對值相對 PSNR 來說更具參考意義，例如在視頻畫面質量評估中，一般認為 SSIM=0.95 意味著畫面質量可接受，而 SSIM = 0.98 的話畫面效果具有欣賞價值。

當然，因為 SSIM 值是基于參考圖像的評估方式，有些時候并不能反映人類視覺對畫面質量的主觀感受，例如我們對畫面做一些銳化之類的處理，從人類視覺系統角度而言處理后的畫面可能會有時候差一點、有時候可能會好一點，但是 SSIM 值此時未必和我們的主觀感受一樣，這也是各種客觀圖像量化對比指標的缺點。

我們這里做的視頻畫面質量對比，在壓縮的時候沒有做除視頻壓縮外的后處理（例如我們的畫面都是 1080p，不需要作反交錯，也不需要做色彩空間轉換），此時 SSIM 還是非常適于用這樣的場合。

現在有多種現成的工具能實現視頻畫面的 SSIM 對比，例如 x264 本身內建了 SSIM 值計算、Avisynth 有 SSIM 插件、莫斯科國立大學（MSU）的 MSU Video Quality Measurement Tool 等。

依據 AVISynth 的 SSIM 插件能很方便的計算出某幀畫面的 SSIM 值
上圖上半部分是片源（1080P），下半部分是 CUDA 1Mbps 壓縮后畫面

我們對比的片段是電影《飛砂風中轉》中的一個 16 分鐘左右的片段全部畫面（大概兩萬多張畫面），而非單獨的某幀畫面，這就要求我們要做到幀精確的對比（否則的話會相當麻煩）。

因此在對比前，我們都要對源視頻和處理后的視頻做索引化，除了 Media Espresso 壓制出來的 Intel QuickSync 缺少后面的幾幀畫面外，都能實現 100% 的精確幀序對應。需要注意的是 Media Espresso 必須使用 .m2ts 封裝才能實現正確的畫面幀序，如果是 mp4 封裝的話，前 100 幀畫面會出現幀序不精確問題。

人類在判斷視頻品質的時候往往對整段視頻中極少量的低品質畫面非常敏感
上圖是我們用若干個百分位數繪制的分布圖
百分位數是指將各幀依照 SSIM 值從大到小排列
然后統計在某個 SSIM 值上有百分幾的幀是位于該值之下

可以看到，基于 NVIDIA CUDA Encoder API 進行恒碼率編碼的 1000Kbps 畫面品質最低，達到了 SSIM=0.56xx 的水平，30% 的幀低于 SSIM=0.95 可接受畫面品質指數。

到了 2000Kbps 后，SSIM<0.95 的幀數下降到了大約 7% 以下，但是依然有 80% 的幀低于具欣賞價值的 SSIM 0.98。

當碼率達到 9000Kbps 后，CUDA Encoder 壓縮出來的幀有 12% 以下是不足 0.98 SSIM，換句話說，此時有 88% 左右的幀是具欣賞價值的。

需要多少碼率才能做到 50% 的幀具有欣賞價值（SSIM>=0.98）呢？從百分位比分布圖可以看出，答案是 5000Kbps。

和 CUDA Encoder 相比，基于 Intel MFX 引擎的 QuickSync 在低碼率（1000Kbps）時的表現相對來說沒有那么多的下探，而且下探的幅度要小很多（最低處的 SSIM 值為 0.8216，較 CUDA Encoder 的 0.56xx 高出很多）。

那么在最糟糕（SSIM 值最低）的情況下，實際觀感上和 CUDA Encoder 有怎樣的區別呢？先讓我們用 CUDA Encoder 1000Kbps 下最糟糕幀序的畫面來對比看看：

上：原片
中：CUDA Encoder 1000Kbps
下：Intel QuickSync 1000Kbps
如果你需要無損圖片，請將大圖后綴名稱修改為 png 即可

正如你所看到的那樣，在同一幀下 SSIM=0.8733 的 Intel QuickSync 壓縮效果要比 CUDA Encoder 好得多，瀝青路面的肌理、灰屑（這個是什么灰？看過電影的人應該很清楚）表現都有相對不錯的細節，不過仍然存在一定的斑駁，而且在色彩上存在明顯偏紅的情況。

現在再讓我們來看看同樣碼率下 Intel QuickSync SSIM 值最低的幀（第 18020 幀）畫面表現又如何。

上：原片
中：CUDA Encoder 1000Kbps
下：Intel QuickSync 1000Kbps
如果你需要無損圖片，請將大圖后綴名稱修改為 png 即可

CUDA Encoder 畫面中的紙人面目可辨認度基本上和 10 年前實時網絡視頻效果差不過——眼耳口鼻幾乎都糊在一起了，而中間偏上的紅色物體則是 CUDA Encoder 似乎更好。如果從 SSIM 值來看，CUDA Encoder 是略微高一些，但是驟眼看上去的話，我想不少人會說 Intel Quick Sync 效果要好一些，這說明 SSIM 雖然在客觀指標上的可信度已經比較高，但是它畢竟不是完全基于人類視覺系統的畫面品質評價指標，有時候它的值并不能充分體現我們肉眼所見感觀。

和 Intel QuickSync 相比，x264 采用 MeGUI 的 1pass Max Speed（單次最高速）壓縮預設在低碼率（1000Kbps）上的表現要好很多，波動程度和 Intel QuickSync 2000Kbps 的時候相當。

如果從百分比數分布圖來看，x264 只有大約 3.5% 的幀是低于 SSIM 0.95，而前面的 Intel QuickSync 是大約 5% 的幀低于 SSIM 0.95，在這個檔位之下的低品質幀數縮小對于人類欣賞一整段視頻來說是有比較明顯的感官差別。

上：原片
中上：CUDA Encoder 1000Kbps
中下：Intel QuickSync 1000Kbps
下：x264 1pass maxspeed 1000Kbps
如果你需要無損圖片，請將大圖后綴名稱修改為 png 即可

上圖 x264（MeGUI 1 Pass MaxSpeed 預配置）1000Kbps 中最低 SSIM 值的截圖以及和原圖、CUDA、Quicksync 的對比。

從我個人的主觀判斷來看 Quicksync 和 x264 在細節度上的差別并不大，但是 x264 存在偏紅的問題，如果從 U、V（YUV 色彩空間的兩個色度）通道來看，此外它的色度 SSIM 值不如 CUDA（CUDA 的色度通道 SSIM 值在這一幀中是最好的）。

從平均 RD（碼率-失真）曲線來看，表現最好的是 Intel Quicksync，它在 1000Kbps 的低碼率設置下就能做到 SSIM >0.97，基本上都能比 x264 + MeGUI 1pass max speed 預配置高 0.01 個 SSIM 值。

表現最糟糕的是 NVIDIA CUDA Encoder，在 1000Kbps 低碼率設置下，它只能做到 0.95 些微高一點的 SSIM 值，而且依據我們之前的百分位數來判定的話，它有 30% 的幀是低于 0.95，大約 8% 的幀是低于 SSIM 0.9。

從曲線趨勢來看，CUDA Encoder 需要不低于 4500Kbps 才能做到平均 SSIM 0.98，而 Intel Quicksync 大概是 3200Kbps，x264（1pass maxspeed preset）大概是 3500Kbps。

這意味著什么？說明如果你要上傳壓縮后的視頻到網絡上，CUDA Encoder 需要比其他兩個對手多 40% 以上的時間（我們會在稍后對這個問題做更多的討論）。

目前只有 Media Espresso 的特殊版本能提供 NVIDIA Kepler 所集成的 NVENC 執行硬件編碼加速，但是這個軟件缺乏任意定制的碼率設置以及其他高級選項，而且必須采用 mt2s 封裝才能實現幀序精確。

這次的對比我們添加了采用 x264 + MeGUI 1pass fast CRF=18（平均碼率為 7.4Mbps）的 SSIM 值曲線圖來和 Media Espresso 采用各種硬件加速模式的曲線圖作對比。

從對比圖來看，NVENC 的波動幅度和 x264 CRF=18 接近，那么它們的百分位數表現又是如何呢？請繼續往下看。

首先，我們希望能找一個對比的基準，例如一個這次測試中軟件編碼效果最佳的例子來做對比。

在 Media Espresso 和 MeGUI 中我們采用軟件模式進行編碼，其中 Media Espresso 采用 6000Kbps 和 8000Kbps，而 MeGUI 采用 1pass fast cf=18 預配置，統計錄得的 SSIM 值百分位數（1% 到 99.9% 區間）結果如下。

x264 crf=18 展現出了驚人的實力，大約只有 2% 的幀是低于 0.98，并且 1% 或者以上的幀 SSIM 值都高于 0.979，可以說此時整段片段和原片相比都很難覺察到瑕疵，而碼率代價則是 7.4Mbps，相較 Media Espreso 8Mbps 而言，這樣的壓縮率當然是讓人相當佩服的。

在使用 Core i7 2600K 設置為 3.8GHz 時， x264 1Pass fast CRF18 的壓縮速率為 28.84 fps（avisynth 腳本中的原片 ffms 索引+解碼線程為 3 線程），相當于 1.2 倍速的編碼速度。

在硬件編碼中，百分位表現最好的是 NVENC（NVIDIA Kepler 家族人手一份），8000Kbps、6000Kbps 時候分別大約有 92.5%、89% 的幀是高于 SSIM 0.98，而 Intel Quicksync 在這方面的數字則分別是 83%、79%，CUDA 是 81%、68.5%。

NVENC 和 x264 CRF18 相比,在 35%左右以下的幀數是不敵的，但是在這往后就顯現出一些優勢，但是這些優勢由于是在 SSIM 0.985 以上的，肉眼很難察覺，所以這也體現出了 x264 crf 模式在碼率控制上的強大優勢——也就是可以更智能地將碼率作合理分配。

在這次測試中，我們盡可能地使用目前認為最佳的客觀量化指標以及百分位數等統計手段，來衡量來自 Intel、NVIDIA 以及開源社區目前最成功的編碼器，測試了多種 h.264 編碼器前端，部分由于軟件功能等原因沒有在文中給出，例如 Mainconcept 的 TotalCode for Adobe Premiere Pro（由于缺乏 NVENC 支持而且往往壓出來的片段和設定的碼率有很大出入）、ArcSoft Media Converter（功能上和 Media Espresso 幾乎一樣，而且似乎存在兼容性問題）等。

我們使用一段 16 分鐘左右的 1080p 視頻在不進行任何后處理的情況下進行視頻壓縮處理（壓出來的片段不下 50GB，接近 50 段視頻），然后對各幀畫面（兩萬張以上） SSIM 指標進行統計、繪制曲線圖，依據整段視頻中出現極少量的劣質畫面也會嚴重影響欣賞體驗的原則，對全部幀進行排序統計出百分位，為大家勾勒出各類編碼器的客觀畫面品質體驗指標。

從測試結果來看，硬件編碼器中，在中級（6000Kbps）以上碼率表現最好的是 NVIDIA NVENC，其次是 Intel Quicksync，最差的是 NVIDIA CUDA Encoder。

由于 NVIDIA 目前并未開放 NVENC 的軟件開發包，只有一家公司提供了基于 NVIDIA 專有協議的編碼器前端（Media Espresso），而這個軟件缺乏足夠的定制性，因此使得這次測試有些別扭，無法實現繪制 NVENC 的 RD（碼率-失真關系）曲線圖。

按照我們在 MeGUI 和 MediaCoder 這兩個前段壓縮的 x264、CUDA、Intel Quicksync 片段 RD 曲線來看，CUDA 需要比 Quicksync 多 40% 的碼率才能讓平均 SSIM 值達到相當的水平。

如果我們將 x264 1pass maxspeed 8Mbps 的畫面品質設定為參考指標的話，此時的 SSIM 平均值是 0.9845，Quicksync 要達到同樣的 SSIM 均值所需要的碼率是 7.5Mbps，而 CUDA 則同樣是 8Mbps，Quicksync 此時所需要的傳輸時間可以縮短 6.25%。

對于我們使用的測試片段，Quicksync 7.5Mbps 的文件大小是 828MB 左右，以 2Mbps 的家用光纖寬帶上傳，可以在 3300 秒或者說 0.92 小時左右完成上傳。

Intel Sandybridge 和 Ivybridge 架構搭載的 MFX 視頻引擎在編碼速度上是不同（但是畫面品質一樣）的，后者的編碼速度提高了 50%左右，以我們采用 MediaCoder 為例，2600K 的編碼速率是 4.65 倍，3770K 是 6.55 倍，時間上衡量的話，分別是 210 秒 和 150 秒。

假設是在 3770K 上采用 Quicksync 編碼然后采用 2Mbps 光纖上傳到互聯網上，所需要的全部時間則是 3510 秒左右，即 0.975 小時。

而 CUDA 8Mbps 這邊的編碼+上傳時間是 3730 秒 + 224 秒 = 3954 秒，或者說 1.098 小時，比 Quicksync 多 12.6% 的時間。

NVENC 的畫面品質比 Intel Quicksync 更出色一些，不過速度方面需要比 Quicksync 多大概 50% 的時間（Media Espresso 中，同樣的軟件中 CUDA 需要的時間是 Quicksync 的兩倍，和 MediaCoder 中的速度差別有些不同）。

總括而言，這次測試表明 Quicksync 在畫面品質和速度上目前取得了不錯的平衡，而 NVENC 如果能在 MediaCoder 這類編碼器前端上或得支持（NVIDIA 目前尚未公布 NVENC 的開發包）的話，應該也有不錯的潛力。

x264 這邊目前雖然有一個“半官方” OpenCL 的 lookahead 操作優化版，但是畢竟 h.264 當初設計的時候對多線程加速執行各類操作欠缺考量，實際的速度改變不會有硬件編碼器這邊那么明顯，更多的是一種嘗試性質。

新的 h.265 雖然尚未出臺正式規格，但是依據目前的消息，h.265 將會考慮到多線程的優化，屆時 OpenCL（目前的 OpenCL 對許多開發人員來說還處于挑驅動的階段）也將更加成熟，相信異構計算將會在 h.265 上展現出更多的優勢。