· 从第二代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确实赢了。

该版本在4月份就已经开始测试，PugetSystems曾对此进行过测试，他们使用了三种不同的源素材，分别是码率为150Mbps的4K H.264、4K ProRes 422和4K RED对不同的导出编码进行测试，结果如下面三张图所示：

预览// var istart = 18; //通过编号生成，图片开始的编号，不强求连续，但尽量连续编号，小图+s，如1s； var istart=['4k_h264','4k_prores','4k_red']; //通过文件名生成，大图文件名，不含后缀，小图以s结尾 var ilast = 19; //结束图片的编号，如果是文件名生成，这个数字不用改 var tips = []; //图片说明，按顺序列，没有就空着 var iurl = "https://img.expreview.com/news/2020/05/19/"; //图片目录 var col = 3; //列数，一排几张图，1 2 3 4可选 var nomore = 1; //大小图是否一样，1为一样，不需要s后缀的小图，用于列图片 var gap = 0; //图片间距修正，默认0 var bd = 0; //描边，0或1，默认0 var full = 0; //是否全屏，0 或 1 var pic = ".jpg"; //图片格式 WaterInit(pic, iurl, col, gap, bd, istart, ilast, full, tips, nomore);图上的单位是导出的速度，单位是FPS，红色条柱为NVENC，蓝色为软件编码，绿色为QuickSync。可以看到NVENC不管在哪种情况下都能够提供较大的速度提升。

还有微博网友在AMD的平台上进行了测试，结果显示支持AMF的APU同样可以加速导出，虽然速度没有NVENC那么快，但已经超过了Ice Lake上面的新版QuickSync。

NVENC、AMF和QuickSync都是硬件编码电路，在效率上比软件编码要高很多，不过缺点在于画质会有一定的损失，但实际上，Turing GPU上面的NVENC模块对画质的优化已经达到了相当好的地步，可用性相当高。

我们也会在之后带来相关的测试，敬请期待。

本视频...没有sponsor。如果你喜欢我们的视频，帮忙发弹幕、转发扩散吧，如果你不喜欢，请提建议帮助我们做得更好，先关注我们的频道，一起进步吧。

手机通道：哔哩哔哩

鉴于你们有不看视频的，文字版可以点这里。