异构多核的全高清H264解码系统设计

 原文地址：http://ti.eetop.cn/?action-viewnews-itemid-5338

感谢原文作者分享，基本普及了TI DSP&ARM架构的多媒体编解码使用。

作者：赖梓昌，杨斌  西南交通大学 信息科学与技术学院，成都 610031

摘要: 利用异构多核处理器OMAP4430在多媒体视频编解码上的运算优势,实现了全高清H264视频的实时解码。采用virtio缓存队列和RPMsg消息框架来实现基于异步通知的异构多核间数据通信，并结合TI公司IVAHD多媒体硬件加速引擎和针对多核进行的合理任务分配机制来提高解码器的工作效率。实验结果表明,此方法实现的解码速度达到35 F/s,能够完成对1080P全高清视频的实时解码。

引言
    随着移动互联网时代的到来、高清多媒体视频的普及、3D大型手机游戏的出现，单核嵌入式硬件平台已经难以满足复杂的计算需求。而异构多核处理器在视频编解码运算上具有强大的优势[1]，已经成为嵌入式处理器架构发展的趋势。目前高清视频编解码大多采用异构多核处理器内的DSP进行协同处理，通过片上通信机制实现核间多媒体数据传输。DSP相比软解码在速度和性能上得到了一定的提升，如DaVinci平台内置DSP能够实现720P视频实时解码[2]。但DSP运行时需要对信箱以及 DMA进行配置，占用较多的片上通信带宽，导致核间通信效率不高，同时DSP编解码效率与硬编解码器相比仍偏低。为了进一步提高全高清H264编解码性能，本文采用TI SoC OMAP4430异构多核处理器作为处理平台，其最大不同在于内置双核CortexA9主处理器、双核CortexM3协处理器及IVAHD多媒体硬编解码加速引擎。IVAHD引擎内部有7个针对各种视频编解码而设计的加速引擎，每个加速引擎拥有独立的数据存储器，可以在很大程度上降低模块间因为读写数据造成的竞争。同时采用virtio缓存队列[3]和RPMsg 消息框架[4]来实现基于异步通知的主处理核CortexA9与协处理核CortexM3间数据通信，具有大数据通信效率高、异步通知等优点。OMAP4430处理器内部的CortexA9双核处理器将运行高级嵌入式操作系统Linux，负责系统工作任务的调度、音频解码、用户界面交互，而其内部的CortexM3将充当辅助处理器核，管理IVAHD加速引擎完成解码任务，最后用实例验证设计的正确性。
1 主要技术
1.1 virtio缓存队列
    virtio是半虚拟化 hypervisor中位于设备之上的抽象层,为异构多核间数据通信提供了最底层的实现。它使用了两个基于异步通知的缓存队列(一个用于向协处理核发送数据，另一个用于从协处理核接收数据）和散列表，用于与远程异构处理器进行数据通信。每个队列最多包含有512个缓存，每个缓存的大小限制在512字节以内，缓冲池里面存放着通信数据。为了尽量减少共享内存，采用环形散列表，散列表每个表项包括了缓存的物理地址和缓存的大小，散列表存放在内存特定地址中，主处理器核与协处理器核基于互斥机制的共享内存方式进行访问。异构多核间访问virtio缓存池示意图如图1所示。

图1 异构多核间访问virtio缓存池示意图
    采用共享环形散列表进行异构处理器核间数据通信的好处主要有几个方面:
    ① 采用散列表表项表示数据缓存,可以减小共享内存区域的大小，提高系统内存使用率，同时允许变长数据传输;
    ② 采用中断方式通知目的处理器散列表的变化，减少了处理器盲目等待时间，提高了处理器的利用率;
    ③ 允许同时传输多个缓存数据，提高了系统通信的吞吐率。
1.2 RPMsg消息框架
    RPMsg(Remote Processor Messaging)是基于virtio技术的用于处理器核间数据通信的消息框架,提供协处理器核上电复位管理、消息通信等功能。
1.2.1 协处理器核复位管理
    协处理器核复位管理主要负责加载程序执行体到协处理器核的运行内存中、设置虚拟地址映射到物理地址MMU单元，当协处理器核遇段错误或内部代码异常时，输出直观的出错信息并且提供恢复机制,使得协处理器核可以重新使用。
1.2.2 消息通信
    RPMsg消息框架基于virtio缓存队列实现主处理器核和协处理器核间进行消息通信，RPMsg向系统注册了一条消息总线，并为每个CortexM3协处理器核创建相应的总线设备，而多个客户端驱动程序也注册在该消息总线上，并分配一个本地地址端口src和远程地址端口dst。当客户端驱动需要发送消息时，会把消息封装成virtio缓存并添加到缓存队列中以完成消息的发送,当消息总线接收到协处理器送来的消息时，会根据消息地址端口dst合理的派送给客户驱动程序进行处理。其示意图如图2所示。

图2 RPMsg消息总线工作示意图
1.3 IVAHD加速引擎
    H.264/MPEG4 Part 10是由ITUT视频编码专家组和ISO/IEC运动图像专家组(MPEG)联合提出的高度压缩数字视频编解码器标准[6]，被广泛应用于网络流媒体资源、HDTV等方面。与MPEG4、H263等标准相比,H264具有低码率、高画质、高压缩率和高可靠性等特点,适用于干扰严重、丢包率高的信道传输。
    H264解码器工作流程如图3所示，解码器从网络抽象层NAL中接收输入的数据帧，经过熵解码、重排列后得到量化系数矩阵X，量化系数矩阵在经过反量化和反变换后得到计算残差Dn，同时通过运动补偿和帧间预测或帧内预测得到预测块Pn,将Pn和Dn相加结果uFn经过环路滤波得到输出缓存图像Fn。

图3 H264解码器工作流程
    IVAHD引擎是TI公司针对嵌入式平台进行多媒体编解码加速而设计的第3代硬件加速引擎，支持H264、MPEG4、MPEG2、H263等常见的视频编解码标准。为了让CPU更有效地进行数据准备和逻辑功能控制，IVAHD集成了7个硬件加速引擎，它们和H264解码器各个功能模块的对应关系在图3中用虚线框表示，其中加速引擎名称core1～5所对应的模块功能分别是:熵解码、反量化和反变换、环路滤波、帧内预测、运动补偿。
2 系统设计
    全高清H264解码任务由主处理器CortexA9和协处理器CortexM3共同完成，CortexA9主要负责从多媒体文件中或网络数据流中进行数据的读取、多媒体数据包过滤分离视频流和音频流、构建RPMsg控制消息经过virtio缓存封装发送给协处理器CortexM3以设置IVAHD加速引擎的控制参数、向协处理器发送多媒体数据包进行H264解码、在协处理器完成解码任务后接收图像并通过DRM API[7]及KMS 模块[8]绘制到屏幕上。
    平台上有两个CortexM3处理器，分为Sys M3和App M3,都运行TI BIOS实时操作系统[9]，其中Sys M3主要负责创建与CortexA9通信的virtio缓存队列，对程序执行流程和CPU负载情况进行记录，接收A9发过来的缓存数据并进行参数解析，同时根据缓存中dst参数分派缓存到App M3的相应消息链表中。而App M3协处理器则完成实际的解码工作，通过运行于嵌入式平台的Codec Engine[10]来完成对IVAHD加速引擎的操作。App M3提取消息链表中消息请求，相应设置IVAHD加速引擎的状态和初始化参数，在进行实际解码时，通过Codec Engine来调用IVAHD加速引擎来完成解码任务，并将解码结果通过缓存队列发送回CortexA9处理器。整个系统解码的框架图如图4所示。

 

图4 H264解码器工作框架图
3 系统实现
3.1 CortexA9软件实现
    CortexA9运行Linux操作系统，包括内核模块omapdce.ko和virtio缓存、RPMsg总线驱动程序设计和FFmpeg多媒体库[11]及DRM显示接口调用。
3.1.1 virtio缓存队列实现 
    virtio缓存队列以共享散列表的方式和协处理器进行数据通信，通过中断方式通知对方散列表的添加,包括以下几个方面：
    ① Irq_require()注册中断函数，Register_bus_type("virtio")向系统注册virtio总线;
    ② Regsiter_virtio_driver(&virtio_driver)向virtio总线注册一个驱动客户端,用于创建向RPMsg总线注册的设备;
    ③ 系统在发现协处理器后通过Register_virtio_device(&virtio_device)向virtio总线注册一个设备，设备内部含有创建virtio缓存队列的函数指针;
    ④ virtio_bus->match(&virtio_device,&virtio_driver)函数将匹配virtio_driver与virtio_device是否合适，如果匹配成功,virtio_driver->probe(virtio_device)来创建send_virqueue、recv_virqueue及注册到RPMsg的rpmsg_device,这样virtio缓存队列就和RPMsg总线联系在一起了。
3.1.2 RPMsg消息框架实现
    RPMsg总线将挂载许多rpmsg_driver和rpmsg_device，rpmsg_driver都有本地端口src和目的端口dst属性，每次发送消息时会调用rpmsg_send((void*)data,src,dst)将消息添加到virtio的缓存队列中，而当消息msg到达RPMsg总线时，总线把msg分配给dst属性和msg->dst相同的rpmsg_driver，并调用rpmsg_driver->callback()进行消息处理。
3.1.3 omapdce.ko驱动模块的实现
    omapdce.ko模块将作为一个rpmsg_driver，其完成了应用程序引擎相关API的内核实现，主要包括ioctl_engine_open()、ioctl_viddec_create()、ioctl_viddec_control()、ioctl_viddec_process()，它们提供了应用API engine_open、viddec_create()、viddec_control()、viddec_process()的驱动实现，这些驱动函数将调用RPMsg总线rpmsg_send()、rpmsg_recv()与协处理器进行消息通信以完成工作任务。 
3.1.4 解码应用viddectest实现
    H264解码应用程序viddectest的工作主要分为以下几个方面：
    ① Linux显示接口DRM初始化，通过Drmopen()函数打开/dev/dri/card0设备文件,获取设备资源drmModeGetResources()，创建帧缓存drmModeAddFB2()及设置输出分辨率及模式drmModeSetCrtc();
    ② FFmpeg多媒体库的调用，通过AVOpenStreamFile()打开多媒体文件，AVFindStream()分离出音频流和视频流，然后依次通过AVGetPacket()读取视频流数据包送去解码器进行解码；
    ③ 加速引擎初始化和利用消息总线进行解码数据通信，通过Engine_open()打开H264解码引擎，Viddec3_create()创建一个解码实例对象，Viddec3_control()设置解码所需的参数，Viddec3_process()将用RPMsg消息总线送出解码数据流并接收解码后的图像缓存数据。应用Viddectest解码流程图略——编者注。
3.2 CortexM3软件实现
    双核CortexM3运行TI公司 BIOS实时操作系统，负责与主处理器的virtio缓存队列通信及通过Codec engine调用IVAHD加速引擎实现H264解码，运行流程图略——编者注。主要包括以下内容。
    ① virqueue_create(&send_queue),virqueue_create(&recv_queue)创建与CortexA9主处理器通信的 virtio发送及接收缓存队列；
    ② Message_get_queue(&recv_queue)从virtio缓存队列获取主处理器发过来的请求数据，Message_send_queue派发到App M3的消息队列中；
    ③ App M3将获取消息链表的消息，设置IVAHD加速引擎的工作状态并初始化，如果为解码消息则通过Codec Engine 调用IVAHD加速引擎来完成解码过程；
    ④ 将解码后的图像缓存封装成virtio缓存，调用Message_send_queue(),通过virtio缓存队列发送回主处理器调用DRM进行显示输出。
4 测试 
    本文在OMAP4430开发平台上实现了基于异构多核的全高清H264解码，为了测试解码器的性能，将针对不同比特率的720P、1080P 的网络视频文件Big_Buck_Bunny_Sunflower 进行解码测试，测试结果如表1所列，同时采用FFmpeg开源库项目软解码进行测试，其对比图略——编者注。
表1 H264解码系统解码测试表

 

    本次设计的H264解码器在解码720P(1280×720)和1080P(1920×1080)视频时分别达到60和34 fps，相比FFmpeg开源H264软解码器效率提高了一倍。而普遍全高清流畅视频的帧率为30 fps[12]，能够达到实时解码性能需求。
结语
    随着移动互联网时代的到来，在移动终端上流畅播放全高清视频成为日常需求。为此本文采用移动SoC OMAP4430异构多核处理器为实验平台，通过virtio缓存队列和RPMsg消息框实现了异构多核间多媒体数据通信，同时结合IVAHD多媒体硬件加速引擎设计了一款全高清H264视频硬解码系统。实验结果表明，设计的解码系统具有解码速度快、解码过程由硬件加速器完成无需消耗主核运算资源、核间通信效率高、功耗小等优点，比开源FFmpeg软解码器在性能上提升了一倍，满足实时性要求。