多路camera图像做推理，单帧的处理时间超过33ms 如何做多路的camera的同步？

谢谢你的回复。

针对你说的自己写的软件程序我还有一点疑惑。比方说推理或者后处理特别慢，各vpm pipeline底层主动丢的帧frameid不一样就很难找到同步的帧的。请问这种情况你们有没有推荐的比较好的处理方法啊

我建议这么去写选帧逻辑，先每路数据各种get data，然后get data成功push到选帧线程上，选帧线程通过timestamps比对，进行快速选帧；

选帧逻辑少，能在33ms内完成，这样不会阻塞get data线程；这样可以确保所有帧都能获取到，再由上层进入选帧；避免底层主动丢帧；

你这里推理慢一般也是针对4路或者多路一起的，对底层说一般也是一起，如果有sensor的同步的，你可以逻辑上 找个时间点一起拿就好，只要有一个通路的数据没拿到，基本其他三路也不同步了

另外就是通过frameid的逻辑来丢数据了

谢谢

推理时间久导致了hb_vio_free_pymbuf比较晚 晚到一定的程度就导致的底层的丢帧。只是单路不需要同步，丢就丢了无非是fps低于30.

多路的情况各路hb_vio_free_pymbuf时机不太确定。导致底层丢的帧号也不一样 就发现get data上来的帧号都不一样。

请问地平线有没有相关的demo代码可以参考啊

感谢

我们底软这边未提供过选帧demo；我这边只能建议你，起一个拿帧线程，无时无刻都通过get data获取帧数据；再起一个线程用来对获取的帧数据进行timestamps比对；

这样你就能获取所有帧；由你们来决定是否进行丢帧；

我来捋一下，你们把PYM输出作为感知的输入，那么现在同步的需求需要怎么走，是同步完给感知还是同步和感知分开走？

你好，

谢谢！

你可以按照如下设计：

每一路起一个线程专门用来get data，get完push到选帧线程上，选帧线程用来进行timestamp比对，比对成功之后判断是否给推理线程；

如果推理线程空闲，就给推理线程工作，处理完free；

如果推理线程繁忙，就直接free掉；

这样所有帧都能获取，由选帧线程根据推理线程的负载情况进行有选择的丢帧；

谢谢你的思路。

我理解一下你的设计 大前提是;

2、必须保证每帧都能及时获取并释放底层不丢帧，及时获取每一路起一个线程可以保证，如果推理加后处理比较费时的话，不丢帧就不太能保证了。

我还是以单路为例子，vpm_config里面output_buf_num配置为6，起一个线程专门用来get data 因为推理加后处理整个路劲比较久，前面6帧都能取到做推理，经常第7帧取不到,直接取到第8帧，我怀疑是底层刚好产生第7帧的时候第1帧的frame buffer还没有释放。

谢谢！

从你目前的描述来看，是推理耗时长，所以我提供的设计思路就是在推理线程工作期间，正常进行get data/ free image操作，这样buffer轮转起来了，丢帧与否由上层控制，也能避免底层丢帧导致帧匹配异常；

非常感谢你耐心的解答，我们按照您的建议重新修改试试。

你好感谢你耐心的解答，

还有一个细节点的问题想请教一下，

以output_buf_num配置为6（编号0~5）为例。如果我拿了0号buffer一直不释放，但是1~5号buffer都能很快的free。保证底层图像ready的时候bufffer 1~5可以用。这时候底层会因为buffer0 拿不到而丢帧吗？

感谢！

不会因为buffer0导致丢帧，底层buffer队列轮转的要求是大于2块，所以只要确保2块buffer参与轮转，就能保证底层不丢帧；

你好，

这种情况下是不会有问题得，只要在退出前还回来防止内存泄漏就行，底层不会特别关注一个buffer得

谢谢您的恢复

在硬件已经保证的sensor数据同步的前提下,

1、这个匹配肯定是在推理之前完成吧？

2、多个线程拿多的pipeline的图，vpm_config里面output_buf_num的设置是否有建议的值。有时候推理加后处理比较耗时，底层会发生丢图现象，每条pipeline丢的frameid又不一样，这样就很难找到同步的帧了。

1.对的

2.目前的config是可以满足所有场景，如果能保证sensor同步，基本可以按照时间点去拿数据，驱动丢帧是一致性的无差别的，有一阵数据丢，可以选择这个时间点的数据都不要

如果保证不了sensor的同步化，就可能需要通过一个缓存队里来实现，拿到了4帧一致的数据 就从队里获取4路数据，拿不到帧号就过了 那么其他 几路的数据也就丢掉，队里缓存下一个帧号的数据

1.底层不会提供同步帧匹配机制，望知悉；