Use a timeseries DBMS to store video

time-series-database

From a research study involving participants with a camera, I have chunks of video recording. I have to split them as part of the preprocessing into short sequences of around 5 min long. Each file will be named after its time-stamp in the sequence. I can store them as binary blobs in a database.

In this study, I also have other sensors. It's clear that I should Use a time series DBMS to store these data (IoT sensing data). This will facilitate queries based on time. Do you see a problem with me storing the file paths and indexing them into a TimeseriesDB (like InfluxDB) based on their file blob's sequential time-stamps to facilitate time-driven queries?

The Q & A Should binary files be stored in the database? partially answers my question – from looking at that answer is sounds like storing video as a blob is a good solution. But my question is more about indexing video by the file's time-stamps.

The video is recorded in large (time) chunks at a time. as part of the cleaning/pre-processing, we split them into 5-minute long segments. Each segment is saved to a file that retains/maintains a date-time-stamp (a 50 min long video is split into 10). Putting it this way, it seems natural to store these file paths per their date-time-stamp. I just want to run my logic by others.

Best Answer

From a research study involving participants with a camera, I have chunks of video recording. I have to split them as part of the preprocessing into short sequences of around 5 min long. Each file will be named after its time-stamp in the sequence. I can store them as binary blobs in a database.

It doesn't make much sense to split apart a video, unless for security. It's a container with an audio and video stream. Normally they're stored in a container like AVI, MP4 or MKV (the open standard). In MKV-parlance, you have "Chapters". This is effectively a timeseries database.

Also, you may want to be careful if you're extracting and cutting them. Keep in mind most video streams are compressed, and de-compressing and re-compressing can introduce artifacts and such.

Here are the fields store in the Chapter's data

See Also