谈谈1080P@60 H.265实时编码器的架构设计。
首要考虑1080P@60的实时编码能力，
即设计的编码器需要具备不小于每秒60帧的编码能力，
不允许丢帧的前提下，每帧编码时间不能大于16.6ms，
按照编码主频可以推算出每帧的时钟周期数cycle，或反推，
一般情况下，可以先根据FPGA/ASIC器件平台的fmax确定主频，
此处的fmax并非器件理论上的最高主频，
而是设计RTL代码在器件上能运行的fmax，
不同设计风格或者不同开发者开发代码，fmax可能会有差别。
对于FPGA而言，如xilinx kintex7系列，
类似视频编码这种较大型工程，一般fmax可不低于200M，
速度更快的FPGA器件一般可达300M以上，
ASIC器件则根据工艺不同，差异较大，
同样工艺条件下比FPGA要高不少。
如zobovision开发的H.265 1080P@60实时编码器，
可在xilinx k7325t或ku3p这样的FPGA器件上运行，
fmax在ku3p器件的fmax约300M，
实时运行1080P60所需的主频为265M左右。
以主频250M为例，
每帧平均分配的时钟周期数为4166666，
按64x64的CTU基本编码单元，
平均每个CTU分配8170cycle，
CTU共有4096像素，每个像素2cycle；
对于编码，每个像素大致需要经历几个过程，
帧内或帧间模式粗选，
帧内预测或帧间预测数据计算，
残差数据DCTQ及IDCTQ重建，
RDO最优选择，
码流信息编码，
去块滤波Deblock等。
要完成这么多的功能及选择，
1pixel 2clk?
显然是不够的，
不同功能模块的流水级设计是必须的。
对于H.265/HEVC而言，
以CTU为流水级基本单元，
CTU大小可设定，最大64x64，最小16x16，
一帧编码中只会固定选择一种尺寸，
常见的有64x64和32x32，
理论上尺寸越大，计算复杂度会更高，编码效率会好些，
zobovision编码器固定选择CTU 64x64。
不同的编码功能模块，
有些是必须合并划分到同一级流水单元的，
主要看编码数据流的依赖性，
CTU编码单元又会进一步划分成尺寸更小的TU/PU单元，
以帧内预测为例，每个PU单元会参考相邻的重建像素，
即当前PU块的预测数据计算需要等待相邻块重构数据完成，
也就是说，帧内预测计算、DCTQ、IDCTQ、RDO选择，
这几个不同功能模块实现了从预测数据到重建数据完成的过程，
它们需要被设计到同一个级流水中；
至于帧内模式粗选，以及帧间运动估计功能，
数据的依赖性较少，取决于不同的硬件算法，
它们可以单独划分为一级流水，或多级流水，
如运动估计粗选，可以基于整像素，亚像素等进行多级流水设计，
多级流水可以提供压缩效率，但通常硬件资源也会有所增加。
码流编码和Deblock去块滤波，
是相对独立的功能模块，
它们可以单独划分为一级或多级流水。
不同的流水级，
所需cycle可能有所不同，
有些是可以通过增加并行处理降低cycle数目，
有些却很难通过并行加速，因处理数据存在反馈依赖关系，
如前面所述的帧内预测到DCTQ/IDCTQ重构的过程。
从绝对可控的角度，
一帧视频所需最小cycle数目，
或，一帧编码所需最长时间，
取决于最耗时的流水级处理单元；
当1080P@60的实时主频设定在250M时，
每级流水处理cycle要控制在8000左右，
基本1pixel分配2clock(clk),
对于特定功能模块，
不同的cycle要求将导致不同的硬件算法选择。
zobovision H.265视频编码器，
各流水级处理cycle保持一致，均为8400cycle，
每帧编码所需时钟周期数一致，
保证绝对可控的帧编码时间。
对于1pixel 2clk处理时间，
到底是个什么概念，
下面举例说明。
对于一个64x64的CTU单元，
共有4096pixel，一个流水级可分配8192clk，
假设CTU最终都划分为4x4的帧内预测PU单元，
每个i4x4块分配32clk,
因为帧内预测，需要参考相邻块重建后数据，
基本可认为，前面i4x4编完，后面i4x4才可启动，
即，每个i4x4需要在32clk内完成既定任务，
共有哪些任务呢，主要包括：
1）i4x4帧内预测数据计算；
2）4x4 2D-DCT运算；
3）Q4/IQ4运算
4）4x4 2D IDCT运算
5）RDO判决
6）i4x4重建数据生成;
上述只是i4x4帧内编码的基本任务，
要提高压缩效率，
还需要类似RDOQ和RDO递归操作，
计算复杂度更高，
如何在32clk内实现，
那只能是各显神通了，
不同硬件架构及实现方法，
结果差异化就容易显现。
（转载请勿更改文章标题和内容）