显卡硬件编码这个概念，各位或多或少应该都有所耳闻。最早它指的是用GPU的通用计算能力来处理视频编码这种计算量庞大的任务。但随着硬件的发展，现在的显卡硬件编码已经跟十多年前的用CUDA加速编码不一样了，现在的显卡硬件编码已经指的是利用GPU集成的专用硬件单元进行编码操作，因为是专用的电路，其效率相比起用通用计算来加速要高出不少，目前AMD、Intel和NVIDIA都已经在自家的硬件中加入了硬件编码相关的单元，但可能大家并不清楚，本文就简单介绍一下三家的硬件编码技术和目前的情况。
NVIDIA NVENC首先要讲的是NVIDIA的NVENC，从变革非常大的Kepler架构开始，NVIDIA就在GPU中加入了专门用于编码视频的硬件单元，并引入了NVENC功能。NVIDIA在每次推出新架构的时候都会更新一下这个单元，加入一些新的特性。从Kepler开始到Turing，NVENC单元已经更新了六代之多了，这里罗列几个比较重要的节点：
· 从第二代Maxwell，也就是GM20x芯片开始，NVENC支持HEVC的硬编码
· Pascal开始，支持10-bit的HEVC硬编码
· Turing开始，支持HEVC的B帧，大幅减少码率开支
不过NVENC的支持情况相当复杂，举例来说，同样属于Pascal家族，高端的GTX 1070/1080就可以同时处理两条视频流，而中端的GTX 1060就只支持一条流；再比如说，GTX 1650这款使用小图灵核心的显卡的NVENC模块实际上是Volta版本的（老黄的刀法可不仅限于GPU的规模）。对此，NVIDIA官方提供了一个非常详细的网站供参考：Video Encode and Decode GPU Support Matrix，如果各位想要搞明白自己显卡的硬件编码能力，参照这个网站是肯定没有问题的。
NVENC只能够编码AVC和HEVC，但发展到现在，它的编码质量已经非常优秀了，这项功能目前的应用还是比较广的，像NVIDIA自家的GeForce Experience在录屏的时候就默认会调用NVENC。
另外，我们最近对NVENC在Premiere Pro中的表现进行了测试，详情可以参考这篇文章：NVIDIA NVENC编码加速器测试。
Intel Quick Sync VideoIntel应该是这三家中最早开始捣鼓硬件编码电路的，早在一代经典的Sandy Bridge，也就是第二代酷睿i系列处理器上面，他们就为核显模块加入了Quick Sync Video特性，发展到现在，也是相当成熟稳定了。相比起NVENC只是一项针对视频编码的技术不同的是，QSV中也包含了对视频解码的相关支持（NV那儿解码是NVDEC的东西），从Sandy Bridge开始到Kaby Lake为止，QSV会随着每一代架构的演进而更新，基本和核显的代数是同步的。随着这几年Intel在架构上的停滞，QSV也没有太大的更新。不过Ice Lake和Tiger Lake上面它还是有一定程度的进步的，比如说Tiger Lake就将要引入针对AV1编码的硬件解码能力。
在硬件编码方面，除了AVC和HEVC这两个常用的视频编码之外，QSV还支持MPEG-2、MJPEG和VP8、VP9的编码支持。它也是较早被软件所支持的硬件视频编解码技术，比如Adobe Premiere Pro很早就可以利用到它。需要注意的是，要使用QSV，核显必须处于开启状态，也就是说，目前被屏蔽掉核显的F后缀处理器无法使用它。
AMD Video Core Next在高清时代刚刚拉开帷幕的时候，AMD或者说，ATI针对硬解高清视频搞出的UVD技术可以说是相当的惊艳，不过在编码方面，他们就落后了一些。
AMD最早在初代GCN架构的显卡中引入了Video Coding Engine技术，初始版本只支持YUV420的AVC编码，且不支持B帧。从VCE 3.0版本开始支持HEVC的编码。VCE的最后一个版本是Vega20 GPU中应用的VCE 4.1，在基于RDNA架构的Navi芯片上面，它被Video Core Next所取代了。
Video Core Next首次出现是在18年发布的Raven Ridge系列APU上面，它取代掉了原本的VCE和UVD，是一套新的视频编解码解决方案。随后在Navi 1x系列芯片中，集成了VCN 2.0，但特性较1.0没有变化，Renoir APU上面集成了VCN 2.1，未来的Navi 2x系GPU将集成VCN 3.0。
如何使用硬件编码技术？早几年软件厂商并不重视利用硬件编码技术，不过如今的PC平台硬件或多或少会支持一种硬件编码技术，如果没法利用的话也算是一种浪费。像是OBS这个常用的录屏软件就支持以上这三项硬件编码技术，在检测到系统硬件支持之后会自动在编码器选项中提供对应的选项；而像Adobe这样在软件优化方面不太上心的公司也在Premiere Pro 14.2版本中加入了对NVENC和AMF（Advanced Media Framework，AMD的多媒体处理框架，可调用硬件编码）的支持。
如果想单独调用GPU硬件编码模块去压视频，自己又有一定动手能力的，可以了解一下日本大神rigaya写的NVEnc、VCEEnc和QSVEnc这三款软件，现在的FFmpeg中也整合了QSV和NVENC，各大FFmpeg的图形化前端应该也做了相应的支持。
顺带一提的是，利用专用单元对视频进行编解码操作并不是显卡或者说PC硬件的专利，几大移动SoC厂商早已在旗下的产品中加入了相关的单元，像苹果，从A10开始，就在SoC中集成了HEVC编码单元，未来给Mac用的自研SoC中肯定也会有相关的单元。
总的来说，硬件编码技术已经普及，并可堪一用。
附赠：硬件编码技术质量如何？如果在早几年用过硬件编码的朋友可能会觉得，硬件编码的质量较差，但实际上这个观念放到今天已经有点不正确了。NVIDIA在最近几代的NVENC中着重改良了它的质量表现。之前NVIDIA官方已经提供了他们的测试，我在业余用他们的参数跑了一下 ，并使用Netflix开源的客观视频质量对比框架vmaf对压制后的视频进行评价。这里使用的源视频片段是《你的名字》开场不久后的那段“MV”，源视频是从蓝光原盘文件中切取获得。
参数的话，NVENC组使用的是-c:v h264_nvenc -preset medium -b:v BITRATE -bufsize BITRATE*2 -profile:v high -bf 3 -b_ref_mode 2 -rc-lookahead 20，libx264组使用的是-c:v libx264 -preset medium -b:v BITRATE -bufsize BITRATE*2 -profile:v high，这两组参数均参考自官方Blog文章。码率范围这边选择的比官方文章中的更广，从2Mbps到20Mbps，2~10Mbps段以1Mbps为间隔，10Mbps以上则以2Mbps为间隔，最终测试得到的码率-vmaf分数图线如下：
预览var title_text = "VMAF对比曲线";
var subtitle_text = "www.expreview.com | ffmpeg 4.2";
var xname = "kbps"; //X轴单位
var yname = ["score"]; //Y轴1单位，Y轴2单位(如果有的话)
var leftside = "8%"; //左边空白
var yax = 0; //是否双Y轴
var yminmax = [92, 99]; //Y轴最小值最大值，默认全0为自动，全1为自动以最小值数据最小值
var fill = 0; //0-1表示填充透明度
var sn = 10; //坐标轴分割为多少段
var mp = 1; //是否显示最大最小值 0为不显示
var autocolor = 0; //是否自动颜色
var colors = ['#3cb0ff', '#b5e450', '#82B41B'];
var symbolsize = 10; //数据点的大小，0为不显示
var data_arr = [
["","x264","Pascal","Turing"],
["2000","92.503","93.6836","94.2426"],
["3000","94.9992","95.6905","96.037"],
["4000","96.1069","96.5858","96.8422"],
["5000","96.7344","97.1036","97.2867"],
["6000","97.1333","97.4238","97.5913"],
["7000","97.3847","97.6651","97.7701"],
["8000","97.569","97.8158","97.8885"],
["9000","97.7047","97.9311","97.9832"],
["10000","97.812","98.0154","98.045"],
["12000","97.9591","98.1233","98.1114"],
["14000","98.0658","98.202","98.1494"],
["16000","98.1435","98.2625","98.206"],
["18000","98.2035","98.3153","98.2172"],
["20000","98.2511","98.3323","98.2278"]
]
ZHXInit(title_text, subtitle_text, xname, yname, leftside, yax, fill, sn, colors, data_arr, mp, autocolor, yminmax,symbolsize);可以看到，Turing片段在中低码率段较Pascal有明显的提升，在这个参数下，两个由NVENC编码得到的片段在绝大部分情况下画质表现均好于libx264的。不过这里需要指出的是，官方采用的编码参数对x264是不利的，实际情况中，压制组会使用更为复杂的控制参数来达到一个码率-画质的平衡。不过对于简单的编码，NVENC确实赢了。
