xilinx低延时视频编解码方案

xilinx的Zynq® UltraScale+™ MPSoCs EV系列：

它有一个视频编解码硬核VCU，能实现多种profile/level的H264/H265编解码能力，最高支持一路3840x2160@60或4096x2160@60（需要-2和-3等级的芯片） yuv422的分辨率，支持yuv422 10 bit HDR等，具体参考《PG252》文档。

总共支持4种不同延时的编解码能力：

VCU的软件框架使用了Gstreamer跨平台多媒体处理框架，可以使用gst-launch-1.0等工具进行测试：

我们使用ZCU106开发板进行测试：

1，显示测试图：

modetest -D a0070000.v_mix -s 38:3840x2160-60@BG24
gst-launch-1.0 videotestsrc pattern=ball ! fpsdisplaysink name=fpssink text-overlay=false video-sink="kmssink bus-id=a0070000.v_mix" sync=true -v

2，解码ffmpeg编码出来的h.264文件：

modetest -D a0070000.v_mix -s 38:1920x1080-60@BG24
gst-launch-1.0 filesrc location="1080p.h264" ! h264parse ! video/x-h264, latency-mode=false ! omxh264dec low-latency=0 ! video/x-raw ! queue max-size-bytes=0 ! fpsdisplaysink name=fpssink text-overlay=false video-sink="kmssink bus-id=a0070000.v_mix" sync=true -v

3，测试由zynq采集HDMI输入的视频后编码出h264给ffmpeg解码显示：

vcu_gst_app /media/card/config/1-1080p60/Stream-out/Single_1080p60_AVC_25_Mbps.cfg
gst-launch-1.0 -v v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1 ! omxh264enc num-slices=1 periodicity-idr=60 cpb-size=500 prefetch-buffer=true target-bitrate=25000 gop-mode=basic ! video/x-h264,latency-mode=false,profile=baseline ! filesink location=input.h264

4，Xilinx Low-Latency超低延时测试，使用两块ZCU106板卡，从HDMI采集，经过H265编码后打包成rtp协议，使用udp下发给到解码板，解码板收到rtp码流后解析出H265后解码，并从HDMI口显示：

采集端
ifconfig eth0 192.168.25.90 netmask 255.255.255.0
vcu_gst_app /media/card/config/1-1080p60/Stream-out/Single_1080p60_AVC_25_Mbps.cfg
gst-launch-1.0 -v v4l2src device=/dev/video0 io-mode=4 ! video/x-raw\(memory:XLNXLL\), format=NV12, width=1920, height=1080, framerate=60/1 ! omxh265enc num-slices=8 periodicity-idr=240 cpb-size=500 gdr-mode=horizontal initial-delay=250 control-rate=low-latency prefetch-buffer=true target-bitrate=25000 gop-mode=low-delay-p ! video/x-h265, alignment=nal ! rtph265pay ! udpsink buffer-size=60000000 host=192.168.25.89 port=5004 async=false max-lateness=-1 qos-dscp=60 max-bitrate=120000000 -v显示端
ifconfig eth0 192.168.25.89 netmask 255.255.255.0
modetest -D a0070000.v_mix -s 38:1920x1080-60@BG24
gst-launch-1.0 udpsrc port=5004 buffer-size=60000000 caps="application/x-rtp, media=video, clock-rate=90000, payload=96, encoding-name=H265" ! rtpjitterbuffer latency=7 ! rtph265depay ! h265parse ! video/x-h265, alignment=nal ! omxh265dec low-latency=1 ! video/x-raw\(memory:XLNXLL\) ! queue max-size-bytes=0 ! fpsdisplaysink name=fpssink text-overlay=false video-sink="kmssink bus-id=a0070000.v_mix" sync=true -v

5，Normal Latency普通延时测试，使用H264

采集端：
ifconfig eth0 192.168.25.90 netmask 255.255.255.0
vcu_gst_app /media/card/config/1-1080p60/Stream-out/Single_1080p60_AVC_25_Mbps.cfg
gst-launch-1.0 -v v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1 ! omxh264enc num-slices=1 periodicity-idr=60 cpb-size=500 prefetch-buffer=true target-bitrate=25000 gop-mode=basic ! video/x-h264,latency-mode=false ! rtph264pay ! udpsink buffer-size=60000000 host=192.168.25.89 port=5004 async=false max-lateness=-1 qos-dscp=60 max-bitrate=120000000 -v显示端：
ifconfig eth0 192.168.25.89 netmask 255.255.255.0
modetest -D a0070000.v_mix -s 38:1920x1080-60@BG24
gst-launch-1.0 udpsrc port=5004 buffer-size=60000000 caps="application/x-rtp, media=video, clock-rate=90000, payload=96, encoding-name=H264" ! rtpjitterbuffer latency=1000 ! rtph264depay ! h264parse ! video/x-h264, latency-mode=false ! omxh264dec low-latency=0 ! video/x-raw ! queue max-size-bytes=0 ! fpsdisplaysink name=fpssink text-overlay=false video-sink="kmssink bus-id=a0070000.v_mix" sync=true -v

优点：

1，端对端延时很低，4K@60的H265编解码达到2帧延时。

2，支持yuv422和10bit编解码，而业界很多都只能做到yuv420和8bit，图像质量相对它们好一点。

缺点：

1.芯片不便宜

2.开发繁杂，需要查阅比较多Gstreamer的资料，产品业务复杂的或许还要修改它的gst-omx硬编、硬解插件（如vcu-ctrl-sw和vcu-omx-il库）。

3，调试复杂，经过的层数太多，很难排查问题。从最底层的VCU硬核到FPGA封装的IP核暴露出来的AXI系列总线操作，再到控制AXI总线的MCU闭源固件，还没完，紧跟着到linux驱动层(al5e.ko/al5d.ko等)，再到用户态vcu-ctrl-sw库，.......，最后是顶层的Gstreamer多媒体框架。层次这么多，如果出问题，排查问题的难度可想而知（官方github（gst-omx、gst-plugins-base、gst-plugins-good、gst-plugins-bad等等）很久没更新了），求神拜佛不要在底层出问题吧！

4，稳定性有风险，不像海思的编解码SOC经过多年的市场检验，极其稳定，而xilinx的vcu没有经过长期验证。

5，VCU只有H264/H265编解码功能(VENC/VDEC)，没有缩放、裁剪、去噪等等这些常用的视频处理功能（VPSS），也不包含显示功能(VO)，显示是使用linux的DRM显示框架（利用dma-buf使得解码器与显卡共享物理内存，不同模块间不需要多次DMA拷贝），最后渲染到HDMI_TX输出显示图像，所以VPSS是需要FPGA（PL端）自行实现，鸡肋啊！！

6，在xilinx Low Latency模式下，编码端有硬件的syncIP核实现buffer读写同步，该syncIP核经过软件封装后，会类似于“锁”或者“互斥量”的接口被app调用，但是解码端则需要使用软件自行实现同步，否则会出现不同步现象，譬如当解码器正在写buffer时，显示模块去读buffer就会花屏，增加软件实现负担。

总的来说，这个方案差强人意，单就编解码方面确实有过人之处，采用分片处理，但整体缺点较多，对没有FPGA开发或复杂软件开发经验的公司来说开发难度较大，用的人还不是很多，除非就盯着低延时不放。

参考资料：

Zynq UltraScale+ MPSoC VCU TRD 2020.1 - Xilinx Low Latency PS DDR NV12 HDMI Audio Video Capture and Display - Xilinx Wiki - Confluence

《ug1085-zynq-ultrascale-trm.pdf》

《ug1250-zcu106-vcu-trd.pdf》

《pg252-vcu.pdf》

《ug1144-petalinux-tools-reference-guide.pdf》

xilinx低延时视频编解码方案相关推荐

视频编解码硬件方案漫谈
视频编解码硬件方案最早是在嵌入式领域中广泛存在,如采用DSP,FPGA,ASIC等,用来弥补嵌入式系统CPU等资源能力不足问题,但随着视频分辨率越来越高(从CIF经历720P,1080P发展到4K,8 ...
音视频编解码技术之视频编码基本概念介绍
视频压缩名字解释: 1.有损和无损压缩:在视频压缩中有损(Lossy )和无损(Lossless)的概念与静态图像中基本类似.无损压缩也即压缩前和解压缩后的数据完全一致.有损压缩意味着解压缩后的数据与 ...
流媒体传输协议及音视频编解码技术
说明:本文来自一篇出处不明的老文章,有些内容已过时,但仍有很大的参考价值. 一.音视频编解码技术 1.MPEG4 MPEG全称是Moving Pictures Experts Group,它是&quo ...
视频监控与视频编解码技术
视频监控与视频编解码技术参考文献链接 https://mp.weixin.qq.com/s/UW4Z0vu_Wypc0ddymrOkpg https://mp.weixin.qq.com/s/Rfs ...
音视频编解码类开源项目的18个实时
实时音视频的开发学习有很多可以参考的开源项目. 一个实时音视频应用共包括几个环节:采集.编码.前后处理.传输.解码.缓冲.渲染等很多环节.每一个细分环节,还有更细分的技术模块.比如,前后处理环节有美颜 ...
视频编解码之理论概述和即时通信
前言即时通讯应用中的实时音视频技术,几乎是IM开发中的最后一道高墙.原因在于:实时音视频技术 = 音视频处理技术 + 网络传输技术的横向技术应用集合体,而公共互联网不是为了实时通信设计的.有关实时 ...
实时通信RTC技术栈之：视频编解码
1.前言 RTC(Real-time Communications),实时通信,是一个正在兴起的风口行业,经过短短一年的时间,已经有很多玩家进入了这个行业,最典型的应用就是直播连麦和实时音视频通信.但 ...
【视频编解码性能优化与实现】
点击上方"LiveVideoStack"关注我们 " "音视频+无限可能" 是一扇LiveVideoStackCon面向新兴领域开启的大门,在移动互联 ...
【视频编解码的新挑战与新机会】
在过去的一年中,我们可以看到多媒体特别是音视频技术的能力在严峻的挑战下,为各行各业带来了巨大的变化.疫情过后,又会有哪些多媒体新技术.新实践呈现在大众的视野当中?为行业的发展与应用带来哪些新的趋势与机 ...
视频编解码优化以及与AI的实践结合
RealNetworks是流媒体类别的发明者,改变了音频和视频内容在各种设备和全世界消费的方式.在编解码市场的大环境下,RealNetworks推出了新一代的视频压缩算法RMHD,专为下一代的高清流媒 ...

xilinx低延时视频编解码方案

xilinx低延时视频编解码方案相关推荐

最新文章

热门文章