基于众核平台的多路超高清视频编码系统设计

姚　佳，高志勇，张小云

(上海交通大学 图像通信与网络工程研究所， 上海 200240)

基于众核平台的多路超高清视频编码系统设计

姚佳，高志勇，张小云

(上海交通大学 图像通信与网络工程研究所， 上海 200240)

摘要:首次展示一套基于低功耗众核TILE-36处理器平台的多路超高清实时系统。该系统可以同时编码4路HEVC超高清视频，并经过TS复用后以常码率的形式发送到解码端。为了保证编码系统稳定运行，采取了基于非线性R-Q模型的闭环码率控制来调整编码器的输出码率，同时引入缓存控制机制来确保系统总延时恒定，最后加入了基于帧数统计的时钟同步机制来同步系统中各模块的时钟。实验显示该系统能够长时间稳定运行，并具有同时编码4路HEVC超高清视频的能力。

关键词:多路超高清；众核；码率控制；实时系统

为了满足用户对更高质量的视频服务的需求，设备制造商对视频采集设备和播放设备的性能进行了大幅提升。然而当今主流的视频编码器H.264并不能高效地对超高清视频进行压缩。视频编码联合组制定了新一代的视频压缩标准HEVC。相比于H.264/AVC和HEVC在相同的视频质量下可以大大提高视频的压缩率，但实现复杂度更高[1]。

HEVC继承了H.264/AVC基于块的混合编码架构，并引入了更加灵活的编码树块，自适应样点补偿以及Tile等新特征。在这些新特征中更加灵活的编码树块对HEVC编码性能提升最大，但这也引入了更多的运算复杂度，从而限制了HEVC编码器在实时系统中的应用。众核处理器在一个处理器中集成了几十甚至上百个完整的可独立运行程序指令的处理内核，其并行计算能力相比单核处理器有大幅提升。众核处理器为HEVC并行编码器提供了一个很好的实现平台。

本文在实现多路超高清HEVC视频实时编码系统过程中，主要解决了几个关键问题。首先，由于更复杂的帧间编码，HEVC编码器的输出码率相比于上一代标准H.264波动更大。而多路码流复用后输出码率的叠加会使码率波动加剧。针对这一问题，本文提出了一种闭环码率控制算法，实现了编码器的恒定码率输出。

其次是系统的端到端延时的问题。端到端延时是直播应用中影响消费者观看体验的一个关键因素。

闭环码率控制中引入的缓冲器会增加系统总延时。为了降低总延时，需要尽量减小编码器输出缓冲器的大小。这需要对编码器的码率控制进行优化，尽量降低编码器输出码率的波动幅度，从而减小缓冲器的大小。

最后是系统中各个模块时钟同步的问题。本文提出的多路超高清实时系统由3个模块构成，包括视频源、编码器和解码器。每个模块有独立的本地时钟。各个模块之间本地时钟误差的累积会造成总延时的偏移，从而影响到系统的稳定运行。MPEG2-TS标准规定编码器必须周期性地发送本地的节目时钟参考(PCR)[2]到解码端，用来同步编码端和解码端的时钟。在此基础上，本文提出一种时钟同步机制来同步视频源和解码器的本地时钟。

1实时系统架构

本文基于Tilera公司提供的搭载有4片众核处理器TILE-Gx36[3]的低功耗平台，实现了多路超高清视频实时编码系统。该平台配备带HDMI输入的FPGA视频采集卡，用于实时视频的采集。每片TILE-Gx36处理器上集成了36个独立的核，单核频率可达1.2 GHz。每片TILE-Gx36处理器负责编码一路超高清视频。为了实现各个处理器之间高效安全可靠的数据传输，TILE-Gx36集成了高性能众核可编程智能包引擎(mPIPE)模块。

整个系统架构如图1所示。4路视频输入源为1路4K超高清摄像机和3路超高清播放器。首先，FPGA采集卡对输入的原始视频进行预处理并转储至DDR3内存中。随后，运行在4片TILE-Gx36处理器的4个HEVC编码器J265分别对内存中的4路视频序列进行编码。然后，编码器1，2，3通过mPIPE输出3路TS流到编码器4。最后，4路TS流打包复用成1路TS流，并通过编码器4的发送线程，以RTP流方式发送到解码端。解码端通过4个解码器同时解码4路超高清码流并显示。图2展示了1个编码器中主要的线程分配。

图1　多路超高清系统框图

图2　线程分配框架

每片TILE-Gx36处理器中的两个核分别绑定到采集线程和发送线程。采集线程负责获取4K 原始视频序列并将原始序列转存到在内存里开辟的缓冲器中。剩下的34个核用来进行HEVC并行编码，其中每个核负责编码一个Tile。当一帧图像的所有Tile都编码完成后，编码器将该帧图像以ES流的形式输出到编码器的码流缓冲器 (ES buffer) 中。编码开始后，发送线程开始从ES buffer中读出数据并完成打包发送工作。该系统中，编码器输出码率不稳以及各模块时钟不同步等问题会导致ES buffer上下溢的现象，相应的解决方案在下文详细描述。

2关键机制

2.1码率控制

该实时系统的码率控制需要实现两个目标，一是控制编码器的输出码率，保证输出缓冲器不发生上下溢；二是在此基础上尽量不损失视频质量。本文采用的码率控制算法在缓存控制的配合下使编码器达到设定的输出码率，画面质量良好，其流程图如图3所示。

图3　码率控制流程图

在编码一帧原始图像之前需要对其进行场景检测。当检测到某一帧图像为场景切换帧时，对其采用帧内编码。由于一个GOP中帧内编码帧(I帧)的复杂度无法确定，所以每个I帧的量化参数是由之前每个I帧的QP取平均得到。帧间编码帧(P帧)以及P帧中Tile的量化参数(QP)由非线性R-Q模型[4]计算得到。R-Q模型是基于模糊复杂度来实现的，根据总的模糊复杂度与总的目标比特来计算P帧的QP，计算公式如下

(1)

式中：qscale基于模糊复杂度得到，在一定程度上可以反应编码单元编码后的比特数。P帧以及每帧的各Tile的QP通过式(1)得到。qscale的计算过程为

(2)

cplxrSumi=cplxrSumi-1+tilebit

式中：cplxrSumi表示第i个编码单元的预测复杂度。对于人眼不敏感的高细节复杂度或者高运动场景，可以增加QP而不会损失太多的视觉质量。因此，对于cplxrSum越大的编码单元，经计算得到的QP也越大，编码后生成的比特数相应也越少，反之亦然。wantedBitsi是累计的总目标比特数，qscaleinit为根据经验得到的一个初始值。tilebit为编码一个tile的实际比特数，cplxrSumi-1为前一个编码单元的复杂度。tile_num为一帧划分的tile个数，wantedBitsi-1为前面所有编码单元的预测复杂度，framerate为编码帧率，Bitrate为设定的编码器输出码率。考虑到图像质量的平滑，一帧图像中每个Tile的QP必须限制在[frame_QP-2，frame_QP+2]之间。为了保证画面质量的连续性[5]，相邻两帧图像之间的QP差值限制在[-2，2]区间内。

本文根据已编码比特和缓冲区状态动态的调整码率控制中求得的QP值，实现了闭环码率控制。作为闭环码率的一部分，本文在缓存控制中设置了两个上溢阈值overflow1和overflow2以及下溢阈值underflow来协助码率控制，如图4所示。

图4　编码器输出缓冲器功能框图

当ES buffer的占有量达到overflow2时，编码单元QP加2。当ES buffer的占有量上升到overflow1时，编码单元的QP加3，从而减小编码器的输出比特数。设置两个上溢阈值是为了防止ES buffer的缓存出现较大波动，引起图像QP波动，从而导致视频质量不稳定。ES buffer的占有量降低到underflow时，QP减2。当ES buffer出现下溢的时候，通过插入TS填充包来保证ES buffer的输出码率恒定。

2.2延时控制

在不考虑编码和解码时间的前提下，常码率系统的端到端延时主要是由编码器输出缓冲器和解码缓冲器带来的。常码率系统的初始延时delay为

delay=ES_init_delay+DTS0-PCR0

(3)

式中：ES_init_delay为设定的ES buffer的初始缓存时间；DTS为一帧图像的解码时间戳，用来指示解码器在规定的时刻解码该帧；PCR为每路节目的节目时钟参考，用来将解码器的本地时钟同步到编码器的本地时钟[2]；DTS0为视频流中第一帧的解码时间戳；PCR0为发送给解码器的第一个PCR。因为PCR0将解码器的本地时钟校正到PCR0，而DTS0指定解码器要等到DTS0时刻才能开始解码第一帧，所以当二者同时到达解码器时，二者的差值代表了解码缓冲器的初始缓存量。当某一帧的DTS小于当前解码器的系统时间时，解码器会丢弃该帧。此时由于没有可供解码的图像，解码缓存器处于下溢状态。

实时系统端到端的总延时计算如下

(4)

式中：ES_occupancy为当前编码器输出缓冲器中缓存的数据量。DTS-PCR表示当前帧在解码缓冲器中需要等待的时间，即解码缓冲器的缓存大小。当实时系统运行过程中延时恒定时，式(6)中的delay等于式(5)的delay，即系统总延时始终等于初始延时。同时为了防止解码缓冲器出现下溢，PCR须小于DTS，故由式(6)可知

ES_occupancy≤delay×bitrate

(5)

在保证ES buffer不出现上溢的前提下，只要满足式(8)，式(7)则一定成立

ES_buffer_size=bitrate×delay

(6)

将式(8)代入式(6)可以得到

ES_buffer_size=ES_occupancy+(DTS-PCR)×

bitrate

(7)

由式(5)和(9)可知，当设置ES_init_delay与(DTS0-PCR0)×bitrate之和等于ES buffer的大小时，系统运行过程中只要保证ES buffer不发生上溢，解码缓冲器就不会发生下溢。因此两个buffer的缓存量之和始终等于ES buffer的大小，实时系统运行过程中可以保持延时恒定。

由式(8)可知，减小ES buffer的大小是降低系统端到端延时的关键。故本文采取闭环码率控制方案，通过向码率控制实时反馈ES buffer的缓存量来达到减小输出码率波动的目的，从而使ES buffer尽可能小，系统延时也更低。

2.3系统时钟同步

假设视频源的输出帧率为F。编码器按照本地时钟接收到的实际帧率F′可以表示为

(8)

式中：camera_clock和encoder_clock分别代表摄像机(视频源)和编码器的本地时钟频率；F为摄像机的输出帧率即编码器默认的视频帧率。由式(10)可知，camera_clock低于encoder_clock会导致F′高于F。比如视频源的输出帧率为30 f/s(帧/秒)，但由于时钟频率的差异，编码器实际接收到的帧率为30.03 f/s。此时因为码率控制中每帧图像的目标比特数等于目标码率除以帧率F，所以每帧图像编码出来的实际比特数偏大，从而导致编码器的实际输出码率始终高于目标码率。这样会使ES buffer一直处于上溢状态。在这种情况下，闭环码率控制会调整编码图像的QP，使其一直处于最大值，图像质量因此不断恶化。

为了同步编码器和视频源的时钟，需要得到二者之间的比例关系。本文通过统计编码器每接收100×F帧的时间作为视频源的一百秒，得到二者时钟之间的差值，见步骤1)和步骤2)，然后利用这个统计时间调整PCR，从而使解码器的时钟同步到视频源上。相应的PCR校正机制如下：

1)编码器连续获取100×F帧图像，统计编码器该时段的系统时间t。

2)计算Δt=|t-100|，Δt大于PCR校正阈值转到步骤3)，小于则转到步骤4)。

3)PCR的校正值PCR_adjust_step=Δt/(20×count)。其中count为发送线程每秒的发送PCR次数。每100 s累积的误差在后续20 s内校正，所以再除以20。然后转至步骤1。

4)将Δt累加到下100 s的Δt中，然后转至步骤1)。

因为编码器的输出码率等于数据流中相邻两个PCR之间的比特数除以两个PCR的差值，所以为了匹配编码器实际的输出速率，输出缓冲器每次输出的数据量也要根据PCR的调整幅度作相应的调整。ES buffer每次输出的数据长度应为

(9)

实验结果证明该时钟同步方案能有效防止编码器输出缓冲器的上下溢从而使系统稳定运行。

3实验结果

3.1实验条件

视频源为1台4K超高清摄像机和1台多路超高清播放器，通过4根HDMI1.4线连接到众核平台上。每路编码器的配置参数如表1所示。

表1单路编码器配置参数

参数参数值或说明比特率/(Mbit·s-1)6帧率/(f·s-1)15GOP结构IPPPESBuffer初始缓存/Mbit3DTS-PCR初始值/s0.5ESBuffer大小/Mbit6

3.2实验结果

解码器能够实时播放四路超高清节目，播放过程中没有发生卡顿或者卡死的现象，图像质量良好。实验结果显示单路节目的端到端延时约为1～2 s，4路节目总的输出码率为24 Mbit/s，同时本文提出的码率控制和时钟同步机制能有效避免ES buffer发生上下溢。整个系统能够长时间稳定运行。

图5为演示实物图。其中1台4K摄像机和1台多路超高清视频码流仪作为众核TILE-Gx36处理器平台的输入。众核平台通过1根网线连接到解码器。解码器通过4路HDMI1.4将解码后的视频输出到显示器上进行播放。

图5　演示实物图

4小结

本文基于TILE-Gx36众核平台实现了一个多路超高清实时系统，并针对HEVC编码器输出码率波动较大提出了一个有效的应用于实时系统中的码率控制方案。同时，本文还提出了相应的延时控制机制和时钟同步机制，使系统在常码率信道中能稳定运行并保证端到端延时恒定。实验结果显示本文提出的系统拥有同时实时编码4路4K HEVC视频的能力，即该系统拥有编码8K视频的能力。

参考文献：

[1]POURAZAD M T， DOUTRE C， AZIMI M， et al. HEVC： the new gold standard for video compression：how does HEVC compare with H. 264/AVC?[J]. IEEE transations on consumer electronics magazine，2012， 1(3)：36-46.

[2]IEC I S O. 13818-1, Information technology generic coding of moving pictures and associated audio information： systems[S].1996.

[3]Tilera.[EB/OL].[2015-11-13]. http：//www.tilera.com/.

[4]LIU Y， LI Z G， SOH Y C. A novel rate control scheme for low delay video communication of H.264/AVC standard[J]. IEEE transations on circuits and systems for video technology， 2007， 17(1)：68-78.

[5]WU J， CAI J. Quality-smoothed encoding for real-time video streaming applications[C]//Proc. the Ninth International Symposium on Consumer Electronics， 2005(ISCE 2005). [S.l.]：IEEE，2005：445-449.

姚佳，硕士生，主要研究视频编解码传输；

高志勇，博士生导师，主要研究高速图像与视频处理、数字电视等；

张小云，硕士生导师，主要研究方向为视频编解码、高速视频处理等。

责任编辑：时雯

Multi-channel UHD video encoding system based on many-core platform

YAO Jia，GAO Zhiyong，ZHANG Xiaoyun

(ImageCommunicationandNetworkEngineeringInstitute，ElectronicEngineering，ShanghaiJiaoTongUniversity，Shanghai200240，China)

Abstract:In this paper， a multi-channel ultra-high definition (UHD) encoding real-time system is presented for the first time， which is based on the many-core TILE-Gx36 processors platform with low-power consumption. This system can simultaneously encode four UHD video inputs in HEVC， and transmit the encoded streams to the decoder after the MPEG transport stream (TS) multiplexing in constant bitrate (CBR). To ensure the system running stable， a closed-loop rate-control mechanism based on nonlinear R-Q model to adjust the output bitrate of encoder is proposed， and a buffer-control mechanism is used to make the system latency constant， in the end a clock synchronization mechanism based on the statistics of frame number is proposed to synchronize the clocks in the real-time system. Experiments show that the proposed system can keep stable running for a long time， and has the capacity of encoding 4-channel UHD video simultaneously.

Key words:HEVC； multi-channel UHD； many-core； rate control； real-time system

中图分类号：TN949.292

文献标志码:B

DOI：10.16280/j.videoe.2016.04.002

基金项目：国家自然科学基金项目(61301116)

作者简介：

收稿日期：2015-11-16

文献引用格式：姚佳，高志勇，张小云. 基于众核平台的多路超高清视频编码系统设计[J].电视技术，2016，40(4)：7-11.

YAO J，GAO Z Y，ZHANG X Y. Multi-channel UHD video encoding system based on many-core platform [J].Video engineering，2016，40(4)：7-11.