3

我正在研究一种算法，该算法需要非常快速地随机访问可能很长的视频（至少 30 分钟）中的视频帧。我目前正在使用 OpenCV 的 VideoCapture 来阅读我的视频，但是搜索功能要么坏了要么很慢。到目前为止，我发现的最好的方法是在 MKV 容器中使用 MJPEG 编解码器，但速度还不够快。

我可以选择任何视频格式，甚至可以创建一个新格式。存储空间不是问题（当然在某种程度上）。唯一的要求是尽可能快地搜索视频中的任何位置。理想情况下，我希望能够同时访问多个帧，利用我的四核 CPU。

我知道关系数据库非常适合存储大量数据，它们允许同时读取访问，并且在使用索引时速度非常快。

SQLite 是否适合我的特定需求？我计划以 JPEG 格式存储每个视频帧，并使用帧号索引来快速访问它们。

编辑：对我来说，一帧只是一个图像，而不是整个视频。一个 25 fps 的 3000 万视频包含 30*60*25=45000 帧，我希望能够使用它的数量快速获得其中一个。

编辑：对于那些可能感兴趣的人，我最终实现了一个自定义视频容器，将每个帧保存在固定大小的块中（因此，可以直接计算任何帧的位置！）。图像使用 turbojpeg 库压缩，文件访问是多线程的（对 NCQ 友好）。瓶颈不再是硬盘驱动器了，我终于获得了更好的性能:)

4

2 回答 2

5

我不认为使用 SQLite（或任何其他 dabatase 引擎）是解决您问题的好方法。数据库不是文件系统。

如果您需要非常快速的随机访问，那么请坚持使用文件系统，它是为这种用途而设计的，并为此进行了优化。根据您的评论，您说 5 小时的视频需要 450k 文件，好吧，我认为这不是问题。当然，目录列表会有点长，但您将获得绝对最快的随机访问。而且它肯定会比SQLite 更快，因为你是一个抽象级别。

如果您真的担心目录列出时间，您只需像树一样组织您的文件夹结构。这将使您获得更长的路径，但可以快速列出。

于 2012-06-17T16:43:35.553 回答
1

保持高水平的视角。问题是 OpenCV 在源视频中的搜索速度不够快。这可能是因为

  • 编解码器不是 OpenCV 的强项
  • 未对源视频进行编码以实现高效搜索

你的机器有很多专用的图形硬件可以利用，但它没有在 17 GB 数据集中随机搜索的专门功能，无论是文件、数据库还是一组文件。磁盘每次寻道需要几毫秒。SSD 会更好，但仍然不是那么好。然后你等待它加载到主内存中你必须首先生成所有数据。

使用ffmpeg，它应该可以非常有效地处理解码，甚至可以使用 GPU。这是一个教程。（免责声明，我自己没有使用过。）

您可以预处理视频以添加关键帧。原则上，这不需要完全重新编码，至少对于 MPEG 而言，但我对细节知之甚少。MJPEG 本质上将所有帧都转换为关键帧，但您可以找到中间立场，以 2 倍的尺寸成本寻找 1.5 倍的速度。但要避免撞到磁盘。

对于 SQLite，这是一个很好的解决在 17 GB 数据范围内寻找问题的方法。数据库未针对随机访问进行优化的概念是 poppycock。他们当然是。文件系统是一种数据库。由于硬件而不是软件，17 GB 中的随机访问速度很慢。

我建议不要将文件系统用于此任务，因为它是与机器其余部分同步的共享资源。此外，创建 50 万个文件（并在完成后删除它们）将需要很长时间。这不是文件系统的专门用途。不过，您可以通过在每个文件中存储多个图像来解决这个问题。但是你需要一些格式来找到所需的图像，然后为什么不把它们全部放在一个文件中呢？

确实，（如果采用 17 GB 路线）为什么不忽略整个问题并将所有内容都放在虚拟内存中呢？VM 与 SQLite 或文件系统一样擅长进行磁盘查找。只要操作系统知道进程使用那么多内存是可以的，并且您使用的是 64 位指针，它应该是一个很好的解决方案，并且首先要尝试。

于 2012-06-18T05:22:11.290 回答