将视频存储在SQLite数据库中? [英] Store a video in a SQLite database?

问题描述

我正在研究一种算法，该算法需要对可能较长的视频(至少30分钟)中的视频帧进行非常快速的随机访问.我目前正在使用OpenCV的VideoCapture读取我的视频，但是搜索功能已损坏或速度很慢.到目前为止，我发现最好的方法是在MKV容器中使用MJPEG编解码器，但是速度不够快.

I'm working on an algorithm which needs very fast random access to video frames in a possibly long video (minimum 30 minutes). I am currently using OpenCV's VideoCapture to read my video, but the seeking functionality is either broken or very slow. The best I found until now is using the MJPEG codec inside a MKV container, but it's not fast enough.

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

I can chose any video format or even create a new one. The storage space is not a problem (to some extents of course). The only requirement is to get the fastest possible seeking time to any location in the video. Ideally, I would like to be able to access to multiple frames simultaneously, taking advantages of my quad-core CPU.

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

I know that relational databases are very good to store large volumes of data, they allows simultaneous read accesses and they're very fast when using indexes.

SQLite是否适合我的特定需求?我计划存储以JPEG压缩的每个视频帧，并在帧号上使用索引来快速访问它们.

Is SQLite a good fit for my specific needs ? I plan to store each video frame compressed in JPEG, and use an index on the frame number to access them quickly.

对我来说，框架只是一幅图像，而不是整个视频.一个30百万视频@ 25 fps包含30 * 60 * 25 = 45000帧，我希望能够使用其编号快速获取其中一个.

EDIT : for me a frame is just an image, not the entire video. A 30mn video @ 25 fps contains 30*60*25=45000 frames, and I want to be able to quickly get one of them using its number.

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

EDIT : For those who could be interested, I finally implemented a custom video container saving each frame in fixed-sized blocks (consequently, the position of any frame can be directly computed !). The images are compressed with the turbojpeg library and file accesses are multi-threaded (to be NCQ-friendly). The bottleneck is not the HDD anymore and I finally obtained much better perfs :)

推荐答案

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

I don't think using SQLite (or any other dabatase engine) is a good solution for your problem. A database is not a filesystem.

如果您需要的是非常快速的随机访问，然后坚持使用文件系统，则针对这种用途进行了设计，并为此进行了优化.根据您的评论，您说一个5小时的视频需要450万个文件，嗯，在我看来这不是问题.当然，目录列表会有点长，但是您将获得绝对最快的可能的随机访问.而且肯定会比SQLite更快，因为您是SQLite的抽象级别之一.

If what you need is very fast random access, then stick to the filesystem, it was designed for this kind of usage, and optimized with this in mind. As per your comment, you say a 5h video would require 450k files, well, that's not a problem in my opinion. Certainly, directory listing will be a bit long, but you will get the absolute fastest possible random access. And it will certainly be faster than SQLite because you're one level of abstraction under.

如果您真的担心目录列出时间，则只需要像树一样组织文件夹结构即可.这样可以为您提供更长的路径，但可以更快地列出.

And if you're really worried about directory listing times, you just have to organize your folder structure like a tree. That will get you longer paths, but fast listing.

这篇关于将视频存储在SQLite数据库中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！