[参考译文] TDA4VM：葡萄完全运行时、显示屏上第一帧的大延迟

不、不 这已经在这个阶段完成了！ 图形正在运行、DESER-SER-SENSOR 已完全配置。  

最后的日志消息 由 AEwB 内核进程在图形运行时发送。  Grapho 仅在传感器准备就绪后运行。

谢谢

您好！

您是否可以将摄像头指向一个计时器、并检查实际显示屏上的帧是否存在延迟？

即您看到的定时器值与显示屏上的定时器值？

您看到那里的2秒差异了吗？

此致、

Nikhil

你好

大约有1s 的延迟、

和大约2s 从 TivixdisplayProcess 开始,直到图像是有效的屏幕/视频捕捉

您好！

您的应用中是否具有较大的缓冲深度？

我可以知道您在这里运行的应用吗？ 它是否有多个图形或图形参数？

此致、

Nikhil

你好。

缓冲深度设为4。

只有一个图形。

该参数为  graph_parameters_queue_params_list[graph_parameter_index].refs_list =(vx_reference*)&obj->captureObj.raw_image_arr[0]；

下面我介绍一些节点统计信息：

BR

噢……还可以

此操作应与 SDK 中的多摄像头演示相同。 我是否可以知道此处使用的硬件？ 是 EVM 还是您的定制板？

您是否还在使用 HDMI 或 eDP 输出？

此致、

Nikhil

是的、它基于那个演示。

硬件是 EVM PROC079E3 (我想是旧版本)。

Outpus 为 eDP。 我已经使用 HDMI 适配器(用于 HDMI 输入到 HDMI 采集器件)以及 eDP Direct 到显示器进行了测试。  

BR

您好！

在此 EVM 中、使用 SPL 引导流程时是否看到相同的内容？ 我目前在 SPL 或 SBL 引导流程的末尾没有看到这种延迟。  
通常、当显示节点获得第二个缓冲区时、它会开始流式传输。 (即从显示过程函数的第二次调用开始)

我可以知道您目前使用的是哪个 SDK 版本吗？

此致、

Nikhil

您好！  

我已经用 SPL 进行了测试、看到类似的延迟、但并不总是如此。 下面我来描述一下具体情况：

• SPL 运行 Uboot 和 Ficosa 分布
• UBoot 启动 MCU2_0固件、自动将四个 D3摄像头配置到 StreamOff (设置 Desser、SER、Sensor 等)。 因此、当 A72加载内核时、MCU2_0准备了摄像头。
• 从 shell 开始、它将启动 multicam_recording 应用程序、这是一个简单的链式应用程序、基于 SDK 的 Mosaic 应用程序、可显示4个摄像头。 该应用程序准备图形(初始化节点等)并请求相机上的流。

以下是观察结果的差异：

• 自动下载 第一次( 从加电或重新启动)、屏幕上将显示视频 2-2.5秒 之后 该图正在运行
• 是多少 已重新启动 时、屏幕上的视频将出现在周围 0.5秒后 该图正在运行。

似乎如果图形在系统范围内重新启动后运行,显示视频所需的时间比仅在视频链重新启动后运行视频所需的时间要长得多。

这使我认为 MCU 可以配置或初始化某个东西(¿VPAC/HWA？)。 首次从主机链请求时间比重新引导并再次请求主机链所花费的时间更长。

这是合理的吗？ 这可以最小化吗？

注意：以下是一次实验中的时间事件(通过私人消息请求完整视频)

加电和启动

00：25：956运行视频图

00:28:320视频在 OBS 屏幕

停止并 启动

00：34：908运行视频图表

00:35:487视频 OBS

已停止并 重新启动

00：53：625运行视频图表

00:54:202视频在 OBS 屏幕

重新启动和 启动

1：42：207运行视频图形

1:44:532视频在 OBS 屏幕

已停止并 重新启动

1：51：071运行视频图

1:51:506视频在 OBS 屏幕

非常感谢

这是否与通过屏幕/显示器/视频捕捉完成的任何握手或协商有关？ 是否有 HDCP 握手？

您好！

我最后通过 SDK 多摄像头演示进行了相同的检查 但是、在对显示节点的过程回调进行第二次调用期间、显示将立即出现。

请确认您正在使用的 OBS 屏幕是否未引入此延迟？

我最后使用的是显示器 您可以同样尝试吗？

此致、

Nikhil

您好、Nikhil。  

如果我调试我看到的类似您的 BP 设置、则第二个呼叫图像位于 OBS 屏幕中。 但在 CCS 和调试器正在运行以及 BPS 时、时序完全不同：在 BP 停止、然后 在第二次调用再次停止需要2s、因此这可以足够覆盖延迟。

当您在为电路板上电后运行 multicam_demo 时以及在第二次调用 multicam_demo (关闭应用并从外壳重新启动)时、您是否观察到了相同的反应时间？ 我没有；请查看我的日志。

谢谢

尊敬的 Pablo：

在我结束时、这两种情况的行为都是相同的、即重新启动和应用程序重新启动。  

我在这里看到的一个不同之处是、R5会在触发应用程序之前配置传感器和 DES 通道？ 例如、在 R5F 中的 AppInit 期间、然后在 Linux 启动后(而不是在某些 systemd 初始化期间)触发应用程序  

而在通常的多摄像头流量中、传感器和串行器/解串器是在应用启动后配置的。 (即 Linux 和 RTOS 已完全启动)。  
因此、为了了解问题是否可能是由这种更改引起的、您能否在自己的终端上尝试按原样运行 multicam SDK 应用、看看您是否面临同样的问题(即只有在应用触发后才发生传感器和 SerDes 配置)。  

此致、

Nikhil