xilinx低延时视频编解码方案_zcu低延时无法拉流

        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》