我在opencv中的光流中看到的所有实现都使用视频作为帧阵列,然后在每个图像上实现光流。这涉及将图像切片成NxN块并搜索速度矢量。
虽然视频编解码器中的运动矢量具有误导性并且不一定包含运动信息,但为什么我们不使用它来检查哪个块可能有运动,然后在这些块上运行光流?难道不能紧紧抓住这个过程吗?
答案 0 :(得分:2)
OpenCV是一个通用的图像处理框架。它的算法采用帧而非压缩视频。
你当然可以编写一个视频解码器,它也会提供有关从编解码器到openCV的位移信息 - 但这将是特定于编解码器的,因此不在openCV本身的范围内。
答案 1 :(得分:1)
我清楚地记得已经阅读了关于使用"运动"嵌入在h.264中的矢量和用于光流/视觉运动分析的类似编解码器。最简单的方法是进行迭代估计(例如Horn和Schunk)。可以使用来自解码器的矢量简单地引导迭代算法。
这不会提高估计的准确性,充其量我猜它可以加快收敛速度,允许提前停止。
并非所有h.264编码都具有相同的质量。特别是来自硬件有限的实时系统。有可能情况下,运动矢量将是完全可怕的,实际上是对流量估计的损害而不是帮助。我想的是一个低端IP摄像机的例子,它主要用于静态场景,在不同的光线下移动等。
答案 2 :(得分:1)
为视频编码计算的运动矢量不是“真实运动矢量”。计算目标是找到最佳匹配块以实现最高压缩率。它没有针对最佳运动估计。这就是为什么它不能轻易用于运动估计的原因。
但是,可以以某种方式使用来自解码器的运动矢量来使运动估计更快,更好。例如