TDA4VM: 视频非常卡顿

Mr. Wang

Prodigy 10 points

Part Number: TDA4VM

Hi，TI 工程师：

环境：sensor的输出是YUV_422的，关闭了viss和aewb；

问题描述：在运行run_app_multi_cam.sh时，输出的视频非常卡顿；

以下为输出：

请问一下：1）LDC对于解析YUV_422并转换为NV12格式是否完全支持呢？

2）视频非常卡顿是哪里的问题，有没有思路或建议？

1 年多前

0 Gary Lu 1 年多前

TI__Mastermind 27060 points

1）关于LDC对于解析YUV_422并转换为NV12格式的支持情况，我需要确认一下您所指的LDC是指什么设备或模块，因为不同的设备或模块可能有不同的支持情况。一般来说，LDC（Lens Distortion Correction）模块通常支持YUV格式的输入，并且可以进行格式转换，但具体支持的格式可能因设备而异。

2）视频卡顿的问题可能有多种可能性，包括但不限于处理器性能不足、数据传输带宽不足、缓冲区问题等。建议您按照以下思路进行排查和调试：
- 检查系统资源占用情况，确保处理器和内存等资源足够支持视频处理和传输。
- 检查数据传输路径，包括传感器到处理器的数据传输带宽是否足够，中间数据处理环节是否存在瓶颈等。
- 检查软件应用的实时性和优化程度，确保视频处理的算法和流程能够在给定的硬件条件下实时运行。
- 考虑是否需要对视频流进行降采样或者其他优化处理，以减轻系统负担。

0 Mr. Wang 1 年多前回复 Gary Lu

Prodigy 10 points

在这个Demo中LDC是镜头畸变矫正模块，它支持YUV422格式的输入并转换成YUV420吗？我用的设备是J721e开发板。

0 Gary Lu 1 年多前回复 Mr. Wang

TI__Mastermind 27060 points

支持

0 Mr. Wang 1 年多前

Prodigy 10 points

您好，Lu：

我这边分别运行了app_single和app_multi，并且在运行的时候打印了Perf，我看到single的fps一直可以保持在30帧，而multi只能保持1帧以下，并且multi的"捕获节点"的处理时间一直在增加。

以下是两者log：

single：

GRAPH:         graph_84 (#nodes =   4, #executions =    300)
 NODE:       CAPTURE2:                  node_95: avg =  33292 usecs, min/max =  33196 /  44795 usecs, #executions =        300
 NODE:      VPAC_LDC1:                 node_101: avg =   3438 usecs, min/max =   3388 /   3553 usecs, #executions =        300
 NODE:      VPAC_MSC1:                 node_103: avg =   5211 usecs, min/max =   5192 /   5335 usecs, #executions =        300
 NODE:       DISPLAY1:                 node_105: avg =   5991 usecs, min/max =     84 /   6173 usecs, #executions =        300

 PERF:            TOTAL: avg =  33331 usecs, min/max =  33165 /  33455 usecs, #executions =        117

 PERF:            TOTAL:   30. 0 FPS
 
------------------------------------------

GRAPH:         graph_84 (#nodes =   4, #executions =    486)
 NODE:       CAPTURE2:                  node_95: avg =  33273 usecs, min/max =  33178 /  44795 usecs, #executions =        486
 NODE:      VPAC_LDC1:                 node_101: avg =   3429 usecs, min/max =   3386 /   3568 usecs, #executions =        486
 NODE:      VPAC_MSC1:                 node_103: avg =   5221 usecs, min/max =   5189 /   5373 usecs, #executions =        486
 NODE:       DISPLAY1:                 node_105: avg =   6062 usecs, min/max =     84 /   6386 usecs, #executions =        486

 PERF:            TOTAL: avg =  33331 usecs, min/max =  33160 /  33529 usecs, #executions =        186

 PERF:            TOTAL:   30. 0 FPS

multi：

GRAPH: app_multi_cam_graph (#nodes =   4, #executions =      1) capture_node: avg = 611955 usecs, min/max = 611955 / 611955 usecs, #executions =          1 ldc_node: avg =  14028 usecs, min/max =  14028 /  14028 usecs, #executions =          1 mosaic_node: avg =  38384 usecs, min/max =  38384 /  38384 usecs, #executions =          1 DisplayNode: avg =     86 usecs, min/max =     86 /     86 usecs, #executions =          1 0 usecs, min/max = 4294967295 /      0 usecs, #executions =          0 TOTAL: avg = 208992 usecs, min/max =      7 / 626921 usecs, #executions =          3 -------------------------------------------- (#nodes =   4, #executions =     32) capture_node: avg = 1187878 usecs, min/max =  33258 / 16263708 usecs, #executions =         32 ldc_node: avg =  14054 usecs, min/max =  13917 /  14303 usecs, #executions =         32 mosaic_node: avg =  14735 usecs, min/max =  11258 /  38654 usecs, #executions =         32 DisplayNode: avg =  10453 usecs, min/max =     86 /  14004 usecs, #executions =         32 0 usecs, min/max = 4294967295 /      0 usecs, #executions =          0 TOTAL: avg = 1206559 usecs, min/max =  33312 / 16263963 usecs, #executions =         31 -------------------------------------------- (#nodes =   4, #executions =     35) capture_node: avg = 1335939 usecs, min/max =  32220 / 16263708 usecs, #executions =         35 ldc_node: avg =  14060 usecs, min/max =  13917 /  14303 usecs, #executions =         35 mosaic_node: avg =  14458 usecs, min/max =  11258 /  38654 usecs, #executions =         35 DisplayNode: avg =  10946 usecs, min/max =     86 /  16585 usecs, #executions =         35 0 usecs, min/max = 4294967295 /      0 usecs, #executions =          0 TOTAL: avg = 2915655 usecs, min/max =  32510 / 8680513 usecs, #executions =          3 TOTAL:    0.34 FPS

我不知道如何继续分析，等待您的回复！非常感谢！

0 Mr. Wang 1 年多前回复 Mr. Wang

Prodigy 10 points

另外，运行multi的时候，log输出时，vxGraphParameterDequeueDoneRef()这个接口处理时间很长，主要是在do_while中

API: vxGraphParameterDequeueDoneRef()
            /* wait until a reference is dequeued */
            do
            {
                ref = NULL;
                status = tivxDataRefQueueDequeueDoneRef(data_ref_q, &ref);
                if((status == (vx_status)VX_SUCCESS) && (ref != NULL))
                {
                    /* reference is dequeued break from do - while loop with success */
                    exit_loop = (vx_bool)vx_true_e;
                }
                else
                {
                    /* wait for "ref available for dequeue" event */
                    status = tivxDataRefQueueWaitDoneRef(data_ref_q,
                            graph->timeout_val);
                    if(status!=(vx_status)VX_SUCCESS)
                    {
                        /* some error in waiting for event, break loop with error */
                        exit_loop = (vx_bool)vx_true_e;
                    }
                }
            } while(exit_loop == (vx_bool)vx_false_e);

0 Gary Lu 1 年多前回复 Mr. Wang

TI__Mastermind 27060 points

可能有多种原因导致多线程应用性能下降和处理时间增加。其中一些可能的原因包括多线程同步问题、资源竞争、数据依赖性等。另外，vxGraphParameterDequeueDoneRef()接口处理时间过长也可能与资源管理或者数据流处理有关。

0 Gary Lu 1 年多前回复 Mr. Wang

TI__Mastermind 27060 points

我建议您检查多线程应用的实现，确保线程间的同步和资源管理正确。

另外您可以需要分析多线程应用的性能瓶颈

处理器

处理器论坛

TDA4VM: 视频非常卡顿