工具/软件:
根据 tiovx 文档、
与 TIOVX 使用流水线时、不建议使用 Vx_delay 对象。 延迟对象将无意中在图形中创建序列化并破坏所需的流水线。
可以使用图形参数来模拟图形中的延迟、而不是使用延迟对象、从而允许在应用程序中处理延迟。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:
根据 tiovx 文档、
与 TIOVX 使用流水线时、不建议使用 Vx_delay 对象。 延迟对象将无意中在图形中创建序列化并破坏所需的流水线。
可以使用图形参数来模拟图形中的延迟、而不是使用延迟对象、从而允许在应用程序中处理延迟。
您好、
若要使用 vision_apps 中的图形参数执行 vx_delay、请参考 vision_apps 中的 app_DOF 演示。
tivxDmpacDofNode 需要 2 个 vx_金字塔 输入、一个是当前帧、另一个是前一个帧、以便执行密集光流。 因此、从高斯金字塔节点的输出到 dmpacDof 节点存在前馈延迟。
如果启用了 tastic_prediction_flow_vector、则必须将来自 dmpacDof 节点的输出 flow_vector 作为 dmpacDof 节点的延迟输入提供、这会构成反馈延迟。
在当前演示中、使用了 vx_delay 来获得这一帧延迟。
修改后的演示将涉及延迟的三个节点拆分为 3 个图形、涉及延迟的参数创建为图形参数。 然后、将涉及延迟的参数的缓冲区深度加倍、以便我们有足够的缓冲区来存储前一帧。 然后、我们为前馈和反馈延迟分别创建 2 个任务、将缓冲区的入队列/出队列处理到各自的图中。
Gaussial_Pyrame_node -> PYR_graph
Dense_optical_flow_node -> DOF_graph
df_viz_node 及其后的节点-> viz_graph
高斯金字塔的输出作为图形参数、类似地、dmpacDof_node 的 input_current、input_reference、flow_vector_IN、flow_vector_OUT 参数和 dfo_viz 节点的 flow_vector_IN 都作为图形参数。
我们首先将所有缓冲区排队等待高斯金字塔节点的输出、以便它运行并填充缓冲区。 在前馈延迟任务中、一旦 2 个输出出队、我们就会将当前帧和前一帧入 dmpacDof 输入的队列。 现在、n 个帧和 n-1 个帧进入 DOF 节点的队列、同时我们在 DOF 节点的输出上进入缓冲区的队列。
现在 DOF 节点执行并释放参数、我们将 follow_vector_out 出队列、并将其排入 viz_graph 管道、直至达到缓冲区深度。
n 和 n-1 帧从 DOF 节点出队、n+1 帧从高斯金字塔节点出队、然后将 n-1 缓冲器入队列到高斯金字塔节点、并将 n 和 n+1 入队列到 DOF 节点。 其余迭代也进行了类似的操作。
在 feedback_delay 任务中、我们将 follow_vector_OUT 和 follow_vector_IN 缓冲器进入 DOF_node 的队列、执行后、我们将其出队并使其进入 viz_draph、一旦 viz_draph 管道启动完成、开始从 viz_draph 出队并将其作为 flow_vector_OUT 排入 DOF_node。 其余迭代遵循该序列。
将以下补丁应用到 vision_apps 文件夹、获取修改后的 app_DOF 演示、
e2e.ti.com/.../vx_5F00_delay_5F00_graph_5F00_parameter.patch
cd $(psdkra)/vision_apps git apply vx_delay_graph_parameter.patch
此致、
Gokul