标题:
用Zynq SoC 设计低时延H.264系统-2
[打印本页]
作者:
look_w
时间:
2018-3-18 18:36
标题:
用Zynq SoC 设计低时延H.264系统-2
一种典型的流式视频系统采用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板上创建一个时延极低、高度可配置的系统。
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0
