被稱為“多媒體技術(shù)領(lǐng)域的瑞士軍刀”，F(xiàn)Fmpeg擁有廣泛的應(yīng)用基礎(chǔ)。不過，當(dāng)（實(shí)時(shí)）處理海量視頻時(shí)，需要借助各種方法提升效率。比如，短視頻平臺Revvel將視頻轉(zhuǎn)碼服務(wù)遷移到AWS Lambda和S3上，節(jié)省了大量費(fèi)用和運(yùn)維成本，并且將時(shí)長2小時(shí)的視頻轉(zhuǎn)碼從4-6小時(shí)縮短到不到10分鐘。本文將縱覽FFmpeg的硬件加速方案，涉及各主流硬件方案和操作系統(tǒng)。本文為此系列的下篇，上篇請?jiān)L問這里。感謝英特爾資深軟件開發(fā)工程師趙軍的投稿。

文 / 趙軍

Android: MediaCodec

MediaCodec是Google在Android API 16之后推出的用于音視頻編解碼的一套偏底層的API，可以直接利用硬件以加速視頻的編解碼處理。MediaCodec的概念中，一般而言，編解碼器處理輸入數(shù)據(jù)并生成輸出數(shù)據(jù)。它異步處理數(shù)據(jù)并使用一組輸入和輸出緩沖區(qū)。在簡單的層面上，需要請求（或接收）一個(gè)空輸入緩沖區(qū)，填充數(shù)據(jù)并將其發(fā)送到編解碼器進(jìn)行處理。編解碼器使用數(shù)據(jù)并將其轉(zhuǎn)換為其空的輸出緩沖區(qū)之一。最后，你請求（或接收）一個(gè)填充的輸出緩沖區(qū)，消耗其內(nèi)容并將其釋放回編解碼器。

MediaCodec可以處理的數(shù)據(jù)有以下三種類型：被壓縮的Buffer（Compressed Buffers）、原始音頻數(shù)據(jù)(Raw Audio Buffers)、原始視頻數(shù)據(jù)(Raw Video Buffers)?？梢允褂肂yteBuffers處理所有三種數(shù)據(jù)，但一般應(yīng)該使用Surface以提高編解碼器的性能。 Surface使用本地視頻緩沖區(qū)，無需映射或復(fù)制到ByteBuffers; 因此，效率更高。 通常在使用Surface時(shí)無法訪問原始視頻數(shù)據(jù)，但可以使用ImageReader類來訪問不安全的解碼（原始）視頻幀。 這可能比使用ByteBuffers更有效率，因?yàn)橐恍┍緳C(jī)緩沖區(qū)可能被直接映射到ByteBuffers。 當(dāng)使用ByteBuffer模式時(shí)，也可以使用Image類和getInput / OutputImage（int）訪問原始視頻幀。FFmpeg自3.1版本加入了android MediaCodec硬件解碼支持，其實(shí)現(xiàn)Follow了FFmpeg的HWaccel接口，但直到現(xiàn)在為止，F(xiàn)Fmpeg都并未支持基于MediaCodec的硬件加速編碼。

1.基于Chip 廠商的私有方案

這里所提及的私有，并非是說代碼沒有Open，更多層面上是指所提供的相應(yīng)的API接口和實(shí)現(xiàn)，是廠商所特定的，而非行業(yè)標(biāo)準(zhǔn)定義的API ，諸如OpenMAX或者OS層面剝離了硬件具體實(shí)現(xiàn)相關(guān)抽象的API。更進(jìn)一步說，是采用相關(guān)廠商私有方案之后，如果想要二次深度開發(fā)，其困難度較大一些。實(shí)際上，從開放的角度而言，Intel，AMD，Nvidia這3家GPU大廠所提供的方案的Open 程度不盡相同，總的說來，其開放程度是Intel好于AMD, 而AMD又好于Nvidia。

Intel: Media SDK:

Intel提供的Media SDK，本質(zhì)是一套跨平臺的加速方案，它在Windows/Linux上提供了相同的API，底層則分別使用了Windows上的DXVA2和Linux上的VAAPI接口，以Windows平臺上為例，它的基本結(jié)構(gòu)框圖如下：

而在FFmpeg的集成中，基本上是在Libavcode/Libavfilter內(nèi)提供了一個(gè)基本的wrapper去調(diào)用Media SDK的API來提供相應(yīng)的功能。下圖展示了Libavcodec集成MediaSDK的h264/hevc/mpeg2 Codec的狀態(tài)，需要注意的是，F(xiàn)Fmpeg master開發(fā)分支上支持的FFmpeg QSV已經(jīng)支持了更多的Codec和相關(guān)VPP功能。

在Windows平臺，如果你想在Intel 平臺上執(zhí)行編碼相關(guān)的事務(wù)， Media SDK基本上是唯一的選擇。當(dāng)然，如果你更偏向FFmpeg的API，可以使用FFmpeg QSV/Media SDK的方式；而在Linux平臺，F(xiàn)Fmpeg VA-API與FFmpeg QSV/Media SDK 接口大部分功能重合，更多的區(qū)別可能在于軟件靈活度和開放程度的考量。一般說來，F(xiàn)Fmpeg VA-API提供了更大的靈活度，對于有開發(fā)能力或者想二次定制的客戶更加的友好一些。從FFmpeg的角度看，這兩者在FFmpeg框架內(nèi)的最大不同點(diǎn)在于： FFmpeg VA-API是以Native CODEC的方式直接實(shí)現(xiàn)與FFmpeg內(nèi)部，而FFmpeg QSV集成Media SDK的方式，非嚴(yán)格的類比則類似于FFmpeg 集成libx264 這樣第三方庫的方式，需要依賴Media SDK，而FFmpeg VA-API則并不依賴第三方的庫，其CODEC的實(shí)現(xiàn)直接位于FFmpeg代碼庫自身。另外，需要提及的另外一件事情是，Media SDK開放了部分功能，其代碼Repo在：

https://github.com/Intel-Media-SDK/MediaSDK

Nvidia: CUDA/CUVID/NVENC

之前提及Nvidia的時(shí)候說過，Nvidia曾經(jīng)一度提出VDPAU與Intel 提出的VA-API在Linux上競爭，但最近的趨勢似乎是Nvidia走向了更為封閉的方式，最主要的傾向是，Nvidia似乎放緩了對VPDAU的支持，取而代之的是提供較為封閉的NVDEC與NVENC庫。另外，在FFmpeg中集成NVENC 與NVDEC的方式與FFmpeg QSV集成Intel Media SDK方式一致，也是以集成第三方庫的方式集成進(jìn)FFmpeg的。這帶來的弊端是，對NVENC/NVDEC的依賴較大，加上Nvidia并未開放NVENC/NVDEC的代碼，因此如果想做二次開發(fā)或者功能增強(qiáng)以及性能調(diào)整的時(shí)候，基本都得依賴Nvidia自身去改動NVENC/NVDEC，這可能對部分開發(fā)者帶來一些影響。

下面是NVECN/NVDEC說支持的CODEC的一個(gè)圖示，基本上FFmpeg CUVID/NVECN/CUDA部分分別集成了硬件加速的解碼，編碼以及部分CUDA加速的諸如Scaling這樣的Filter。另外，CUVID部分，為了和NVENC統(tǒng)一，Nvidia已經(jīng)把它改稱為NVENC，但FFmpeg并沒有去做這個(gè)更新。

AMD: AMF

AMF SDK用于控制AMD媒體加速器，以進(jìn)行視頻編碼和解碼以及色彩空間轉(zhuǎn)換，現(xiàn)在開源出來的版本（https://github.com/GPUOpen-LibrariesAndSDKs/AMF），并未支持Linux，只能在Windows上進(jìn)行編碼，支持的Codec有AVC/HEVC。需要指出的是AMF的全稱是Advanced Media Framework，之前有時(shí)會被稱之為VCE（Video Coding Engine）

另外，VCE實(shí)際上支持兩種模式，一種模式是所謂的full fixed mode，這種模式之下，所有的編碼相關(guān)執(zhí)行使用的ASIC 方式，而另一種模式則是hybrid mode，主要是通過GPU中的3D引擎的計(jì)算單元執(zhí)行編碼相關(guān)動作，而對應(yīng)的接口則是AMD's Accelerated Parallel Programming SDK 以及 OpenCL。

除了上述的一些方案以外，還有一些使用在嵌入式平臺的一些方案，能夠看到的有：

• BRCM的MMAL：

  http://www.jvcref.com/files/PI/documentation/html/

  https://github.com/techyian/MMALSharp/wiki/What-is-MMAL%3F

• RockChip：MPP

  http://opensource.rock-chips.com/wiki_Mpp

  http://opensource.rock-chips.com/images/f/fa/MPP_Development_Reference.pdf

• TI DSP方案：

  http://www.ti.com/processors/dsp/applications.html

有興趣者，可以通過這些資源自行去獲取相關(guān)信息。

2.獨(dú)立于平臺與Chip廠商的優(yōu)化方案

OpenCL與Vulkan:

Khronos在OpenGL的年代一戰(zhàn)成名，最近這些年，圍繞著高性能圖形圖像API提出了大量的標(biāo)準(zhǔn)，其中有兩個(gè)較新的標(biāo)準(zhǔn)值得注意，一個(gè)是OpenCL，最初是Apple提出，現(xiàn)在則是異構(gòu)高性能并行計(jì)算的標(biāo)準(zhǔn)，其出發(fā)點(diǎn)基本是以Nvidia的CUDA為對標(biāo)；另一個(gè)則是OpenGL的后繼者Vulkan。最新的動向是Khronos似乎打算把OpenCL標(biāo)準(zhǔn)整合進(jìn)Vulkan，所以很可能不久的將來，Vulkan會變成統(tǒng)一圖像與計(jì)算的API。由于OpenCL基本上是GPU上編程的唯一通用標(biāo)準(zhǔn)（另一個(gè)業(yè)內(nèi)使用范圍更廣泛的是Nvidia的CUDA），很自然的FFmpeg也打算用OpenCL去加速相應(yīng)的一些Codec或者AVfiter相關(guān)的任務(wù)。最初，x264嘗試用OpenCL優(yōu)化，但結(jié)果并不盡理想，主要原因估計(jì)是很多時(shí)候編碼器實(shí)現(xiàn)是一個(gè)反復(fù)迭代的過程，數(shù)據(jù)之間也會出現(xiàn)依賴，導(dǎo)致想完全并發(fā)利用OpenCL去加速，比較困難，所以最終x264只用OpenCL加速了部分功能，更多的信息可以參考

https://mailman.videolan.org/pipermail/x264-devel/2013-April/009996.html

FFmpeg并未嘗試用OpenCL去優(yōu)化Codec部分，但是卻優(yōu)化了AVFilter部分，主要用在硬件加速轉(zhuǎn)碼的場景下。其最大的好處是解碼，F(xiàn)ilter、編碼都在GPU內(nèi)部完成，避免了GPU與CPU之間的數(shù)據(jù)交換，而一般Codec輸出的數(shù)據(jù)，需要與OpenCL實(shí)現(xiàn)所謂的Zero Copy，這一點(diǎn)，需要OpenCL做一些擴(kuò)展以支持接收解碼器解碼的出來的數(shù)據(jù)格式，并輸出編碼器能接收的數(shù)據(jù)格式。這里典型的擴(kuò)展如Intel 提出的OpenCL與VA-API的Surface sharing：

https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_va_api_media_sharing.txt：

最近，F(xiàn)Fmpeg社區(qū)的Rostislav Pehlivanov開始嘗試用Vulkan優(yōu)化AVFilter，已經(jīng)提交了Patch，正處于Review階段，從他FOSDEM的PPT https://pars.ee/slides/fosdem18_encoding.pdf 看，他似乎也想再次嘗試用Vulkan來優(yōu)化Codec，但初期只有針對AVFilter的優(yōu)化代碼出現(xiàn)。順帶說一句，Rostislav Pehlivanov的這份PPT中，回顧了各種CODEC上的各種嘗試，整個(gè)行業(yè)在CODEC上的努力，而其中大部分的CODEC，并未流行開來，但這些人的種種努力不該被完全忘記。

3.參考文獻(xiàn)

• https://developer.nvidia.com/nvidia-video-codec-sdk 更多Nvidia video codec的信息，可以從這里獲取到

• http://on-demand.gputechconf.com/gtc/2016/presentation/s6226-abhijit-patait-high-performance-video.pdf 這里對NVENC/NVDEC 給出了一些詳盡的說明

• https://developer.android.com/reference/android/media/MediaCodec.html 使用MediaCodec時(shí)候，Android上的文檔基本上是必須要先讀的

• https://elinux.org/images/9/9d/Android_media_framework--van-dam_and_kallere.pdf

• https://static1.squarespace.com/static/4eb80772d09a941b5c45e0c0/t/541f2918e4b092469720191e/1411328280290/Video_DroidConNYC.pdf

• https://www.khronos.org/ khronos 最近動作不斷，一方面，看到各種新標(biāo)準(zhǔn)的提出，另一方面又擔(dān)心這些標(biāo)準(zhǔn)最終實(shí)施的狀況。

WebRTCon 2018

WebRTCon 2018將于5月19-20日在上海光大國際會展中心舉行，這是一次對過去幾年WebRTC技術(shù)實(shí)踐與應(yīng)用落地的總結(jié)。

大會組委會以行業(yè)難點(diǎn)為目標(biāo)，設(shè)立了主題演講，WebRTC與前端，行業(yè)應(yīng)用專場，測試監(jiān)控和服務(wù)保障，娛樂多媒體開發(fā)應(yīng)用實(shí)踐，WebRTC深度開發(fā)，解決方案專場，WebRTC服務(wù)端開發(fā)，新技術(shù)跨界，WebRTC與Codec等多個(gè)專場。邀請30余位全球領(lǐng)先的WebRTC技術(shù)專家，為參會者帶來全球同步的技術(shù)實(shí)踐與趨勢解讀。

在主題演講環(huán)節(jié)，Google軟件工程師Zoe Liu 、姜健，將分別向國內(nèi)的開發(fā)者分享AV1的最新進(jìn)展與技術(shù)探索、VP9的SVC優(yōu)化。此外，北京大學(xué)教授王榮剛、英特爾實(shí)時(shí)通信客戶端架構(gòu)師邱建林、Aupera傲睿智存 CTO周正寧將分別分享國產(chǎn)Codec AVS2的最新演進(jìn)、H.264的硬件編碼優(yōu)化，FPGA加速WebRTC服務(wù)端和轉(zhuǎn)碼。上海交通大學(xué)圖像通信與網(wǎng)絡(luò)工程研究所副所長宋利會分享學(xué)術(shù)界在Codec優(yōu)化的最新思路與嘗試，他會介紹AI、區(qū)塊鏈和大數(shù)據(jù)賦能的Codec。