具有GPU处理功能的低延迟软件，适用于相机应用

在许多图像处理应用中，我们不仅需要处理相机图像，还需要执行快速计算并提供即时反馈。 这就是低延迟解决方案对特定项目发挥作用的地方。 为了解决这个问题，我们实现了低延迟快速VCR相机应用程序，它将相机延迟降低到非常低的值。

低延迟应用程序

• 遥控机器人
• 视网膜手术和视频内窥镜
• 无人机和联网自动驾驶汽车
• 广播及流媒体

影响相机应用程序延迟的主要问题

• 相机（图像传感器）帧速率，位深度，图像分辨率。 位深度和分辨率越高，帧速率越低，因为相机带宽有限。 较低的帧速率意味着帧之间有更多的时间，这会影响延迟.
• 相机操作模式。 标准模式被称为"连续",它意味着我们一帧一帧地获取图像. 相机"突发模式"用于从相机接收帧的批次. 这适用于高速应用程序，但对于低延迟情况并不好。 对于低延迟解决方案，我们需要从相机获取每个帧。 突发模式不行.
• 相机输出接口。 每个机器视觉相机接口（MIPI CSI2，MSI，USB3，Camera Link，10-GigE，Coax，PCIe）都有自己的最大吞吐量。 为了获得更好的延迟，请使用传输数据所需时间更短的高速接口.
• 时间进行图像处理。 为了实现低延迟，我们需要最快的图像处理软件。 我们在NVIDIA GPUs上提供非常快的ISP，这是由于并行图像处理算法的实现和他们的低级优化而成为可能的。 为了更好的延迟，实现最简单的管道也是有意义的。 通常，NVIDIA Quadro或GeForce上的ISP性能比Jetson更好，因此更好的性能意味着更好的延迟.
• 批量图像处理vs低延迟响应。 与使用并行算法处理单独帧相比，批处理图像处理可以更快地完成，但它不适用于低延迟应用程序。 所以我们需要分别捕获和处理每一帧.
• 输出图像的压缩比。 为了减少数据传输的时间，我们需要应用图像或视频编码。 它可能是中等像10-15倍的JPEG或强（100-200倍的H.264/H.265），但在任何情况下，如果我们想获得更好的延迟，我们不应该传输未压缩的图像。 我们还必须考虑每种编码算法的处理时间，从这个角度来看，JPEG压缩可能比H.264/H.265更好.
• 流协议。 在发送图像时，我们应该使用UDP，而不是TCP。 值得使用自定义RTSP。 请记住，标准RTSP不适用于低延迟任务.
• 网络带宽。 这是另一个外部限制，建议您使用带宽大于相机输出数据速率的网络.
• 流距离。 我们需要更多时间通过同一网络将相同数量的数据发送到更远的距离，因此这一点也很重要.
• 监控帧速率。 如果监视器是我们解决方案的一部分，它自己的延迟可能会对整体延迟产生影响。 为了获得最佳效果，我们建议使用144fps甚至高达360fps的高fps显示器.
• PC性能。 请选择快速CPU，内存，GPU，SSD，GigE等。 PC应该拥有所有必要的资源来尽快执行计算。 操作系统的延迟也很重要.
• 软件的编程语言应该是C++/CUDA/OpenCL，以便尽可能快地进行计算。 软件应该优化和加速.
• 在GPU上，使用共享内存和寄存器进行低级优化是一个好主意。 I/O的固定内存也是必须的.
• I/O操作、主机到设备以及设备到主机的数据传输可能会破坏延迟。 I/O应该并行完成。 例如，从相机获取图像和输出图像都应该与图像处理管道分开。 异步操作也很重要.
• 最好限制线程数以避免线程同步.
• 延迟测量/估计的方法。 广泛使用的g2g（玻璃到玻璃）延迟估计方法并不理想，我们应该考虑到这一点。 这不是一个具有非常高的精度和可靠性的方法，我们认为Q2的结果是近似的.

GPU上的完整图像处理管道

• 图像采集
• 10位和12位模式的帧解包
• 图像线性化
• 暗帧减法(FPN)
• 平场校正（阴影校正）
• 坏像素去除
• 白平衡/AWB
• 自适应曝光和增益控制
• MG算法的高质量演示
• 使用矩阵配置文件或DCP配置文件进行色彩校正
• 突出恢复
• 曝光校正（亮度控制）
• Denoiser:双边,NLM
• 曲线和水平
• 旋转到90/180/270度和触发器
• 作物/作物
• 调整大小（缩小和高档）
• 旋转到任意角度
• 通过LCP或通过校准的地图进行反失真
• 锐化（局部对比度）
• 伽玛变换
• SSD上的JPEG压缩和存储
• 可选转换为NV12和H264/h265/av1编码
• 自动实时分割AVI/MP4视频文件到指定的文件大小
• 用于低延迟视频流和广播的内置RTSP服务器
• 实时输出监控

FastVCR软件输出

• 通过OpenGL实时监控视频输出
• 摄影机统计数字
• 柱状图，游行，矢量图
• SSD上的图像存储实时处理和JPEG压缩
• 视频编码到MJPEG(AVI)、H.264/H.265/AV1(MP4)和存储到SSD上的视频容器
• 通过RTSP实现低延迟视频流（包括播放器和服务器）
• 用于延迟评估的玻璃到玻璃模块
• RTSP流与VLC和快速VCR视频播放器兼容
• 在GPU级别与基于GPU的AI库和应用程序的互操作性

FastVCR 延迟基准

对于延迟评估，我们使用标准的玻璃到玻璃（G2T或GTG）方法。 为了检查系统延迟，我们实施了一个软件模块来执行G2G测试。 以下选项可用于G2G测试:

• 相机从监视器上的高分辨率计时器捕获当前时间的图像，然后我们将数据从相机发送到软件，继续GPU上的图像处理，然后用计时器在窗口附近的同一监视器上显示处理后的图像。 当我们停止软件时，我们看到两个不同的时间，它们的区别是系统延迟.
• 我们还实现了一个更复杂的解决方案：在GPU上进行图像处理后，我们可以应用JPEG编码（GPU上的MJPEG），然后将MJPEG流发送到receiver进程，在那里我们进行MJPEG解析和解码，然 两个进程（发送方和接收方）在同一台PC上运行.
• 与以前的方法相同的解决方案，但使用H.264/H.265编码/解码（CPU或GPU），两个进程都在同一台PC上.

我们还可以测量通过网络将压缩数据从一台PC流式传输到另一台PC时的延迟。 延迟取决于相机帧速率、显示器fps、NVIDIA GPU性能、网络带宽、图像处理管道的复杂性等。 我们认为G2G延迟结果是近似的，因为它们依赖于相机/监视器帧速率等.

为了进行测试，我们在120fps和144fps显示器上运行了XIMEA USB3 3-MPix8位彩色相机。 估计G2G延迟约为35-40ms。 使用更快的相机和具有更高fps的显示器可能会更好，并且使用PCIe相机而不是USB3是一个好主意。 您可以使用XIMEA相机在PC上运行该软件，以评估系统的延迟.

FastVCR CLI 申请表格

通常我们需要在没有GUI的情况下运行软件，这可能发生在各种情况下。 对于远程控制的机器人应用程序或涉及远程摄像机控制的任何其他任务，情况都是如此。 任何长期无人看管的视频录制和流媒体也是如此.

为了满足这些要求，我们开发了一个CLI应用程序，它具有FastVCR软件的所有上述功能，并且可以在没有GUI的情况下工作。 我们仍然能够完全控制图像传感器和图像处理参数的实时。 对于视频预览，我们提供我们自己的播放器与RTSP客户端，或者您可以使用VLC代替。 该软件兼容Windows/Linux/L4T，所有图像处理都在GPU上完成.

兼容性

• CUDA-12.6 for Windows/Linux, NVIDIA GeForce, Quadro
• CUDA-12.6 for NVIDIA Jetson NX, Xavier, Orin
• XIMEA USB3 and PCIe cameras

软件下载

• FastVCR XIMEA相机软件 在Windows-10/11和CUDA-12.6上运行。 该软件还可以使用SSD的PGM/RAW/TIFF帧.