CN104683860B - 一种音视频多路并发解码加速卡及其解码加速方法 - Google Patents

Abstract

本发明提供一种音视频多路并发解码加速卡，包括解码处理器和内存，所述解码处理器包括通用处理器，***代理模块，末级高速缓存模块，以及多种硬件解码加速模块；所述通用处理器和所述硬件解码加速模块共享末级高速缓存，末级高速缓存通过所述***代理模块连接内存。内存中设置硬件和软件待解码数据缓冲区；通用处理器用于根据是否可以进行硬件加速解码将待解码帧数据送入硬件或是软件待解码数据缓冲区；通用处理器软件和硬件解码线程分别将各自相应的缓冲区数据取出解码。本发明还提供了相应的解码加速方法。本发明能够提供强大的音视频解码加速能力，能够在多种格式、多种解码器下快速切换，可以应对上千路的并发解码请求。

Description

一种音视频多路并发解码加速卡及其解码加速方法

技术领域

本发明涉及音视频解码技术领域，具体地说，本发明涉及一种音视频多路并发解码加速卡及其解码加速方法。

背景技术

网络音视频流量巨大，尤其对于优酷等内容提供商，每分钟用户上传音视频量长达数小时，而这些音视频文件必须要在10多分钟内进行盗版检测、不良信息检测、内容分类等基于音视频内容分析的自动处理工作。音视频数据以压缩形式传输，而内容分析必须基于音频原始波形数据和视频原始图像数据，因此数据解码是内容分析必不可少的前置条件。而互联网用户使用的音视频文件格式多种多样，其中常见的有FLV、WMV、ASF、RMVB、AVI、MP4等，这些文件格式通常用于封装多种编码器进行编码的音视频流，常见的编码器有H.264/AVC、H.265/HEVC、VP8、VP9、VC-1、MPEG1/2/4、RV8/9/10等。然而，目前音视频解码多是针对播放器实时播放需求的，其设计能力只需达到单路视频30fps的帧率即可。而面向内容分析的音视频解码器需要与强大的机器处理能力对应，每秒解码处理能力需要达到数千甚至上万帧。并且，内容提供商所面临的数据解码需要单处理节点能够同时处理多路多种格式的音视频流的并发解码请求，上述应用需求传统播放器类解码器均无法满足，因此需要针对音视频多路并发高速解码需求设计出新的解决方案。

目前，通用服务器适用于进行数据分析等传统业务处理，而对音视频解码不能提供专用加速逻辑，无法发挥其计算性能。因此，设计单独的硬件与通用服务器连接并为其提供解码服务，是一种较佳的方案。针对解码需求接入带宽高的特点和通用服务器高带宽接口的特点，带有PCIe接口的解码硬件是最佳选择，该解码硬件通常被设计为PCIe接口的解码加速卡形式，以便接入服务器。现有技术中，一种典型的PCIe接口解码加速卡是基于DSP处理器的音视频解码加速卡，它的主处理器通常是TI的集成ARM核的Netra处理器，代表性的产品为海康威视等公司的高清视频多路解码显示设备。该类解码加速卡主要用于监控摄像头的多路同时回放，解码设备同时接收多路监控设备的音视频流，进入解码设备后，单片TI处理器最多可进行8路高清解码，解码格式包括H.264、MPEG4、MPEG2、MJPEG等，解码后的数据直接接入显示设备进行显示。然而，该方案仅适合单格式多路并发的音视频处理。因为DSP中专用的解码加速器解码一种格式时，需要切换相应的固件，这种切换效率很低，而多格式并发视频解码的特点决定了需要在多个解码器之间频繁切换，甚至解一帧之后，由于当前视频没有数据，就要切换到另一路另一个格式的视频解码，此时固件切换速度甚至比解一帧的速度还慢，无法发挥其加速性能。

现有技术中，高性能GPU也可以看作一种PCIe接口解码加速卡。其缺点在于功耗大，且解码应用需要频繁跳转不利于GPU编程模型发挥效率。GPU每一次跳转操作都导致大量的计算单元停止工作等待重新分发数据，而解码算法中存在大量的跳转操作，因此这类高性能GPU在解码方面的效率很低。

另外，目前市场上还有一种基于众核处理器的PCIe接口解码加速卡，其代表产品是Tilera公司的tilepro64和tilegx系列芯片。众核处理器内集成数十个(例如64个)通用处理器核，各个通用处理器核内集成了部分向量指令，可用于视频解码的部分算法加速。然而，众核处理器处理多路多格式并发音视频解码应用存在以下问题：

1、单核处理能力有限，处理分辨率大的视频(如FHD视频)时存在延迟大的问题，严重影响分析***实时性；

2、多核协同处理一路视频时，存在多核间数据传输和同步效率较低的问题。

3、众核处理器基于mesh网互联结构实现，而mesh网互联结构对数据局部性处理要求很高，解码器体系结构优化代价很大，而众核处理器的体系结构无法使用已有的优化方法，开发周期长，将造成对新解码器支持严重拖后的问题。

发明内容

因此，本发明的任务是提供一种能够克服上述现有技术缺陷的音视频多路并发解码加速解决方案。

本发明提供了一种音视频多路并发解码加速卡，包括解码处理器和内存，所述解码处理器包括通用处理器，***代理模块，末级高速缓存模块，以及多种硬件解码加速模块；所述通用处理器和所述硬件解码加速模块均与末级高速缓存模块连接并共享末级高速缓存，所述末级高速缓存模块还与***代理模块连接，并通过所述***代理模块连接所述内存；

所述内存中设置硬件待解码数据缓冲区和软件待解码数据缓冲区；

所述通用处理器用于从主机端接收待解码数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区；还用于运行软件解码线程和硬件解码线程，所述软件解码线程和硬件解码线程分别将各自相应的缓冲区数据取出解码，并将解码结果和解码状态放入回传数据缓冲区；其中，所述硬件解码线程调用所述硬件解码加速模块，所述硬件解码加速模块通过所述末级高速缓存模块读取解码上下文并进行解码，向所述硬件解码线程返回解码结果。

其中，所述音视频多路并发解码加速卡还包括与所述末级高速缓存模块连接的图形处理器，所述图形处理器中集成了所述多种硬件解码加速模块，并且所述图形处理器与所述通用处理器共享末级高速缓存。

其中，所述的音视频多路并发解码加速卡还包括与***代理模块连接的I/O桥片和与I/O桥片连接的外部设备。

其中，所述的音视频多路并发解码加速卡还包括PCIe接口以及实现PCIe接口双向传输的PCIe Switch芯片，所述PCIe Switch芯片连接在所述PCIe接口和PCIe控制器之间，所述PCIe控制器集成在所述解码处理器或者I/O桥片中。

其中，所述通用处理器是SANDYBRIDGE，IVBBRIDGE，HASWELL，CRYSTALWELL或者BROADWELL构架的多核通用处理器，或者AMD多核通用处理器。

本发明还提供了一种基于上述音视频多路并发解码加速卡的解码加速方法，所述内存中设置硬件待解码数据缓冲区和软件待解码数据缓冲区；

所述通用处理器运行软件解码线程和硬件解码线程并执行下列步骤：

1)对于从主机端接收待解码数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区；

2)软件解码线程和硬件解码线程分别将各自相应的缓冲区数据取出解码，并将解码结果和解码状态放入回传数据缓冲区；其中，所述硬件解码线程调用所述硬件解码加速模块，所述硬件解码加速模块通过所述末级高速缓存模块读取解码上下文并进行解码，向所述硬件解码线程返回解码结果。

其中，所述内存中还设置接收数据缓冲区，所述步骤1)包括下列子步骤：

11)从主机端接收待解码数据，放入接收数据缓冲区；

12)从接收数据缓冲区取出数据片段，根据节目ID从解码上下文表中取出属性信息；

13)从数据片段中逐一取出帧数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区。

其中，所述内存中还设置解码上下文数据表存储区，所述步骤12)中，所述解码上下文表从所述解码上下文数据表存储区中读出。

其中，所述解码上下文表包括节目信息、解复用器上下文和解码器上下文；

所述步骤12)中，所述通用处理器运行的音视频上下文管理线程检索节目信息中的节目ID，以确定该ID的音视频节目是否已在上下文信息表中存在属性信息，若判断为否，则认为当前节目为新节目，在解码上下文表中添加新的节目ID，若判断为是，则直接根据节目ID提取解复用器上下文和解码器上下文，准备解码；所述解码器上下文中存储了参考帧、对应节目的解码器配置参数；

所述步骤2)中，当解码出数据后，对解码上下文数据表中对应节目ID的参考帧信息进行更新。

其中，所述内存中还设置回传数据缓冲区，所述步骤2)还包括：软件解码线程和硬件解码线程将解码结果存储至回传数据缓冲区；

所述通用处理器还执行步骤：

3)将回传数据缓冲区的状态与解码数据打包回传至主机端。

与现有技术相比，本发明具有下列技术效果：

1、本发明能够提供强大的音视频解码加速能力。

2、本发明能够在多种格式、多种解码器下快速切换，可以应对上千路的并发解码请求，且进行多路并发处理时不降低***性能。

3、本发明可以快速基于开源软件对新解码器进行支持。

4、本发明功耗低，其峰值功耗低于65W，体积开销小，可集成在全高半长PCIe卡，易于与服务器对接。

附图说明

以下，结合附图来详细说明本发明的实施例，其中：

图1示出了根据本发明一个实施例所提供的音视频多路并发解码加速卡；

图2示出了本发明另一个实施例的解码加速卡；

图3示出了本发明一个实施例中的解码处理器的结构以及它与内存和I/O桥片的连接关系；

图4示出了根据本发明一个实施例的服务器主机与解码加速卡的启动过程的流程图；

图5示出了根据本发明一个实施例的解码***的解码流程图；

图6示出了本发明一个实施例中的多路多格式多解码器加速卡解码数据流向及相应数据结构的示意图；

图7示出了根据本发明的一个实施例的音视频数据接收线程的数据处理流程图；

图8示出了根据本发明的一个实施例的解码结果与状态数据回传线程的数据处理流程图；

图9示出了根据本发明的一个实施例的音视频上下文管理线程的数据处理流程图；

图10示出了根据本发明的一个实施例的硬件解码线程的数据处理流程图；

图11示出了根据本发明的一个实施例的软件解码线程的数据处理流程图；

图12示出了根据本发明的一个实施例的各个线程和各个缓冲区的关系图；

图13示出了根据本发明一个实施例的加速卡端的单路音视频解码流程。

具体实施方式

图1示出了根据本发明一个实施例所提供的音视频多路并发解码加速卡。如图1所示，该解码加速卡(为便于描述，下文中多处将解码加速卡简称为加速卡)包括解码处理器；与解码处理器连接的PCIe Switch模块(PCIe交换模块，例如PCIe交换芯片)，内存和I/O桥片；与PCIe Switch芯片连接的PCIe接口；与I/O桥片连接的USB存储模块，SATA存储模块以及用于显示、网络等功能的外设模块；以及用于为各个模块提供相应电压的电源管理模块。

本实施例中，解码处理器采用x86指令集的Intel四核处理器作为通用处理器，其架构为CRYSTALWELL，并且解码处理器内置HD5200显卡，Intel多核处理器与显卡连接并共享高速缓存。解码处理器外接的内存可以是内存条或是内存颗粒，I/O桥片外接的USB存储器可以是U盘/闪存模块，用于显示、网络等功能的外设模块可以是网络接口、显示接口等。电源管理模块包括一系列独立的变压稳压器件，其作用是将从PCIe Edge接入的12V/5V/3.3V电源转化为解码加速卡上各个模块所需的电压，并为加速卡上所有模块供电。

需要说明的是，图1所示的解码加速卡结构并不是唯一的，例如，图2示出了本发明另一个实施例的解码加速卡，PCIe Switch芯片不是直接与解码处理器连接，而是与解码处理器的I/O桥片内集成的PCIe控制器连接。

由于X86处理器或其桥片内的PCIe控制器均为Root Complex端，因此无法以主从方式进行数据传输，故在加速卡上接入一个PCIe Switch芯片。该PCIe Switch芯片可直接与解码处理器(图1的实施例)或其桥片(图2的实施例)内集成的PCIe控制器连接，PCIeSwitch芯片可以支持PCIe NT方式且可提供双向PCIe 8x/16x传输的任意芯片，因此PCIeNT连接后，形式上服务器主机(为便于描述，下文中多处将服务器主机简称为服务器或者主机)和加速卡组织为主从方式，实际上由PCIe Switch为转发芯片，通过其自身进行数据缓冲，实现双向的PCIe DMA传输。这样就解决了以X86处理器为核心的解码加速卡与服务器主机之间的数据传输问题。

图3示出了本发明一个实施例中的解码处理器的结构以及它与内存和I/O桥片的连接关系。如图3所示，解码处理器包括***代理(System Agent)模块，末级高速缓存(LastLevel Cache，缩写为LLC)模块，图形处理器(GPU)和四个x86核心，其中***代理模块用于连接内存和I/O桥片。***代理模块，图形处理器和四个x86核心均与末级高速缓存模块。其中，***代理模块中集成片内逻辑链路控制单元。末级高速缓存模块由CPU(即四个x86核心)与图形处理器共享，从而支持高速内存数据共享与交换，节省访存带宽。这与传统结构中由CPU专享的LLC模块是不同的。图形处理器中集成有硬件解码加速模块。图形处理器是HD5200集成显卡，这些集成显卡中均集成有多种硬件解码加速模块，硬件解码加速模块是指专用音视频解码逻辑单元，例如：H.264、H.265、VC-1、AAC等硬件解码加速器。本实施例中，x86核心用于判断和分配解码任务，使得软件解码和硬件解码发挥各自的优势，从而在功耗和体积开销受限的前提下提供强大的音视频多路并发解码性能。同时，本实施例的加速卡相对于众核处理器能够降低处理器核心间的管理开销，更易于支持新解码器。

需说明的是，本发明的解码处理器也可以采用其它基于X86核心的多核通用处理器，例如SANDYBRIDGE，IVBBRIDGE，HASWELL，CRYSTALWELL或者BROADWELL构架的多核通用处理器，或者AMD的相应多核通用处理器。解码处理器内置的显卡也可以是其它集成了硬件解码加速模块的显卡，例如HD4000/4200/4600等。

本发明的解码加速卡用于为服务器提供解码加速服务，下面再进一步介绍本发明的加速卡和服务器所组成的解码***的工作流程。

图4示出了根据本发明一个实施例的服务器主机与解码加速卡的启动过程的流程图。该实施例中，由于解码加速卡以PCIe设备形式接入服务器主机，因此整个***上电流程从服务器开始，服务器加载操作***后，启动相应的加速卡驱动程序和解码请求程序。如图4所示，服务器主机的启动过程包括下列步骤：

步骤101：***上电。

步骤102：服务器操作***启动。

步骤103：主机的操作***加载后启动解码请求程序。

步骤104：主机通过PCIe与加速卡建立设备驱动层(设备驱动层包括基本输入输出IO接口等，它还用于处理连接速度、设备类型等方面的事务)连接，连接建立成功后对加速卡进行控制和使用。本实施例中，主机通过PCIe与加速卡建立通信连接后，启动板卡重启线程，板卡状态检测线程和解码服务请求线程，这三个线程分别执行步骤105,106和107。

步骤105：运行板卡重启线程，这个主机端的板卡重启线程用于触发板卡重启操作。这个触发可以是主机的主动触发，也可以是根据板卡状态检测线程的结果进行被动触发。

步骤106：运行板卡状态检测线程。板卡状态检测线程用于对加速卡进行板卡状态检测。本步骤中，板卡状态检测线程可以通过PCIe通信连接调用加速卡端的管理服务程序检测加速卡状态(如温度)。上述启动板卡重启线程，板卡状态检测线程均可以看作主机端的加速卡驱动程序的组成部分。

步骤107：运行解码服务请求线程。解码服务请求线程用于向加速卡提交解码服务请求。另外，解码服务请求线程还用于上传音视频码流、接收加速卡端返回的解码后的结果数据。

步骤108：在没有新的音视频文件需要解码时，主机关闭断电或进入空闲状态。

另一方面，仍然参考图4，加速卡的启动流程包括下列步骤：

步骤101：***上电。

步骤202：加速卡***启动。

步骤203：根据BIOS配置，选择从USB或SATA存储设备启动。

步骤204：执行相应存储上的Loader，即从USB或SATA存储设备启动Loader。

步骤205：Loader启动后，根据默认配置在加速卡上启动Windows或Linux操作***。

步骤206：操作***加载后，启动应用层程序，应用层程序包括管理服务程序和解码服务程序，然后分别执行步骤207和208。

步骤207：运行管理服务程序。管理服务程序首先尝试通过PCIe与主机建立通信，进行基本的配置信息交互，然后进入管理服务状态，对主机提供控制请求服务，包括加速卡的重启动、加速卡状态(如温度)检测等。

步骤208：运行解码服务程序。解码服务程序用于响应主机的解码请求，接收和分析主机上传的音视频数据的信息(格式、解码器种类等)，将可以进行硬件加速解码的视频送入硬件加速模块进行处理，其它的直接进行软件解码，并将软硬件解码后的数据以及解码信息传回主机。

步骤108：在没有新的音视频文件需要解码时，加速卡随着主机关闭断电或进入空闲状态。

图5示出了根据本发明一个实施例的解码***的解码流程图，参考图5，在主机端，解码流程包括下列步骤：

步骤301：开启需要音视频多路并发解码的应用，例如音视频处理分析应用。

步骤302：主机与加速卡建立解码应用层(包括解码请求响应接口和状态监测接口)连接。

步骤303：判断连接是否成功，如果是，分别执行步骤304和步骤308，否则，进入步骤307。

步骤304：主机接收网络数据。例如，接收不同用户上传的海量的各种格式的音视频数据流。

步骤305：判断所接收的网络数据的数据量是否足够解码，如果是，进入步骤306，否则返回执行步骤304。

步骤306：将所接收的网络数据打包上传至加速卡。

步骤307：尝试重启加速卡，然后返回步骤302。

步骤308：接收来自加速卡的解码数据。

步骤309：基于解码数据进行数据分析处理。

步骤310：关闭音视频处理分析应用。

一个实施例中，主机和加速卡根据功能不同在启动后加载各自的线程池，主机的线程池包括网络数据处理、数据打包上传加速卡、接收解码数据和数据分析处理四个功能单元，上述步骤301至310基于这四个功能单元以及主线程完成。其中，主线程负责启动加速卡，确定加速卡是否可用，连接建立后，在本地启动所有功能线程。网络数据接收线程从网络数据中分离出音视频数据，对音视频数据按单路音视频进行重组，并给新的节目分配ID，并放入待解码数据缓冲区。数据打包上传线程检查待解码数据缓冲区中满足一定长度的数据片段，上传到加速卡进行解码。数据接收线程接收加速卡解码后的音视频数据和解码状态统计信息，音视频数据存入待分析数据缓冲区，解码状态统计信息计入日志。数据分析线程进行分析处理。

仍然参考图5，加速卡端的解码流程包括下列步骤：

步骤401：加速卡接收主机上传的数据。如前文所述，主机端的网络数据接收线程从网络数据中分离出音视频数据，对音视频数据按单路音视频进行重组，并给新的节目(即新的单路音视频数据)分配ID。本步骤可以与前文的步骤306衔接。

步骤402：判断加速卡端是否已存在当前所接收的单路音视频数据的属性信息，如果是，执行步骤403，否则，执行步骤404。

步骤403：对当前的单路音视频数据进行解封装得到帧数据。然后执行步骤406。

步骤404：分析当前的单路音视频数据的属性信息。

步骤405：对于当前的单路音视频数据，建立新的解码上下文。然后执行步骤403。

步骤406：判断当前的帧数据是否支持硬件解码，如果是，执行步骤408，否则，执行步骤407。

步骤407：对当前帧数据进行软件解码。软件解码通常由X86核心实现。本步骤完毕后，分别执行步骤409和410。

步骤408：对当前帧数据进行硬件加速解码。硬件加速解码通常由专用音视频解码芯片实现。本步骤完毕后，分别执行步骤409和410。

步骤409：判断当前的单路音视频数据中是否还有未处理的数据，如果是，返回执行步骤403，如果否，返回执行步骤401，即从主机端接收下一单路音视频数据。

步骤410：向主机端返回解码结果数据，同时向主机回传加速卡的状态。本步骤中解码结果基于步骤407和408的处理得到。并且，本步骤可以与主机端的步骤308衔接。

在一个实施例中，加速卡线程池包括音视频数据接收，音视频上下文管理(解封装与属性信息分析)，硬件解码，软件解码以及解码结果与状态数据回传线程。另外，加速卡的内存中设置有接收数据缓冲区，硬件待解码数据缓冲区，软件待解码数据传冲区以及回传数据缓冲区。前述步骤401至410基于上述线程以及数据缓冲区完成。其中，音视频数据接收线程从主机端接收数据，放入接收数据缓冲区；音视频上下文管理线程从接收数据缓冲区取出数据片段，首先根据节目ID确定是否是一路新的节目，假如是，对数据进行音视频解码属性信息分析，并将属性信息加入解码上下文表，假如不是新节目，则直接从解码上下文表中取出属性信息及上下文以备解码。得到属性信息及上下文后，从数据中逐一取出帧数据，按是否可以进行硬件加速解码来确定送入硬件待解码数据缓冲区或是软件待解码数据缓冲区。软件解码线程和硬件解码线程分别将各自缓冲区数据取出解码，并将解码数据和解码状态放入回传数据缓冲区。数据回传线程将状态与解码数据打包回传至主机。

图6示出了本发明一个实施例中的多路多格式多解码器加速卡解码数据流向及相应数据结构的示意图。该实施例的内存中设置解码上下文数据表存储区，硬件待解码数据缓冲区，软件待解码数据缓冲区以及回传数据缓冲区。其中硬件待解码数据缓冲区，软件待解码数据缓冲区可以合称为待解帧缓冲区。这些缓冲区均设置在解码处理器的***代理模块所连接的内存中，各个x86核心与专用音视频解码芯片均通过LLC模块以及***代理模块对内存中的相应存储区或缓冲区进行读写。参考图6，加速卡解码的整个流程均需参考解码上下文表，解码上下文表包括节目信息、解复用器上下文和解码器上下文三部分。加速卡中的各个线程围绕解码上下文数据表完成解码。解码卡接收到新的解码请求数据后，首先由音视频上下文管理线程检索节目信息中的节目ID，以确定该ID的音视频节目是否已在上下文信息表中存在属性信息，若判断为否，则认为当前节目为新节目，在解码上下文表中添加新的节目ID，若判断为是，则直接根据节目ID提取所有上下文信息，准备解码；软件和硬件解码线程主要使用解码上下文数据表中的解码器上下文，其中存储了参考帧、对应节目的解码器配置参数等，同时当解码出数据后，需要对解码上下文数据表中的参考帧等信息进行更新；数据回传线程将回传数据与节目ID等信息打包回传，从而使主机可以利用这些信息进行音视频内容上下文相关分析。

进一步地，图7示出了根据本发明的一个实施例的音视频数据接收线程的数据处理流程图，该数据处理流程包括下列步骤：

步骤411：通过PCIe通道接收主机端传来的数据。本实施例中，每次接收的数据长度通常为：4KB至4MB之间，其中，4KB是PCIe DMA的最小单位，4MB是Linux连续物理内存最大单位。对于基于不同的编码方式的节目，每次接收的数据长度可以包含的帧数为约为1帧至1000帧不等。

步骤412：判断接收数据缓冲区是否已满，如果是，则进入步骤413，否则，如步骤414。

步骤413：等待一个时间周期，这个时间周期的长度，可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤412。

步骤414：将收到的数据放入接收数据缓冲区，然后回到步骤411。

图8示出了根据本发明的一个实施例的解码结果与状态数据回传线程的数据处理流程图，该数据处理流程包括下列步骤：

步骤421：判断回传数据缓冲区是否有数据，如果是，则进入步骤422，否则，进入步骤425。

步骤422：通过PCIe通道将回传数据缓冲区中的数据发送到主机。

步骤423：判断PCIe通道的发送状态是否正常，如果是，返回执行步骤421，如果否，则执行步骤424。

步骤424：对PCIe通道的状态进行重置，然后回到步骤423。

步骤425：等待一个时间周期，这个时间周期的长度，可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤421。

另外，解码结果与状态数据回传线程的数据处理流程还用于将加速卡的状态数据回传给主机。返回形式可以是周期性返回，即每个一段时间，如1秒，将状态数据打包后，放入回传数据缓冲区，然后再传回主机(例如在步骤422中，将打包的状态数据与回传数据缓冲区中的解码结果一并回传给主机)。

在另一个实施例中，加速卡的状态数据回传还可以通过另一种形式实现。该实施例中，主机端发送主动状态查询，加速卡收到状态查询后，打包状态数据，放入回传数据缓冲区，然后再通过回传数据缓冲区传回主机。

图9示出了根据本发明的一个实施例的音视频上下文管理线程的数据处理流程图，该数据处理流程包括下列步骤：

步骤431：判断接收数据缓冲区是否有数据，如果是，执行步骤433，否则，执行步骤432。

步骤432：等待一个时间周期，这个时间周期的长度，可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤431。

步骤433：从接收数据缓冲区取出一个数据分段，该数据分段长度一般为4KB至4MB之间，即每个解码请求的实际数据大小。

步骤434：判断解码上下文数据表是否已有当前数据分段的属性信息，该属性信息是指解码所需要的属性信息，例如，节目信息、解复用器上下文和解码器上下文等。判断为是，则进入步骤438，否则，进入步骤435。

步骤435：提取当前数据分段中的属性信息。

步骤436：判断属性信息是否提取成功，如果是，进入步骤437，否则进入步骤442。

步骤437：在解码上下文数据表中添加新的解码属性信息表项，然后继续执行步骤438。

步骤438：对当前数据分段解封装得到相应的帧数据。

步骤439：判断当前数据分段是否可以硬件解码，如果是，进入步骤440，否则，进入步骤441。

步骤440：将解封装得到的帧数据放入硬件待解码数据缓冲区，然后回到步骤431。

图10示出了根据本发明的一个实施例的硬件解码线程的数据处理流程图，该数据处理流程包括下列步骤：

步骤451：判断硬件待解码数据缓冲区中是否有数据，如果是，则进入步骤452，否则进入步骤463。

步骤452：从硬件待解码数据缓冲区中取出一个待解帧数据段，调用硬件解码入口，向该入口送入待解帧数据段。硬件解码入口是操作***与硬件解码加速模块的接口。调用硬件解码入口就是设置硬件解码加速模块中相应的寄存器，这些寄存器包括待处理的数据缓冲区地址寄存器、输出缓冲区地址寄存器、以及解码参数寄存器。调用硬件解码入口后，硬件解码加速模块将自动去取数据和处理并将解码结果(即解码后的帧数据)和解码状态放到指定缓冲区。

步骤453：硬件解码线程查询硬件解码状态。其中，硬件解码状态包括：已经完成解码的帧数，已经完成解码的帧的标识，解码失败的帧的标识及其失败原因(失败原因可以用错误码的形式表征)。

步骤454：判断硬件解码器中是否有解码结果，如果是，进入步骤455，否则进入步骤462。

步骤455：从硬件解码器取出解码结果和解码状态。

步骤456：判断解码状态是否异常，如果是，进入步骤461，否则执行步骤457。

步骤457：判断回传数据缓冲区是否已满，如果是，进入步骤459，否则进入步骤458。

步骤458：向回传数据缓冲区写入解码结果和解码状态，然后执行步骤460。

步骤459：等待一个时间周期，这个时间周期的长度可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤457。

步骤460：判断所调用的硬件解码加速模块中是否还有待解帧数据，如果是，返回步骤453，如果否，返回步骤451。

步骤461：重置所调用的硬件解码加速模块，将当前数据分段送入软件待解码数据缓冲区，然后回到步骤451。

步骤462：等待一个时间周期，这个时间周期的长度可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤453。

步骤463：等待一个时间周期，这个时间周期的长度可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤451。

本实施例中，在进行硬件解码时，硬件解码线程通常只需将音视频结构体指针传给硬件，后续的上下文切换、码流解复用直到输出解码帧都由硬件完成，因此与硬件相关的解码上下文切换管理代价很小。而传统的基于众核处理器的解码技术本质上是纯软件解码，所有上下文切换数据均需软件加载，各处理器核的Cache为私有，因此对上下文的访问和管理相当于完全在内存中进行，而访存时延是Cache时延的10倍到数百倍。小核彼此间访问需要显式声明且经过可能需要mesh网数跳的数据访问才能完成一致性维护过程，相对位置不同的处理器核间Cache访问时延不可控，这些都造成其音视频解码下文切换代价极大。这导致基于众核处理器的解码技术的实际性能，尤其是对高清视频的解码能力受到极大的限制。而本发明能够提供强大的音视频解码加速能力，其FDH解码性能高于每秒600帧，720p解码性能高于每秒1200帧，D1解码性能高于每秒2500帧，CIF解码性能高于每秒5000帧，QCIF解码性能可达每秒万帧。与此同时，本发明功耗低，其峰值功耗低于65W，体积开销小，可集成在全高半长PCIe卡，易于与服务器对接。

图11示出了根据本发明的一个实施例的软件解码线程的数据处理流程图，该数据处理流程包括下列步骤：

步骤471：判断软件待解码数据缓冲区是否有数据，如果是，进入步骤472，否则，进入步骤480。

步骤472：从软件待解码数据缓冲区中取出一个待解帧数据段，开始软件解码。

步骤473：解码出一帧。

步骤474：判断解码是否正确，如果是，进入步骤475，否则进入步骤478。

步骤475：判断回传数据缓冲区是否已满，如果是，进入步骤477，否则，进入步骤476。

步骤476：向回传数据缓冲区写入解码结果(即已解码的数据帧)，然后执行步骤479。

步骤477：等待一个时间周期，这个时间周期的长度可以根据实际情况设定，本实施例中为10ms。等待时间届满后回到步骤475。

步骤478：丢弃当前帧数据，然后执行步骤479。

步骤479：判断当前待解帧数据段中是否还有待解帧，如果是，重新执行步骤473，即对下一个待解帧进行解码，如果否，则返回执行步骤471。

本实施例中，由于软件解码的通用处理器核与硬件解码单元共享高速缓存(所共享高速缓存即LLC，LLC通常是三级高速缓存，即L3Cache)，若需要在软硬件之间传递解码上下文，彼此的地址互相可见，常常能够免去访存开销。因此，在需要进行软硬件间上下文传递时，上下文传递的开销也大大减少。

图12示出了根据本发明的一个实施例的各个线程和各个缓冲区的关系图，其中，操作***的线程池中存在多个硬件解码线程和多个软件解码线程，每个软件解码线程各自独立地并行进行解码工作，多个硬件解码线程可共用一个解码硬件中的多个硬件解码资源，多个硬件解码资源是并行解码的。同时，如前文所述，本发明中通过减少解码上下文切换管理等管理方面的开销，使得加速卡能够在多种格式、多种解码器下快速切换，可以应对上千路的并发解码请求，且进行多路并发处理时不降低***性能。相对于基于众核处理器的解码加速卡，本发明在同等功耗，体积要求的前提下，显著地提高了加速卡的解码性能。

进一步地，图13示出了根据本发明一个实施例的加速卡端的单路音视频解码流程，具体包括下列步骤：

步骤501：单路音视频数据进入加速卡。

步骤502：对当前单路音视频数据解复用，获得解码器信息。

步骤503：根据所获得的解码器信息判断当前单路音视频数据是否支持硬件解码，如果是，进入步骤504，否则，进入步骤505。

步骤504：用专用音视频解码芯片尝试硬件解码，进入步骤507。

步骤505：进行Libav软件解码，进入步骤506。

步骤506：根据解码结果更新解码上下文数据表。返回步骤502。

步骤507：判断硬件解码是否成功，如果是，进入步骤508，否则，执行步骤505。

步骤508：继续进行硬件解码，然后执行步骤506。

不断执行上述步骤502至508，即可获得当前单路音视频数据的解码结果，该解码结果被存储于回传数据缓冲区，并由数据回传线程打包回传至主机。由于硬件解码中容错设计较软件解码简单，没有复杂的误码恢复机制，因此在处理需要尽可能从误码帧中解出数据的请求时，将硬件解码失败的数据交给软件解码流程，由软件解码使用更加复杂的误码恢复方法尝试重建数据。所以尽管解复用器解出的参数表明可以进行硬件加速，本实施中仍进行硬件尝试解码，若失败，则转为软件解码，在首次解码尝试后，即步骤507中，根据首次解码尝试的结果设置解码上下文中的软/硬件解码标志位，这样，后续数据均可以按照软/硬件解码标志位分发该路节目的任务数据给软件或硬件解码器。这种设计能够进一步地减少管理开销，从而提升加速卡的解码性能。

最后应说明的是，以上实施例仅用以描述本发明的技术方案而不是对本技术方法进行限制，本发明在应用上可以延伸为其它的修改、变化、应用和实施例，并且因此认为所有这样的修改、变化、应用、实施例都在本发明的精神和教导范围内。

Claims (10)

1.一种音视频多路并发解码加速卡，包括解码处理器和内存，所述解码处理器包括通用处理器，***代理模块，末级高速缓存模块，以及多种硬件解码加速模块；所述通用处理器和所述硬件解码加速模块均与末级高速缓存模块连接并共享末级高速缓存，所述末级高速缓存模块还与***代理模块连接，并通过所述***代理模块连接所述内存；

所述内存中设置硬件待解码数据缓冲区和软件待解码数据缓冲区；

所述通用处理器用于从主机端接收待解码数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区；还用于运行软件解码线程和硬件解码线程，所述软件解码线程和硬件解码线程分别将各自相应的缓冲区数据取出解码，并将解码结果和解码状态放入回传数据缓冲区；其中，所述硬件解码线程调用所述硬件解码加速模块，所述硬件解码加速模块通过所述末级高速缓存模块读取解码上下文并进行解码，向所述硬件解码线程返回解码结果。

2.根据权利要求1所述的音视频多路并发解码加速卡，其特征在于，所述音视频多路并发解码加速卡还包括与所述末级高速缓存模块连接的图形处理器，所述图形处理器中集成了所述多种硬件解码加速模块，并且所述图形处理器与所述通用处理器共享末级高速缓存。

3.根据权利要求2所述的音视频多路并发解码加速卡，其特征在于，所述的音视频多路并发解码加速卡还包括与***代理模块连接的I/O桥片和与I/O桥片连接的外部设备。

4.根据权利要求3所述的音视频多路并发解码加速卡，其特征在于，所述的音视频多路并发解码加速卡还包括PCIe接口以及实现PCIe接口双向传输的PCIe Switch芯片，所述PCIe Switch芯片连接在所述PCIe接口和PCIe控制器之间，所述PCIe控制器集成在所述解码处理器或者I/O桥片中。

5.根据权利要求3所述的音视频多路并发解码加速卡，其特征在于，所述通用处理器是SANDYBRIDGE，IVBBRIDGE，HASWELL，CRYSTALWELL或者BROADWELL构架的多核通用处理器，或者AMD多核通用处理器。

6.一种基于权利要求1～5中任意一项所述的音视频多路并发解码加速卡的解码加速方法，其特征在于，所述内存中设置硬件待解码数据缓冲区和软件待解码数据缓冲区；

所述通用处理器运行软件解码线程和硬件解码线程并执行下列步骤：

1)对于从主机端接收待解码数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区；

2)软件解码线程和硬件解码线程分别将各自相应的缓冲区数据取出解码，并将解码结果和解码状态放入回传数据缓冲区；其中，所述硬件解码线程调用所述硬件解码加速模块，所述硬件解码加速模块通过所述末级高速缓存模块读取解码上下文并进行解码，向所述硬件解码线程返回解码结果。

7.根据权利要求6所述的解码加速方法，其特征在于，所述内存中还设置接收数据缓冲区，所述步骤1)包括下列子步骤：

11)从主机端接收待解码数据，放入接收数据缓冲区；

12)从接收数据缓冲区取出数据片段，根据节目ID从解码上下文表中取出属性信息；

13)从数据片段中逐一取出帧数据，根据是否可以进行硬件加速解码将帧数据送入硬件待解码数据缓冲区或是软件待解码数据缓冲区。

8.根据权利要求7所述的解码加速方法，其特征在于，所述内存中还设置解码上下文数据表存储区，所述步骤12)中，所述解码上下文表从所述解码上下文数据表存储区中读出。

9.根据权利要求8所述的解码加速方法，其特征在于，所述解码上下文表包括节目信息、解复用器上下文和解码器上下文；

所述步骤12)中，所述通用处理器运行的音视频上下文管理线程检索节目信息中的节目ID，以确定该ID的音视频节目是否已在上下文信息表中存在属性信息，若判断为否，则认为当前节目为新节目，在解码上下文表中添加新的节目ID，若判断为是，则直接根据节目ID提取解复用器上下文和解码器上下文，准备解码；所述解码器上下文中存储了参考帧、对应节目的解码器配置参数；

所述步骤2)中，当解码出数据后，对解码上下文数据表中对应节目ID的参考帧信息进行更新。

10.根据权利要求9所述的解码加速方法，其特征在于，所述内存中还设置回传数据缓冲区，所述步骤2)还包括：软件解码线程和硬件解码线程将解码结果存储至回传数据缓冲区；

所述通用处理器还执行步骤：

3)将回传数据缓冲区的状态与解码数据打包回传至主机端。