[参考译文] AM62A7：当 CPU 使用率很高时、帧跳过

尊敬的 Jason：

您是否使用完整的流水线进行测试、如下所述： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1576997/am62a7-tidss-error

是否可以像您在此处所做的那样使用禁用的不同元素进行测试：  关于 AM62A7：TIDSS 错误 

这应该可以帮助我们确定管道的特定部分是否导致了此问题。

我们开发团队提出的另一个潜在问题可能是、在运行算法足够长的时间后、流水线完全停止。 在以下外部 Jira 中记录的并行解码器中也注意到了类似的问题： https://sir.ext.ti.com/jira/browse/EXT_EP-12787

在此期间、我将尝试在我这边重复这个问题。

此致、
Jay

嗨、Jay

我已将管道更改为以下内容。然后、stress-ng --cpu 4 --cpu-load 70 --timeout 200在后台运行后、问题似乎不会出现。 让我花些时间逐步添加一些要素来测试问题可能发生的位置。

gst-launch-1.0 v4l2src device=/dev/video3 io-mode=dmabuf-import ! \
video/x-raw, format=UYVY, width=1920, height=1536, framerate=60/1 ! \
tiovxldc dcc-file="/root/isp_config/dcc_ldc.bin" sensor-name="X3F" ! \
video/x-raw, format=NV12, width=1920, height=1536, framerate=60/1 ! \
tiovxmultiscaler name=multi target=0 \
multi.src_0 ! video/x-raw, width=1920,height=720,format=NV12 ! queue ! \
tiovxmosaic ! \
kmssink driver-name=tidss sync=false skip-vsync=true

BR

Jason

嗨、Jay

此问题也可能与算法有关。 当我只启用预览和算法函数、并使用 stress-ng 增加 CPU 使用率时、就会出现问题。 添加其他功能不会触发问题。 下面是有问题的流水线图。

我尝试使用命令模拟流水线、但无法重现问题。

gst-launch-1.0 v4l2src device=/dev/video3 io-mode=dmabuf-import ! \
video/x-raw, format=UYVY, width=1920, height=1080, framerate=60/1 ! \
tiovxldc dcc-file="/root/isp_config/dcc_ldc.bin" sensor-name="X3F" ! \
video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1 ! \
tiovxmultiscaler name=multi target=0 \
multi.src_0 ! video/x-raw, width=1280,height=720,format=NV12 ! queue ! mosaic.sink_0 \
multi.src_1 ! video/x-raw, width=640,height=720,format=NV12 ! queue ! mosaic.sink_1 \
multi.src_2 ! video/x-raw, width=960,height=540,format=NV12 ! queue ! multi2.sink \
tiovxmultiscaler name=multi2 target=1 \
multi2.src_0 ! video/x-raw, width=608,height=352,format=NV12 ! queue ! \
fakesink sync=false \
tiovxmosaic name=mosaic \
sink_0::startx="<0>" sink_0::starty="<0>" \
sink_1::startx="<1280>" sink_1::starty="<0>" ! \
kmssink driver-name=tidss sync=false skip-vsync=true

BR

Jason

尊敬的 Jason：

这种情况下的一个潜在问题可能是算法花费时间进行推理可能会导致流水线停滞。 要确定此问题是指该问题、还是 gstreamer 流水线本身、还是算法中的问题、请将数据（使用 appsink）拉入占用帧并处于睡眠一秒的应用程序中。 如果这会导致流水线停滞、那么通过在 appsink 上设置以下标志 https://gstreamer.freedesktop.org/documentation/app/appsink.html?gi-language=c#appsink:leaky-type 或添加队列（我们可以努力弄清楚该器件）、问题可能会得到解决。

如果这不起作用、请详细介绍所有算法的作用。 它只是推理、还是执行其他一些任务？

此致、
Jay

嗨、Jay

我们不在 appsink 中直接处理算法,因为我们发现 appsink 中直接处理算法会导致预览也受算法帧速率的影响。 即使在多个位置添加队列后也是如此。  我们 appsink 中的新样本回调如下所示,我们启动了一个新线程来从检索数据以frame_queue进行算法推理。

static GstFlowReturn AlgProcessSample(GstAppSink *appsink, gpointer user_data)
{
    // printf("AlgProcessSample\n");
    GstSample *sample = gst_app_sink_pull_sample(appsink);
    if (!sample)
    {
        g_print("algo no sample!\n");
        return GST_FLOW_ERROR;
    }

    GstBuffer *buffer = gst_sample_get_buffer(sample);
    if (!buffer)
    {
        g_print("algo no buffer!\n");
        return GST_FLOW_ERROR;
    }

    // int64_t syscurr = media_getBootTick();

    // copy frame
    GstBuffer *new_buf = gst_buffer_copy_deep(buffer);

    g_async_queue_push(frame_queue, new_buf);

    // int64_t sysend = media_getBootTick();
    // printf("alg duration: (%lld)\n\n", sysend - syscurr);
    gst_sample_unref(sample);
    return GST_FLOW_OK;
}

我试图修改回调函数,也禁用了实际运行算法的线程,但这个问题仍然可以重现。所以,我相信这个问题可能与算法处理无关。 问题是否在我的管道中？我的队列或其他属性的设置是否有问题？

static GstFlowReturn AlgProcessSample(GstAppSink *appsink, gpointer user_data)
{
    // printf("AlgProcessSample\n");
    GstSample *sample = gst_app_sink_pull_sample(appsink);
    if (!sample)
    {
        g_print("algo no sample!\n");
        return GST_FLOW_ERROR;
    }

    GstBuffer *buffer = gst_sample_get_buffer(sample);
    if (!buffer)
    {
        g_print("algo no buffer!\n");
        return GST_FLOW_ERROR;
    }
    
    usleep(10 * 1000);
    // printf("alg duration: (%lld)\n\n", sysend - syscurr);
    gst_sample_unref(sample);
    return GST_FLOW_OK;
}

BR

Jason

尊敬的 Jason：

这确实排除了算法作为错误源。 我正尝试用类似的管道在我的终端复制此错误。

作为一项测试、您是否可以尝试在 v4l2src 之后添加一个 leaky=2 属性的队列元素。 如果某些元素使流水线停滞、这将丢弃较旧的帧。

我在上一次答复中提出的问题是、由于算法消耗的帧不够快、流水线可能会间歇性停止。 这需要在流水线本身中固定。

同时、我将尝试重现此问题、并返回给您更好地分析可能出现的问题。

此致、
Jay

嗨、Jay

我在 v4l2src 之后添加了一个队列元素、问题仍然存在

BR

Jason

尊敬的 Jason：

我想我已经在我的身边重现了这个问题、并试图了解这个问题是什么。 但我正在进行一些重要的调试。 因此、请预计响应会延迟。 我会尝试通过星期五回复您。 同样的。

此致、
Jay

我在 v4l2src 之后添加了一个队列元素、问题仍然存在

BR

嗨、Jason、

很抱歉耽误回复。 我基于 appsink 的流水线重现了错误。 但在这里、您似乎已经删除了包含算法处理的整个流水线。 您能否确认您是否在此流水线中也遇到了问题、因为在 90%的负载下、我不会遇到这个问题。

另外、在带延迟的测试中、测试是否在没有 CPU 负载的情况下正常运行？

此致、
Jay

嗨、Jay

关于基于 appsink 的问题复制、您是否找到了修复程序？

至于上述管道,我将在核实后回到你身边。

BR、

Jason

尊敬的 Jason：

您可以尝试使用以下流水线吗：

v4l2src device=/dev/video3 io-mode=dmabuf-import ! \
video/x-raw, format=UYVY, width=1920, height=1080, framerate=60/1 ! \
tiovxldc dcc-file="/root/isp_config/dcc_ldc.bin" sensor-name="X3F" ! \
video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1 ! \
tee name=t \
t. ! tiovxmultiscaler name=multi target=0 \
multi.src_0 ! video/x-raw, width=1280,height=720,format=NV12 ! queue ! mosaic.sink_0 \
multi.src_1 ! video/x-raw, width=640,height=720,format=NV12 ! queue ! mosaic.sink_1 \
t. ! queue max-size-buffers=1 leaky=downstream ! tiovxmultiscaler name=multi2 target=1 \
multi2.src_0 ! video/x-raw, width=608,height=352,format=NV12 ! \
appsink drop=true name=sink_0 \
tiovxmosaic name=mosaic background=/tmp/background_0 \
sink_0::startx="<0>" sink_0::starty="<0>" \
sink_1::startx="<1280>" sink_1::starty="<0>" ! \
video/x-raw, width=1920, height=1080 ! \
kmssink driver-name=tidss force-modesetting=true sync=false

关键变化：由于可以通过单个多标量节点实现输出流水线的输出分辨率、因此我使用 TEE 在多标量之前拆分流水线。 TEE 节点（第二分支）之后的队列也设置了 LEAY 属性。 因此、如果传入流水线的帧速率比算法的处理高、则可能会丢弃较旧的帧。

如果这不起作用、您可以尝试如下所述运行： https://github.com/TexasInstruments/edgeai-gst-apps/tree/main/scripts/gst_tracers

这应该会生成有用的调试日志、以查看哪个元素可能导致延迟问题。

此致、
Jay