一种基于GPU的完全硬件转码的方法和系统

摘要

本申请涉及一种基于GPU的完全硬件转码的方法和系统。具体而言，本申请的方法和系统是在原本NVENC的基础上，借助OPENCV封装的CUVID进行硬件解码，然后在显存里使用新开发的转码逻辑进行转码计算，最后使用NVENC的编码器进行编码，从而实现完整的纯GPU硬件转码过程。

说明书

技术领域

本专利涉及到流媒体视频转码技术，尤其是针对一种基于GPU的对具有 H.264、MPEG-2编码格式的视频数据进行完全硬件转码生成H.264编码格式的 视频以减少CPU占用率的方法和系统。

背景技术

2007年，NVIDIA公司推出了CUDA(ComputeUnifiedDeviceArchitecture) 框架以及CUDAC语言，将传统的GPU通用计算(GPGPU)推向一个新的高 峰。传统的GPU通用计算是通过“欺骗”GPU与显存的渲染过程，来借助显卡 的强大并行处理矩阵型数据的能力达到通用计算的目的。这一过程既不直观， 也很费力，很难得到较好的推广。而CUDA框架的出现，使GPGPU编程变得 类似普通高级语言编程，使开发者可以便利使用GPU的强大并行运算能力。 具体而言，CUDA框架是一个新的基础架构，这个架构可以使用GPU来解决 商业、工业以及科学方面的复杂计算问题。它是一个完整的GPGPU解决方案， 提供了硬件的直接访问接口，而不必像传统方式一样必须依赖图形API接口来 实现GPU的访问。在架构上采用了一种全新的计算体系结构来使用GPU提供 的硬件资源，从而给大规模的数据计算应用提供了一种比CPU更加强大的计算 能力。CUDAC采用C语言作为编程语言提供大量的高性能计算指令开发能力， 使开发者能够在GPU的强大计算能力的基础上建立起一种效率更高的密集数 据计算解决方案。

GPU极为擅长处理大型矩阵型或类矩阵型数据的整体变换或计算，在当 时，借助GPU的计算能力可以达到CPU效率的数倍甚至数十倍。尽管在现在 随着CPU的进一步发展，GPU的压倒性优势有所衰减，但其强大依然不容小 视。

而视频转码技术是指将已经压缩编码的视频码流转换成另一个视频码流， 以适应不同的网络带宽、不同的终端处理能力和不同的用户需求。随着互联网 技术的发展，越来越多的视频被广泛传播到各种播放设备上，例如个人计算机、 笔记本、电视机、MP4播放器、平板和手机等等。这些设备通常安装了各种不 同的操作系统或播放软硬件，分别支持不同格式的视频流。这就很容易导致用 户所获得的视频的格式可能并不能直接被其持有的播放设备所支持。而随着技 术的进步，各种新的视频编码技术被不断推出，这也导致老的设备可能并不支 持最新的视频格式。因此，为了解决上述问题，视频转码技术正变得日益重要。 所述视频转码技术本质上是一个先对原始格式的视频进行解码，随后将其转码 成所需的格式，再以新的视频编码标准对其进行编码的过程。对于高效的视频 文件转码需求，视频文件的每一帧都是一幅图像，而图像是完美的矩阵型数据， 因此，借助GPGPU进行GPU硬件视频转码，从而在效率上超越传统的纯CPU 视频转码就成了一个很自然的思路。

NVIDIA伴随着CUDA，也发布了视频的解码与编码工具开发包，解码工 具为NVCUVID(简称CUVID)，编码工具为NVENC。乍看之下， CUVID+NVENC已经可以完成GPU视频转码，而且新版本的FFMPEG中已经 增加了对NVENC的支持，但经代码分析和运行测试，可以发现：NVENC包 含转码计算(包含转码率计算)和编码器两个部分，其中转码部分的计算依旧 在CPU里完成，并非真正的纯GPU硬件转码——FFMPEG也是如此。另一个 常见的商业转码软件WOWZA也不是纯GPU硬件转码，它们都采用了“GPU 解码，取回内存，CPU转码，推送显存，GPU编码”的方式，这一方式对CPU 和内存资源消耗依旧很大，同时，在转码过程中，数据在内存和显存之间的来 回过程消耗了大量的系统时间，而且转码计算并没有充分利用GPU的计算能 力。因此，现有的NVENC和应用NVENC的诸如FFMPEG、WOWZA之类的 转码软件均不是严格意义上的完全基于GPU的硬件转码。

因此，为了提高视频转码效率，存在期望能够提供一种基于GPU的完全 硬件转码的方法和系统的需求。

发明内容

本申请的方法和系统是在原本NVENC的基础上，借助OPENCV封装的 CUVID进行硬件解码，然后在显存里使用新开发的转码逻辑进行转码计算，最 后使用NVENC的编码器进行编码，从而完成完整的纯GPU硬件转码过程。

在本申请的一个方面，提供了一种基于GPU的完全硬件转码的方法，其 特征在于，包括：GPU转码器从显存中读取经GPU解码器解码的YUV4：4：4 格式的视频帧数据；将所述视频帧数据拆分成Y、U、V三个通道的独立矩阵； 对于Y矩阵，通过转换分辨率形成新Y矩阵；对于U矩阵和V矩阵，按YUV4： 2：0格式转换分辨率分别形成新U矩阵和新V矩阵，并且将所述新U矩阵和新 V矩阵合并成双通道的UV矩阵；将所述新Y矩阵的数据和所述双通道的UV 矩阵的数据分别复制到待编码的显存中；以及GPU编码器对从所述待编码的 显存中读取的所述新Y矩阵的数据和所述双通道的UV矩阵的数据进行编码以 生成输出的视频文件。

在本发明的另一个方面，提供了一种基于GPU的完全硬件转码的系统， 其特征在于，包括：GPU解码器，配置为将来自存储器或数据源的视频帧数据解 码成YUV4：4：4格式的视频帧数据并将其写入到显存中；GPU转码器，配置用 于执行下述操作：从所述显存中读取经所述GPU解码器解码的YUV4：4：4格式 的视频帧数据；将所述视频帧数据拆分成Y、U、V三个通道的独立矩阵；对 于Y矩阵，通过转换分辨率形成新Y矩阵；对于U矩阵和V矩阵，按YUV4： 2：0格式转换分辨率分别形成新U矩阵和新V矩阵，并且将所述新U矩阵和新 V矩阵合并成双通道的UV矩阵；将所述新Y矩阵的数据和所述双通道的UV 矩阵的数据分别复制到待编码的显存中；以及GPU编码器，配置为对从所述 待编码的显存中读取的所述新Y矩阵的数据和所述双通道的UV矩阵的数据进 行编码以生成输出的视频文件。

一个或多个实施例的详情在附图及以下描述中阐述。通过阅读以下详细描 述并查阅相关联的附图，其它特征和优点将是显而易见的。应该理解，下述详 细的描述仅是说明性的，而不是对所要求保护的发明的限制。

附图说明

为让本申请的上述目的、特征和优点能更明显易懂，以下结合附图对本申请 的具体实施方式作详细说明，其中：

图1是根据本申请的实施例的系统硬件结构示意图。

图2是根据本申请的实施例的GPU转码器工作流程图的理论层面示意图。

图3是根据本申请的实施例的GPU转码器工作流程图的实践层面示意图。

具体实施方式

在现有GPU转码技术中的“解码-转码-编码”计算链中，转码步骤的实现依 旧是在GPU对视频帧数据解码之后将所解码的视频帧数据从显存取回到内存 中，然后使用CPU完成转码计算后，再从内存将所述转码后的数据推送至显存， 再由GPU进行后续的编码操作。这一转码过程中，数据在显存与内存之间多 了一个来回传输的过程，耗费了大量的系统时间，同时也无法彻底降低视频转 码处理的CPU占用率，也没有充分利用GPU的计算能力。

因此，本申请的方法和系统的目的即是设法让“解码-转码-编码”这三个核 心步骤全部在GPU及显存里完成，省去转码步骤在显存与内存之间的数据传 输的系统耗时，并通过极大化使用GPU的计算能力来相应地降低CPU占用率， 使得所述视频转码处理的整个过程都可以不依赖于CPU的使用，实现真正意义 上的完全硬件转码。

具体而言，在现有的开源库OPENCV中，封装了一定程度的GPU、图像、 视频处理的类与函数，但这些远不足以直接完成GPU转码，特别是对于H.264 编码需要的YUV4：2：0格式，现有的OPENCV中的GPU模块没有提供直接 支持。针对现有的OPENCV中的所述缺陷，本申请提供了创新的GPU转码逻 辑来执行传统的在CPU中进行的转码计算。当然，对于逻辑实现过程中可用 OPENCV函数和NVENC原有结构实现的步骤，本申请则还是调用了相应的原 有函数。

在本申请的方案中，通过利用创新的GPU转码逻辑来使得GPU支持 YUV4：2：0格式以实现GPU对YUV4：2：0格式的转码计算，使视频帧数 据不需要再在GPU解码后从显存取回内存以供CPU转码计算，而是可以继续 留在显存中直接经由GPU进行转码计算，并因此也取消了原本在CPU转码计 算后将帧数据从内存再推回显存的步骤，而是直接将显存中转码好的数据送至 GPU编码工具进行编码，即可完成完整的GPU转码流程。

经实测，本申请的方法的转码速度比纯CPU转码方法提升了3到5倍，比 现在正在使用的CPU+GPU的转码方案快1.5到3倍。同时，使得CPU占用率 也大大下降，实现了系统时间的节省，CPU占用率的下降和整体转码效率的提 高等改进。

现在就开始讨论本申请的具体方案。在本申请中将整个转码系统和方法及 其所必须的前导与后续步骤，即完整的对具有H.264、MPEG-2编码格式的视 频转码过程，将其实现为一个系统工程，称为WSNVENC。其中，所述MPEG-2、 H.264编码格式可被目前的GPU解码器支持并且解码后生成YUV4：4：4格式， 但所述示例的编码格式并非限制性的，实际上，本申请的WSNVENC所支持的 格式取决于GPU自身支持的视频格式。所述WSNVENC的核心贡献如图3所 示在解码-转码-编码的计算链中的转码过程中。

在下面的讨论中，先结合图1中的系统硬件结构示意图对所述WSNVENC 系统的基本工作流程进行概述。

首先，在所述WSNVENC系统100的工作过程中，首先，将从存储器或数 据源110中读取输入视频文件的视频帧数据读取到内存中。所述存储器包括例 如硬盘、光盘、U盘、磁盘等计算机可读存储介质，而所述数据源则包括例如 在局域网、广域网、因特网上通过有线或无线网络与WSNVENC系统进行数据 通信的服务器、客户机、个人终端等计算设备，以及通过有线或无线连接与 WSNVENC系统相连的诸如照相机、摄像机(头)等视频捕捉设备。所述视频 文件包括GPU解码器能够支持的编码格式的视频文件。具体而言，由于CUVID 所支持的视频编码格式限制，目前仅支持MPEG2和H.264格式的视频文件。

接着，所述WSNVENC系统通过GPU解码器120(即OPENCV封装的 CUVID工具)直接读取在内存中存储的所述视频帧数据并将其写入到显存中。

随后，利用OPENCV封装的CUVID工具对显存中的视频帧数据进行解码。 如本领域技术人员所熟知的，这种解码操作是利用GPU的硬件资源来进行的 硬件解码操作，在本申请中就不再对其进行详述。通过所述GPU硬件解码， 获得了经解码的YUV4：4：4格式的视频帧数据并将其保存在显存中。与传统 的CUDA转码技术不同的是，在本申请中，此视频帧数据不用再被取回到内存 中以供CPU处理，而是直接从显存中被送入WSNVENC系统专门编写的GPU 转码器(WSNVENC工具130)。

WSNVENC系统的GPU转码器130在显存中完成视频帧数据的转码计算， 所述转码计算主要涉及从YUV4：4：4格式到YUV4：2：0格式的转化和相应 的转换分辨率的计算(转码过程中必备的转码率计算可以使用在CUDA所提供 的现有NVENC中的转码率计算方案来获得，因此不需要WSNVENC额外实 现)，经过GPU转码器转码后得到的YUV4：2：0格式的视频帧数据保留在 显存中，因此可以直接供GPU编码器140使用。GPU转码器130的详细工作 流程原理由图2展示。在完成GPU转码计算之后，将经转码的视频帧数据送 入GPU编码器140。

GPU编码器140即为CUDA所提供的现有NVENC的编码功能，所述功能 在显存中通过GPU编码将YUV4：2：0格式的视频帧数据编码为例如H.264 格式的视频帧数据，并在完成编码后将经编码的视频帧数据写回到内存中，并 经CPU控制将所述经编码的数据从内存写至所述存储器或发送给所述数据源 150，形成输出的转码后的视频文件。所述GPU编码器140和编码过程为本领 域技术人员所熟知，因此，本申请不再在此进一步详述。至此，所述WSNVENC 系统的转码方案结束。

在概览了本申请的WSNVENC系统的转码方案之后，将结合附图2和3 通过具体的示例来进一步详细描述本申请的GPU转码方案的理论实现和实践 实现。

图2示出了根据本申请的实施例的GPU转码器工作流程图的理论层面示 意图，该图仅从理论层面说明了GPU转码器的工作原理和设计思想，而理论 实现与实践实现的区别可以从图3中获得。

从GPU解码器(即OPENCV封装的CUVID)直接得到的显存内的经解码 的视频帧数据是RGB格式的矩阵数据(步骤210)，使用OpenCV提供的 cv::gpu::cvtColor()函数可以将RGB数据转化成YUV4：4：4格式的三通道混 合矩阵，该三通道混合矩阵内的Y、U、V三个通道的数据排列形成形如 YUVYUVYUV……YUV的样式。

之后开始GPU转码过程，首先，GPU转码器将YUV4：4：4的三通道混 合矩阵进行分离，将三个通道拆分成三个独立矩阵，即：Y矩阵、U矩阵、V 矩阵(步骤220)，这三个矩阵分辨率均与原视频分辨率相同。

Y矩阵的转码处理相对简单，直接按新分辨率进行数据缩放即可，形成新 Y矩阵(步骤230)。

U矩阵、V矩阵的转码处理除了按新分辨率进行数据缩放外，还需要按照 GPU编码器需要的YUV4：2：0格式进行缩放，缩放后的新U矩阵、新V矩 阵的长、宽均为新Y矩阵的1/2，总数据量为新Y矩阵的1/4(步骤240和250)。

新U矩阵、新V矩阵需要再经过一步合并处理以形成一个双通道的UV矩 阵，UV矩阵的总数据量为新Y矩阵的1/2(步骤260)。

将新Y矩阵的数据全部复制入待编码显存中，再将UV矩阵的数据全部复 制入待编码显存中(步骤270)。在所述待编码显存中，所述UV矩阵的数据 位于之前被复制入的新Y矩阵的数据之后。即在待编码显存中，形成 YYYY……YUVUVUV……UV的数据存储结构，该数据存储结构即为GPU编 码器所需要的YUV4：2：0数据格式。至此，GPU转码器的工作流程即告结束。

在完成GPU转码器的工作流程之后，WSNVENC系统将处理好的YUV4： 2：0数据格式的视频帧数据推送入GPU编码器。之后，在步骤280中，在显 存中由所述GPU编码器(即NVENC)对所述转码后的数据进行编码处理，并 将经编码的数据作为新的视频文件输出。

但是，由于NVENC通过GPU操作显存与CPU操作内存的方式有很大不 同，因此，很多在理论上非常简单、直接的操作在实际实现时如果不加以改进 而是直接按照理论方法去做就会出错。因此，上述理论层面的GPU转码器的 工作流程只有在针对GPU、显存进行适应性调整后，才能够得到正确的结果。 需要指出的是，理论流程和实际流程之间的差异只是理论与实践之间的自然差 异，而理论思想与原理本身并没有错误。基于上述理解，本申请接着对GPU 转码器的实际实现的工作流程进行详细说明。

图3是根据本申请的实施例的GPU转码器工作流程图的实践层面示意图。 该图从实践层面说明了GPU转码器在实际工程实现中的工作流程。与图2相 区别的部分在图3中以“下划线”和“虚线”标识。为了简洁起见，对于图3中与 图2相同的步骤，本申请不再重复描述，而是着重描述不同之处。

与图2中的GPU转码器工作流程图的理论层面示意图相比，图3中的实 践层面示意图的区别主要在于“适应性分辨率转换”的处理和“非整数倍率”的处 理这两方面。

按照理论原理，比如要将一个1280*720分辨率的视频转为640*360分辨 率的视频，只需要将Y矩阵宽、高都缩小一半，U、V矩阵宽、高都缩小至1/4 即可，但实际上，如果直接这样做的话结果出错。这是因为在显存里，帧数据 是按照“段-块式”存储的。经测试验证，单通道帧矩阵数据中，一行占据的显存 空间为不小于一行实际元素数的512字节的最小整数倍，例如，1280*720分辨 率的视频的Y矩阵一行占据的空间为1536字节(512*3)，而640*360分辨率 的视频的Y矩阵一行占据的空间为1024字节(512*2)，也就是说，一个给定 的分辨率视频可以按其一行占据的空间大小划分为512字节的1倍、2倍、3 倍、4倍四大类区段视频。根据目前的硬件水平，属于4倍视频的1920*1080 是目前常用的最大视频分辨率，故所述四大类区段已经能够满足目前的绝大多 数的系统的正常需求，但本申请并不局限于所述四大类区段视频。随着硬件技 术的发展，当性能更加优异的新系统(诸如新兴的支持4K分辨率的超高清电 视)需要更高分辨率的视频时，诸如5、6……等更高倍数的区段视频也适用于 本申请的转码方案。

同时，显存操作是按块进行操作的，要操作的块可以放大，但不可以缩小， 否则结果会不正确。所以，如果要将视频放大的话，那么分辨率按图2简单转 换即可；但如果要将视频缩小的话，那么，在行方向上缩小的同时，列方向上 要做相应的放大，增大的倍率为旧行宽与新行宽的区段倍率之比(下面简称为 “倍率”)。例如，1920*1080分辨率转为640*360分辨率的倍率为2：1(4倍： 2倍)，那么，视频在行方向上缩小时，列方向上要相应放大为2倍。这种处 理被称为“适应性分辨率转换”处理。

但这种适应性分辨率转换也存在例外。当倍率为非整数时，如4：3和3： 2这两个倍率，列方向上放大为相应的比值并不能使结果正确，而保持不变或 者缩小也不能使结果正确。这是因为GPU编码器的处理模式与GPU操作内存 的模式也存在不同的缘故，要解决这个问题，需要后续的扩展步骤，因此，在 此处，遇到非整数倍率时，如果没有后续扩展步骤的处理，适应性分辨率转换 取列方向为不变，这样的结果自然也是不正确的。

非整数倍率处理：非整数倍率出现问题的原因是，GPU编码器对数据的处 理模式是按照一行占据的空间为512字节的2的整数次幂倍处理的，换言之， 对GPU编码器来讲，视频只有1倍、2倍、4倍三大类区段视频，因此，在3 倍视频相关的非整数倍率问题上，如果不添加扩展步骤，则无论怎样结果都不 正确。当然，从工程角度上来说造成结果不正确的直接原因是适应性分辨率转 换时，列方向不变导致了数据量缩小，因为同样为3倍视频，3：1的转换由于 是整数倍，数据量没有缩小，因而不需要额外扩展步骤其处理的数据结果也是 正确的。而添加了额外的扩展步骤，也就使得本方法在应对非整数倍率视频转 换时，效率有所打折，差不多要慢一半左右。但即使慢一半，其效率也依然高 于纯CPU方法(3倍)和现在常用的CPU+GPU方法(1.5倍)。

因此，在图3所示的GPU转码器工作流程图的实践层面示意图中，在步 骤220中将YUV4：4：4的三通道混合矩阵拆分成三个独立矩阵(Y矩阵、U 矩阵、V矩阵)之后，本申请采用了适应性分辨率转换处理(即视频在行方向 上缩小时，列方向上要放大相应比值——非整数倍率时除外，此时列方向不变 并等待后续扩展处理来形成新Y矩阵、新U矩阵、新V矩阵。具体而言，对 于Y矩阵直接通过适应性分辨率转换形成新Y矩阵(步骤330)，对于U矩阵 按照YUV4：2：0格式通过适应性分辨率转换形成新U矩阵(步骤340)，而 对于V矩阵按照YUV4：2：0格式通过适应性分辨率转换形成新V矩阵(步 骤350)。

在完成所述新矩阵的转换之后，对各新矩阵分别执行转换前后的分辨率所 属的“512字节区段”倍率之比是否为整数的判断(步骤335和步骤355)。如果 在步骤335和355中确定所述倍率比是整数，则如上所述无需额外扩展步骤其 处理的数据结果也是正确的。因此，直接执行后续步骤260、270和280。如果 在步骤335和355中确定所述倍率比非整数，则执行非整数倍率的处理方法， 所述方法包括在进行相应的后续步骤(例如步骤260、270和280)之前，如图 3所示对帧矩阵进行适应性扩展。所述适应性扩展包括：在行方向的末端，对 帧矩阵整体填充上废数据(可以是任意合法值)，填充的数据量为Y矩阵512 列，U、V矩阵256列，从而分别形成YEXT、UEXT、VEXT矩阵(步骤336 和356)。之后，对YEXT、UEXT、VEXT三个矩阵按照理论流程中的后续步 骤(步骤260、270和280)进行操作即可以得到正确的转码结果。所述废数据 填充仅仅是示例说明，本领域技术人员可以根据需要对Y矩阵和U、V矩阵进 行填充，只要Y矩阵的填充列数为偶数，且能够保证使Y矩阵的行大小刚好处 于下一个“512字节区间”内，同时U、V矩阵填充列数为Y矩阵的列数的一半 即可。

当然，在显存中，往一个矩阵型数据的每行末尾填充数据并不容易，但是， 在矩阵型数据的列方向的末尾填加几行却很容易。因此，在实际操作时，我们 利用了OPENCV里封装的cv::gpu::transpose()函数，先将要填充数据的矩阵转 置，例如Y矩阵形成Y^T矩阵，然后本来要在Y矩阵填充N列的，现在变成在 Y^T矩阵填充N行。填充完毕后，再度调用cv::gpu::transpose()函数转置填充后 的矩阵即形成了我们需要的扩展矩阵。

本系统和方法的实例：

下面针对实际使用情况，列举一些可以应用本申请的技术方案的实例。

实例1：若硬件结构满足以下条件：(1)CPU计算能力较弱，或CPU需 要同时用于计算其他更重要的任务；(2)GPU计算能力满足使用NVENC的 基础需求。这样的环境在视频转码中会有自然的降低CPU使用率，充分利用 GPU计算能力，提高转码效率的需求。如果要转码的输入视频格式属于MPEG-2 或H.264，或已经其它解码器解码生成的YUV4：4：4格式，且输出格式为H.264 的话，那么这时的工程需求最适合使用本方法和系统实现。

实例2：若硬件结构满足以下条件：GPU计算能力远强于CPU，同时视频 转码的格式需求满足实例1的格式需求，这时，可以利用本方法和系统达到最 高效率，同时，也可以将多余的CPU的计算能力移做其他需要之用。

实例3：对于视频源格式稳定(MPEG-2或H.264)，输出视频格式没有 特殊要求或可以接受H.264格式的视频网站或个人，可以利用本方法和系统获 得或提供高效、稳定的视频转码服务。

实例4：本方法和系统对于高校、研究所、研发型企业进行H.264与GPU 硬件编解码研究具备充分的实用价值。与此同时，本方法的核心思想其实与输 入/输出视频格式无关。因为当前GPU转码器本身的输入格式为YUV4：4：4， 输出格式为YUV4：2：0，所以，只要GPU解码器支持输出YUV4：4：4，GPU 编码器支持输入YUV4：2：0就可以完全正常工作。目前支持格式不够多样化 的障碍点仅在于GPU解码器支持的输入格式和GPU编码器支持的输出格式很 有限，而随着GPU解码、编码支持格式的进一步发展壮大，本方法的GPU转 码器可以近乎无缝地迁移至新的应用转码系统中。因此，本申请的方案实际上 并不会影响或限制系统整体的输入/输出视频格式。

本申请可具体化为其它具体形式而不背离其精神或本质特征。所描述的实 施例在所有方面都应被认为仅是说明性而非限制性的。因此，本发明的范围由 所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围 内的所有改变都被权利要求书的范围所涵盖。