视频管道延迟工具 - NVIDIA 文档

NVIDIA 开发者套件作为高性能计算平台表现出色，它结合了高带宽视频 I/O 组件和 NVIDIA GPU 的计算能力，以满足最苛刻的视频处理和推理应用的需求。

对于位于边缘的许多视频处理应用（尤其是那些旨在增强医疗器械和辅助实时医疗程序的应用），最大限度地减少图像捕获和显示之间增加的延迟（通常称为端到端延迟）至关重要。

虽然通常很容易通过简单地测量单个帧（或帧序列）的处理时间来测量隔离的计算或推理算法的各个处理时间，但当视频捕获和显示被纳入时，测量完整的端到端延迟并不总是那么容易，因为这通常涉及外部捕获硬件（例如，摄像头和其他传感器）和显示器。

为了建立使用 NVIDIA 开发者套件以及各种视频 I/O 硬件和软件组件可以实现的最小端到端延迟的基准测量，Holoscan SDK 包含一个示例延迟测量工具。

要求

硬件

延迟测量工具需要使用 dGPU 模式下的 NVIDIA 开发者套件，并通过让输出组件生成一系列已知的视频帧，然后使用物理环回电缆将其传输回输入组件来操作。

测试从 GPU 输出的任何 HDMI 模式的延迟需要 DisplayPort 转 HDMI 适配器或电缆（请参阅下面的示例配置）。请注意，此电缆必须支持正在测试的模式；例如，只有当电缆被宣传为支持“4K 超高清 (3840 x 2160) @ 60 Hz”时，UHD 模式才可用。

测试可选的 AJA Video Systems 设备的延迟需要支持的 AJA SDI 或 HDMI 采集设备（有关支持的设备列表，请参阅AJA Video Systems），以及测试配置所需的 HDMI 或 SDI 电缆（请参阅下面的示例配置）。

软件

以下附加软件组件是必需的，并且通过 Holoscan SDK 安装或在下面的安装步骤中安装

CUDA 11.1 或更高版本 (https://developer.nvidia.com/cuda-toolkit)
CMake 3.10 或更高版本 (https://cmake.com.cn/)
GLFW 3.2 或更高版本 (https://www.glfw.org/)
GStreamer 1.14 或更高版本 (https://gstreamer.freedesktop.org/)
GTK 3.22 或更高版本 (https://gtk.org.cn/)
pkg-config 0.29 或更高版本 (https://www.freedesktop.org/wiki/Software/pkg-config/)

以下是启用 DeepStream 支持（用于来自 GStreamer Producer 的 RDMA 支持）的可选项

DeepStream 5.1 或更高版本 (https://developer.nvidia.com/deepstream-sdk)

以下是启用 AJA Video Systems 支持的可选项

AJA NTV2 SDK 16.1 或更高版本（有关安装 AJA NTV2 SDK 和驱动程序的详细信息，请参阅AJA Video Systems）。

安装

下载源代码

视频管道延迟工具可以在 Holoscan Performance Tools GitHub 存储库的 loopback-latency 文件夹中找到，该存储库通过以下方式克隆

复制
已复制！

            
            $ git clone https://github.com/nvidia-holoscan/holoscan-perf-tools.git

安装软件要求

CUDA 在 dGPU 设置期间自动安装。其余软件要求通过以下方式安装

复制
已复制！

            
            $ sudo apt-get update && sudo apt-get install -y \
    cmake \
    libglfw3-dev \
    libgstreamer1.0-dev \
    libgstreamer-plugins-base1.0-dev \
    libgtk-3-dev \
    pkg-config

构建

首先在 loopback-latency 目录中创建一个 build 文件夹

复制
已复制！

            
            $ cd clara-holoscan-perf-tools/loopback-latency
$ mkdir build
$ cd build

然后使用 CMake 构建该工具，并将 loopback-latency 二进制文件输出到当前目录

复制
已复制！

            
            $ cmake ..
$ make -j

注意

如果遇到错误 No CMAKE_CUDA_COMPILER could be found，请确保可以通过将 CUDA 运行时位置添加到您的 PATH 变量来找到 nvcc 可执行文件。

复制
已复制！

            
            $ export PATH=$PATH:/usr/local/cuda/bin

启用 DeepStream 支持

当使用 GStreamer Producer 时，DeepStream 支持启用 RDMA。要启用 DeepStream 支持，必须将 DEEPSTREAM_SDK 路径附加到 cmake 命令，并提供 DeepStream SDK 的位置。例如，当针对 DeepStream 5.1 构建时，将上面的 cmake 命令替换为以下命令

复制
已复制！

            
            $ cmake -DDEEPSTREAM_SDK=/opt/nvidia/deepstream/deepstream-5.1 ..

启用 AJA 支持

要启用 AJA 支持，必须将 NTV2_SDK 路径附加到 cmake 命令，并提供 NTV2 SDK 的位置，其中包含头文件和编译后的库（即 libajantv2）。例如，如果 NTV2 SDK 位于 /home/nvidia/ntv2 中，则将上面的 cmake 命令替换为以下命令

复制
已复制！

            
            $ cmake -DNTV2_SDK=/home/nvidia/ntv2 ..

示例配置

注意

当测试从 GPU 输出的配置时，该工具目前仅支持无显示器环境，其中环回电缆是唯一连接到 GPU 的电缆。因此，任何从 GPU 输出的测试都必须使用来自另一台机器的远程连接（如 SSH）执行。在这种情况下，请确保 DISPLAY 环境变量设置为您正在使用的 X11 显示器的 ID（例如，在 ~/.bashrc 中）

复制
已复制！

            
            export DISPLAY=:0

还要求系统已登录到桌面，并且在使用延迟工具时系统不会睡眠或锁定。这可以通过临时将显示器连接到系统来完成以下操作

打开 Ubuntu 系统设置
打开用户帐户，单击右上角的解锁，然后启用自动登录
返回所有设置（左上角），打开亮度与锁定，并禁用睡眠和锁定，如图所示

在进行这些更改后，请确保再次断开显示器的连接。

有关基于 GPU 的生产者（即 OpenGL 和 GStreamer）的更多详细信息，请参阅生产者部分。

GPU 到板载 HDMI 采集卡

在此配置中，DisplayPort 转 HDMI 电缆从 GPU 连接到板载 HDMI 采集卡。此配置支持 OpenGL 和 GStreamer 生产者，以及 V4L2 和 GStreamer 消费者。

图 25 GPU 和板载 HDMI 采集卡之间的 DP 转 HDMI 电缆

例如，可以使用此配置和以下命令来测量 OpenGL 生产者到 V4L2 消费者

$ ./loopback-latency -p gl -c v4l2

GPU 到 AJA HDMI 采集卡

在此配置中，DisplayPort 转 HDMI 电缆从 GPU 连接到 AJA 采集卡上的 HDMI 输入通道。此配置支持 OpenGL 和 GStreamer 生产者，以及使用 AJA HDMI 采集卡的 AJA 消费者。

图 26 GPU 和 AJA KONA HDMI 采集卡（通道 1）之间的 DP 转 HDMI 电缆

例如，可以使用此配置和以下命令来测量 OpenGL 生产者到 AJA 消费者

$ ./loopback-latency -p gl -c aja -c.device 0 -c.channel 1

AJA SDI 到 AJA SDI

在此配置中，SDI 电缆连接在同一设备上的两个通道之间，或两个单独的设备之间（图中显示的是单个设备的两个通道之间的环回）。此配置必须使用 AJA 生产者和 AJA 消费者。

图 27 单个 AJA Corvid 44 采集卡的通道 1 和 2 之间的 SDI 电缆

例如，以下命令可用于测量如图所示的配置，该配置使用单个设备，通道 1 和 2 之间进行环回。请注意，该工具默认使用通道 1 作为生产者，通道 2 作为消费者，因此可以省略 channel 参数。

$ ./loopback-latency -p aja -c aja

如果连接了两个 AJA 设备，则可以使用以下命令来测量配置，其中它们都连接到通道 1

$ ./loopback-latency -p aja -p.device 0 -p.channel 1 -c aja -c.device 1 -c.channel 1

操作概述

延迟测量工具通过让生产者组件生成一系列已知的视频帧来操作，这些帧被输出，然后使用物理环回电缆传输回输入消费者组件。在帧的整个生命周期中比较时间戳，以测量帧在此过程中看到的总体延迟，并在收到所有帧且测量完成时总结这些结果。有关更多详细信息，请参阅生产者、消费者和示例配置。

帧测量

该工具生成的每个帧都按顺序执行以下步骤，每个步骤都有其测量的时间，并在所有帧完成后报告。

图 28 延迟工具帧生命周期（禁用 RDMA）

CUDA 处理

为了模拟真实世界的 GPU 工作负载，该工具首先运行 CUDA 内核，循环用户指定的次数（默认为零）。下面在模拟 GPU 工作负载中对此步骤进行了描述。
在 GPU 上渲染

在可选地模拟 GPU 工作负载之后，每个生产者都使用 GPU 生成其帧，可以通过通用的 CUDA 内核或生产者 API 可用的另一种方法（例如 OpenGL 生产者）。

预计此步骤非常快（<100us），但如果总体系统负载较高，则可能会看到更高的耗时。
复制到主机

一旦在 GPU 上生成帧，可能需要将帧复制到主机内存，以便生产者组件可以输出帧（例如，禁用 RDMA 的 AJA 生产者）。

如果不需要主机复制（即，为生产者启用 RDMA），则此时间应为零。
写入硬件

某些生产者组件需要在输出帧之前将帧复制到外围内存（例如，AJA 生产者需要将帧复制到 AJA 设备上的外部帧存储）。如果为生产者禁用 RDMA，则此复制可能源自主机内存；如果启用 RDMA，则此复制可能源自 GPU 内存。

如果不需要此复制（例如，生产者直接从 GPU 输出），则此时间应为零。
VSync 等待

一旦帧准备好输出，生产者硬件必须等待下一个 VSync 间隔，然后才能输出帧。

预计此 VSync 等待和所有先前步骤的总和接近帧间隔的倍数。例如，如果帧速率为 60Hz，则步骤 1 到 5 的时间总和应接近 16666us 的倍数。
线路时间

线路时间是帧通过物理环回电缆传输所需的时间量。这应该接近单个帧间隔的时间。
从硬件读取

一旦帧通过线路传输并且可供消费者使用，某些消费者组件需要将帧从外围内存复制到主机（禁用 RDMA）或 GPU（启用 RDMA）内存中。例如，AJA 消费者需要将帧从 AJA 设备的外部帧存储复制出来。

如果不需要此复制（例如，消费者组件将接收到的帧直接写入主机/GPU 内存），则此时间应为零。
复制到 GPU

如果消费者将帧接收到主机内存中，则使用 GPU 处理帧所需的最后一步是将帧复制到 GPU 内存中。

如果为消费者启用 RDMA 并且帧先前已直接写入 GPU 内存，则此时间应为零。

请注意，如果在生产者和消费者端都启用了 RDMA，则上面的 GPU/主机复制步骤（分别为 3 和 8）实际上将被删除，因为 RDMA 将在视频硬件和 GPU 之间直接复制。以下显示了与上面相同的图表，但生产者和消费者都启用了 RDMA。

图 29 延迟工具帧生命周期（启用 RDMA）

解释结果

以下显示了当测试从 AJA 生产者到 AJA 消费者的 4K @ 60Hz 流（禁用 RDMA，且无 GPU/CUDA 工作负载模拟）时，该工具的上述测量的示例输出。请注意，所有时间值均以微秒为单位给出。

$ ./loopback-latency -p aja -p.rdma 0 -c aja -c.rdma 0 -f 4k

虽然此工具先测量生产者时间，然后测量消费者时间，但真实世界视频处理应用的预期顺序是相反的。也就是说，真实世界应用的预期顺序是它会按以下顺序捕获、处理和输出帧（括号中给出了负责测量该时间的组件）

从硬件读取（消费者）
复制到 GPU（消费者）
处理帧（生产者）
将结果渲染到 GPU（生产者）
复制到主机（生产者）
写入硬件（生产者）

图 30 真实应用帧生命周期

为了说明这一点，该工具对生产者和消费者的总时间求和并显示，然后提供估计应用时间，作为所有这些步骤（即，上述步骤 1 到 6）的总和。

（续上）

一旦真实世界的应用程序捕获、处理和输出帧，最终输出仍然需要等待下一个 VSync 间隔，然后才能实际通过物理线路发送到显示硬件。基于此假设，该工具然后通过执行以下操作来估计最终估计延迟的最终值

取估计应用时间（来自上面）
将其向上舍入到下一个 VSync 间隔
添加物理线路时间（即，帧间隔）

图 31 带有 VSync 和物理线路时间的最终估计延迟

继续使用帧间隔为 16666us (60Hz) 的示例，这意味着平均最终估计延迟由以下因素确定

平均应用时间 = 26772
向上舍入到下一个 VSync 间隔 = 33332
添加物理线路时间 (+16666) = 49998

这些时间也报告为帧间隔的倍数。

（续上）

使用此示例，我们应该期望使用这些组件和配置运行此管道所看到的总端到端延迟为 3 个帧间隔 (49998us)。

前面的示例对 4K @ 60Hz 流使用了 AJA 生产者和消费者；但是，RDMA 对这两个组件都已禁用。因此，GPU 和主机内存之间的额外复制为管道增加了超过 10000us 的延迟，导致应用程序超出每个帧一个帧间隔的处理时间，因此总帧延迟为 3 帧。如果启用 RDMA，则可以避免这些 GPU 和主机复制，从而将处理延迟减少 10000us 以上。然而，更重要的是，这也使得总处理时间可以适应单个帧间隔，从而可以将总端到端延迟减少到仅 2 帧。

图 32 使用 RDMA 减少延迟

以下显示了启用 RDMA 后重复的上述示例。

$ ./loopback-latency -p aja -p.rdma 1 -c aja -c.rdma 1 -f 4k

模拟 GPU 工作负载

默认情况下，该工具测量的是本质上的直通视频管道；也就是说，系统不对视频帧执行任何处理。虽然这对于测量视频输入和输出组件可以实现的最小延迟很有用，但这并不能很好地指示真实世界的使用案例，在真实世界的使用案例中，GPU 用于对输入和输出之间的视频帧执行计算密集型处理操作（例如，将叠加层应用于输出帧的对象检测算法）。

虽然测量将应用于视频帧的处理算法的运行时延迟可能相对简单——只需测量在单个帧或帧流上运行算法的运行时——但这可能无法指示此类处理可能对总体系统负载产生的影响，这可能会进一步增加视频输入和输出组件的延迟。

为了估计在向系统添加额外 GPU 工作负载时的总延迟，延迟工具具有 -s {count} 选项，该选项可用于在生产者实际生成帧之前运行任意 CUDA 循环指定的次数。此选项的预期用法如下

实际 GPU 处理算法的每帧运行时在延迟测量工具外部测量。
延迟工具仅使用 -s {count} 选项重复运行，调整 {count} 参数，直到运行模拟循环所需的时间大致与上一步中测量的实际处理时间相匹配。

$ ./loopback-latency -s 2000
延迟工具与用于视频 I/O 的完整生产者 (-p) 和消费者 (-c) 选项以及 -s {count} 选项一起运行，使用在上一步中确定的循环计数。

注意

以下示例显示，消费者接收到的大约一半帧是重复/重复帧。这是因为生产者的额外处理延迟导致其超过单个帧间隔，因此生产者只能每隔一个帧间隔输出一个新帧。

$ ./loopback-latency -p aja -c aja -s 2000

提示

为了获得真实世界应用程序所看到的延迟的最准确估计，最好的方法是在延迟测量期间运行应用程序使用的实际帧处理算法。这可以通过修改延迟工具源代码中的 SimulateProcessing 函数来完成。

结果图表

延迟工具包含一个 -o {file} 选项，该选项可用于输出 CSV 文件，其中包含每个帧的所有测量时间。然后可以将此文件与该工具随附的 graph_results.py 脚本一起使用，以生成测量的图表。

例如，如果使用以下命令测量延迟

$ ./loopback-latency -p aja -c aja -o latencies.csv

然后可以使用以下命令生成图表，这将打开桌面上的窗口以显示图表

$ ./graph_results.py --file latencies.csv

通过向脚本提供 --png {file} 选项，图表也可以输出到 PNG 图像文件，而不是在桌面上打开窗口。以下显示了禁用 RDMA 的 4K @ 60Hz 流的 AJA 到 AJA 测量的示例图表（如上面的解释结果中的示例所示）。

请注意，这显示了从左到右 600 帧的时间，每个帧的生命周期从底部开始，到顶部结束。虚线黑线表示帧 VSync 间隔（每 16666us）。

上面的示例直接绘制了工具测量的时间图。为了改为为解释结果中上述的最终估计延迟生成图表，可以将 --estimate 标志提供给脚本。正如延迟工具在报告估计延迟时所做的那样，这会重新排序生产者和消费者步骤，然后添加 VSync 间隔，然后是物理线路延迟。

以下图表使用与上图相同的数据文件绘制了最终估计延迟。请注意，这显示了总共 3 帧的预期延迟。

为了进行比较，以下图表显示了相同的测试，但启用了 RDMA。请注意，由于使用了 RDMA，复制到 GPU 和 复制到 SYS 时间现在为零，并且现在仅显示 2 帧的预期延迟。

作为最后一个示例，以下图表复制了上面启用了 RDMA 的测试，但向管道添加了大约 34 毫秒的额外 GPU 处理时间 (-s 1000)，以产生 4 帧的最终估计延迟。

生产者

Holoscan 延迟工具目前支持 3 种生产者类型。有关每个受支持生产者的描述，请参阅以下部分。

OpenGL GPU 直接渲染 (HDMI)

此生产者 (gl) 使用 OpenGL 在 GPU 上直接渲染帧，以便通过 GPU 上的 HDMI 连接器输出。目前，这预计是 GPU 视频输出的最低延迟路径。

OpenGL 生产者注意事项

此生产者生成的视频以全屏方式渲染到主显示器。截至此版本，此组件仅在无显示器环境中进行了测试，在该环境中，环回 HDMI 电缆是唯一连接到 GPU 的电缆（因此是主显示器）。可能还需要使用 xrandr 工具配置 HDMI 输出；如果需要，该工具将提供所需的 xrandr 命令。
由于 OpenGL 直接渲染到 GPU，因此不支持 p.rdma 标志，并且 RDMA 始终被认为为此生产者启用。

GStreamer GPU 渲染 (HDMI)

此生产者 (gst) 使用 Holopack 附带的 nveglglessink GStreamer 组件来渲染源自 GStreamer 管道的帧到 GPU 上的 HDMI 连接器。

GStreamer 生产者注意事项

必须使用 DeepStream 支持构建该工具，此生产者才能支持 RDMA（有关详细信息，请参阅启用 DeepStream 支持）。
此生产者生成的视频以全屏方式渲染到主显示器。截至此版本，此组件仅在无显示器环境中进行了测试，在该环境中，环回 HDMI 电缆是唯一连接到 GPU 的电缆（因此是主显示器）。可能还需要使用 xrandr 工具配置 HDMI 输出；如果需要，该工具将提供所需的 xrandr 命令。
由于生成的帧的输出由 nveglglessink 插件在内部处理，因此帧从 GPU 输出的时间是未知的。因此，此生产者报告的线路时间包括帧在传递到 nveglglessink 和最终被消费者接收之间花费的所有时间。

AJA Video Systems (SDI)

此生产者 (aja) 从支持视频播放的 AJA Video Systems 设备输出视频帧。

AJA 生产者注意事项

必须使用 AJA Video Systems 支持构建延迟工具，此生产者才能可用（有关详细信息，请参阅构建）。
以下参数可用于配置用于输出帧的 AJA 设备和通道

-p.device {index}

整数，指定设备索引（即 0 或 1）。默认为 0。

-p.channel {channel}

整数，指定通道号，从 1 开始（即 1 指定 NTV2_CHANNEL_1）。默认为 1。
p.rdma 标志可用于启用 (1) 或禁用 (0) 将 RDMA 与生产者一起使用。如果要使用 RDMA，则系统上加载的 AJA 驱动程序也必须支持 RDMA。
目前已验证可与此生产者配合使用的唯一 AJA 设备是 Corvid 44 12G BNC (SDI)。

消费者

Holoscan 延迟工具目前支持 3 种消费者类型。有关每个受支持消费者的描述，请参阅以下部分。

V4L2（板载 HDMI 采集卡）

此消费者 (v4l2) 直接使用 V4L2 API，以便使用某些 NVIDIA 开发者套件上的板载 HDMI 采集卡捕获帧。

V4L2 消费者注意事项

板载 HDMI 采集卡锁定为特定的帧分辨率和帧速率 (1080p @ 60Hz)，因此 1080 是使用此消费者时唯一支持的格式。
-c.device {device} 参数可用于指定用于捕获帧的设备的路径（默认为 /dev/video0）。
V4L2 API 不支持 RDMA，因此 c.rdma 选项将被忽略。

GStreamer（板载 HDMI 采集卡）

此消费者 (gst) 也从板载 HDMI 采集卡捕获帧，但使用包装 V4L2 API 的 v4l2src GStreamer 插件，以支持捕获帧以在 GStreamer 管道中使用。

GStreamer 消费者注意事项

板载 HDMI 采集卡锁定为特定的帧分辨率和帧速率 (1080p @ 60Hz)，因此 1080 是使用此消费者时唯一支持的格式。
-c.device {device} 参数可用于指定用于捕获帧的设备的路径（默认为 /dev/video0）。
v4l2src GStreamer 插件不支持 RDMA，因此 c.rdma 选项将被忽略。

AJA Video Systems (SDI 和 HDMI)

此消费者 (aja) 从支持视频捕获的 AJA Video Systems 设备捕获视频帧。这可以是 SDI 或 HDMI 视频采集卡。

AJA 消费者注意事项

必须使用 AJA Video Systems 支持构建延迟工具，此生产者才能可用（有关详细信息，请参阅构建）。
以下参数可用于配置用于捕获帧的 AJA 设备和通道

-c.device {index}

整数，指定设备索引（即 0 或 1）。默认为 0。

-c.channel {channel}

整数，指定通道号，从 1 开始（即 1 指定 NTV2_CHANNEL_1）。默认为 2。
c.rdma 标志可用于启用 (1) 或禁用 (0) 将 RDMA 与消费者一起使用。如果要使用 RDMA，则系统上加载的 AJA 驱动程序也必须支持 RDMA。
目前已验证可与此消费者配合使用的唯一 AJA 设备是 KONA HDMI（用于 HDMI）和 Corvid 44 12G BNC（用于 SDI）。

故障排除

如果上述任何 loopback-latency 命令失败并出现错误，则以下步骤可能有助于解决问题。

问题： 输出以下错误
复制

已复制！
```
            
            ERROR: Failed to get a handle to the display (is the DISPLAY environment variable set?)
        
```
解决方案： 确保 DISPLAY 环境变量设置为您正在使用的 X11 显示器的 ID；例如，对于显示器 ID 0
复制

已复制！
```
            
            $ export DISPLAY=:0
        
```
如果错误仍然存在，请尝试更改显示器 ID；例如，将 0 替换为 1
复制

已复制！
```
            
            $ export DISPLAY=:1
        
```
将此变量设置在您的 ~/.bashrc 文件中可能也很方便，以便在您每次登录时自动设置它。

问题： 输出类似以下内容的错误

复制
已复制！

            
            ERROR: The requested format (1920x1080 @ 60Hz) does not match
       the current display mode (1024x768 @ 60Hz)
       Please set the display mode with the xrandr tool using
       the following command:

           $ xrandr --output DP-5 --mode 1920x1080 --panning 1920x1080 --rate 60

但使用提供的 xrandr 命令会产生错误

复制
已复制！

            
            $ xrandr --output DP-5 --mode 1920x1080 --panning 1920x1080 --rate 60
xrandr: cannot find mode 1920x1080

解决方案： 尝试以下操作

确保没有其他显示器连接到 GPU。

检查 xrandr 命令的输出，以查看是否支持请求的格式。以下显示了板载 HDMI 采集卡应支持的示例。请注意，支持模式的每一行都在左侧显示分辨率，然后在右侧显示该分辨率的所有支持帧速率。

复制
已复制！

            
            $ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 1872mm x 1053mm
   1920x1080     60.00*+  59.94    50.00    29.97    25.00    23.98
   1680x1050     59.95
   1600x900      60.00
   1440x900      59.89
   1366x768      59.79
   1280x1024     75.02    60.02
   1280x800      59.81
   1280x720      60.00    59.94    50.00
   1152x864      75.00
   1024x768      75.03    70.07    60.00
   800x600       75.00    72.19    60.32
   720x576       50.00
   720x480       59.94
   640x480       75.00    72.81    59.94
DP-6 disconnected (normal left inverted right x axis y axis)
DP-7 disconnected (normal left inverted right x axis y axis)
USB-C-0 disconnected (normal left inverted right x axis y axis)

如果请求 UHD 或 4K 模式，请确保正在使用的 DisplayPort 转 HDMI 电缆支持该模式。
如果 xrandr 输出仍然不显示请求的模式，但电缆和采集设备应该支持它，请尝试重新启动设备。

问题： 输出以下错误之一

复制
已复制！

            
            ERROR: Select timeout on /dev/video0

复制
已复制！

            
            ERROR: Failed to get the monitor mode (is the display cable attached?)

复制
已复制！

            
            ERROR: Could not find frame color (0,0,0) in producer records.

这些错误意味着采集设备未接收到帧，或者帧为空（生产者永远不会输出黑色帧，(0,0,0)）。

解决方案： 检查 xrandr 的输出，以确保环回电缆已连接并且采集设备被识别为显示器。如果输出以下内容，显示未连接任何显示器，则可能意味着环回电缆未正确连接或有故障。尝试重新连接电缆和/或更换电缆。

复制
已复制！

            
            $ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 disconnected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
DP-6 disconnected (normal left inverted right x axis y axis)
DP-7 disconnected (normal left inverted right x axis y axis)

问题： 输出类似以下内容的错误
复制

已复制！
```
            
            ERROR: Could not find frame color (27,28,26) in producer records.
        
```
此特定值 (27,28,26) 附近的颜色显示在 Ubuntu 锁定屏幕上，这会阻止延迟工具正确渲染帧。请注意，颜色值可能与 (27,28,26) 略有不同。

解决方案

按照示例配置部分顶部的注释中提供的步骤启用自动登录并禁用 Ubuntu 锁定屏幕。