我在 opencv 的光流中看到的所有实现都使用视频作为帧数组,然后在每个图像上实现光流。这涉及将图像切成 NxN 块并搜索速度矢量。
虽然视频编解码器中的运动矢量具有误导性,而且它不一定包含运动信息,但我们为什么不使用它来检查哪个块可能有运动,然后在这些块上运行光流呢?那不应该加快进程吗?
我在 opencv 的光流中看到的所有实现都使用视频作为帧数组,然后在每个图像上实现光流。这涉及将图像切成 NxN 块并搜索速度矢量。
虽然视频编解码器中的运动矢量具有误导性,而且它不一定包含运动信息,但我们为什么不使用它来检查哪个块可能有运动,然后在这些块上运行光流呢?那不应该加快进程吗?
为视频编码计算的运动矢量不是“真实运动矢量”。计算目标是找到最佳匹配块以实现最高压缩。它不针对最佳运动估计。这就是为什么它不能很容易地用于运动估计目的。
然而,来自解码器的运动矢量可以以某种方式用于使运动估计更快更好的过程。例如
OpenCV 是一个通用的图像处理框架。它的算法采用帧,而不是压缩视频。
您当然可以编写一个视频解码器,它还将有关从编解码器到 openCV 的位移信息分发出去——但这将是非常特定于编解码器的,因此不在 openCV 本身的范围内。
我清楚地记得读过有关使用嵌入 h.264 中的“运动”向量和类似编解码器进行光流/视觉运动分析的学术工作。最简单的方法是迭代估计(例如 Horn 和 Schunk)。可以简单地使用来自解码器的向量引导迭代算法。
这不会提高估计精度,充其量我猜它可以加快收敛速度,允许更早停止。
并非所有 h.264 编码都具有相同的质量。特别是来自硬件有限的实时系统。在某些情况下,运动向量可能会非常糟糕,实际上对流量估计有害而不是帮助。例如,我正在考虑一款低端 IP 摄像机,该摄像机专为大多数静态场景而设计,在不同的光照等条件下移动。