用Zynq SoC 设计低时延H.264系统

来源：Xilinx

发布时间：[2014-03-10]

　　小型快速的流式视频系统结合采用微型H.264核和赛灵思Zynq SoC。

        ASSP架构不灵活，而基于FPGA微处理器组合的系统虽然尺寸大但较为灵活，一直以来设计人员为创建PCB占位面积小的基于IP的流式视频系统，除了在这两者之间反复权衡外别无他选。将软核微处理器集成到FPGA,就无需单独的处理器和DRAM，但最终系统的性能可能无法与以外部ARM®处理器为核心且可能还包括USB、以太网及其它有用外设构建的解决方案所提供的性能相媲美。随着赛灵思Zynq®-7000 All Programmable SoC 和小型H.264核的问世，现在仅用一组DRAM就可在超小型PCB板上构建出一个具有用多条高速AXI4总线连接起来的ARM双核和高速外设所实现的高性能的系统(见图1)。

　　虽然针对FPGA的H.264核问世已有相当长的一段时间，但至今仍没有一款H.264核够快够小，能够达到足以转换1080p30帧视频的水平，而且仍旧适用于小型低成本器件。将A2e Technologies公司的最新微型H.264核与Zynq SoC结合使用，可构建一种低时延系统，该系统能够以15-60fps的不同帧速率对720p-4K之间的多种视频流进行编/解码。将A2e Technologies H.264核集成到Zynq SoC器件中，可大幅缩减板级空间并明显减少组件数，同时在Zynq SoC集成ARM双核还可避免使用单独的微处理器及其必须连接的存储体。

　　图1 - 基于单芯片 Zynq SoC的视频压缩系统 (上)与基于双芯片处理器和FPGA的视频压缩系统对比

　　这样可以构建出一个以Linux驱动程序和实时流协议(RTSP)服务器为核心的完整流式视频系统，该系统能够对来自两个摄像头的1080p30帧视频进行压缩，且端到端时延约为10毫秒。A2e Technologies H.264核提供纯编码版和编/解码版两个版本。此外，还有一款低时延版本，可将编码时延降至5毫秒以下。1080p30纯编码版需要10000个查找表(LUT)，或者说会占用Zynq Z7020 FPGA架构25%左右的资源，而编/解码版则需要11,000个查找表。

　　基于SOC-FPGA的系统

　　基于Zynq SoC的产品比采用特定应用标准产品(ASSP)构建的产品灵活性更高。例如，通过在FPGA架构中内置4个H.264核，并将每个摄像头输入端连接到FPGA，就可以很容易构建一个支持1080p30输入的系统。许多ASSP产品只有两个输入端，这让设计人员不得不想办法多路复用若干视频流到一个输入端。每个A2e Technologies H.264核能够处理六个VGA分辨率摄像头或一个1080p30分辨率摄像头。因此，有可能构建一个双核系统，以便对来自12个VGA摄像头输入的视频进行压缩。

　　ASSP产品通常仅对已解码视频提供屏幕视控(OSD)功能，这迫使设计人员将OSD信息作为元数据发送或使用ARM内核测定视频帧时间并以编程方式将OSD数据写入视频缓冲区。在FPGA中，在进行视频压缩前添加OSD如同访问IP模块一样简单。同时在压缩引擎前添加鱼眼镜头校正等其它处理模块，也相对容易。此外，FPGA还支持功能的现场与未来升级，例如添加H.265 压缩功能。图2是带有两个1080p30摄像头输入的H.264压缩引擎方框图，其中OSD适用于未压缩图像。

　　如何应对延时

　　某些应用程序，如遥控飞行器(RPV)的控制，是基于遥控装置发回的流媒体图像反馈。为了控制遥控装置，从传感器发送视频至压缩引擎到解码图像显示(称为“玻璃对玻璃”)之间的时延通常要小于100毫秒。一些设计人员将时延规定在50毫秒内。总时延是如下几项的和：

　　视频处理时间(ISP、鱼眼镜头校正等)

　　•填充帧缓冲的延迟

　　•压缩时间

　　•发送数据包引起的软件延迟

　　•网络延迟

　　•接收数据包引起的软件延迟

　　•视频解码时间

　　许多系统采用硬件对视频进行编码，但最终却采用标准的视频播放器进行解码，如在PC上运行的VLC。即使媒体播放器的缓冲延迟可从一般的500-1000毫秒大幅减少，但时延仍然远远超过50毫秒。要真正控制时延并保持在绝对最低水平，就需要对已压缩视频流进行硬件解码，而且要求缓冲最小。

　　H.264编码器时延通常以帧来表示，如一般在压缩开始前必须缓冲一个完整帧的时间。假设编码器速度可以提高，那么仅通过帧速率加倍即可降低编码时延，也就是说，帧速率为30fps时每帧时延为33毫秒，而帧速率为60fps时每帧时延则为16.5毫秒。

　　一种典型的流式视频系统采用RTSP服务器在摄像头与客户端(解码/记录)设备之间创建流式视频连接。RTSP服务器将已压缩的视频传送至客户端以供显示或存储。

　　很多时候，由于摄像机和编码器的性能限制该方案无法实施。因此，该解决方案是专门设计用于低延编码器。而最新A2e Technologies低延时编码器只有16个视频线才需要在压缩开始前进行缓冲。对于1080p30视频流而言，时延不足500微秒(µs)。而对于480p30视频流而言，时延则低于1毫秒。设计人员采用这种低时延编码器可构建出时延可预测且很低的系统。

　　为使总时延最小化，必须同时最大限度地降低编码侧和解码侧上缓冲、网络协议栈、RTSP服务器/客户端等引起的时延，因为软件路径会产生很长的时延，而在这种情况下采用低时延编码器毫无意义。RTSP服务器通常用来在服务器(摄像头)与客户端(解码/记录)设备之间创建流式视频连接。连接建立后，RTSP服务器会将压缩的视频传送至客户端以供显示或存储。

　　延时最小低化时延

　　通常情况下，服务器和客户端的软件组件只要求与带宽匹配，方便传送压缩视频，而不是为了最小化时延。而如Linux之类的非实时操作系统则很难保证时延。典型的解决方案就是为服务器和客户端创建低时延自定义协议。但这种方法的不足之处就是不符合行业标准。另一种方法是采用一种类似RTSP的标准，通过对软件的低层进行修改来最小化时延，同时保证符合各项标准。

　　然而，也可采取措施尽量减少内核与用户空间之间的拷贝操作，从而减少相关时延。

　　图3  完整编/解码系统方框图

　　而就整个软件路径而言，要减少时延，就需要将RTSP服务器和压缩信息转发任务分离，从而用Linux驱动程序替代RTSP服务器执行发送任务。

　　为了降低时延，我们对A2e Technologies低时延RTSP服务器进行了两处修改。首先，移除转发路径上的RTSP服务器。RTSP服务器仍采用实时控制协议(RTCP)维护统计数据，并随网络目标地址(即IP或MAC目的地地址)的变动定期(或异步)更新内核驱动。第二，内核驱动程序附加必要数据头(基于RTSP服务器提供的信息)，通过直接输入网络驱动程序(例如udp_send)立即转发数据包，从而无需在内核和用户空间之间进行内存拷贝。

　　图3 显示了基于H.264 IP的完整编/解码系统，总时延不足50毫秒。该系统是根据Zynq SoC、A2e Technologies低时延H.264编/解码器与A2e Technologies 低时延RTSP服务器/客户端而建立的。需要注意的是，从硬件角度来看，编码与解码系统之间唯一真正的区别在于，编码侧必须连接到摄像头/传感器，而解码侧则必须能够为平板显示提供驱动。您可以轻松地设计一个具备编码与解码所需的所有必备硬件功能的电路板。

　　为尽量减少实时控制应用中视频压缩/解压缩的时延，设计人员需要特殊编码器和优化的软件。利用赛灵思的Zynq SoC和 A2e Technologies的H.264低时延编码器与以及优化的RTSP 服务器/客户端，可在小型PCB板上创建一个时延极低、高度可配置的系统。