saving video in mp4 format on host #49

Green-cattow commented 2025年03月10日 19:52:39 +01:00

On the host machine, video files are saved in the mdat and meta formats. If you try to play a video directly from disk—without downloading it via the web interface (or if you copy the entire storage_dir to another drive and try to play video on another host)—you won't be able to open it. VLC and other media players can't read the mdat format, and ffmpeg doesn't recognize it either, making it impossible to decode the recordings for normal playback.

Would it be possible to add an option to save videos in a more standard format, such as MKV or MP4, directly on disk?

On the host machine, video files are saved in the mdat and meta formats. If you try to play a video directly from disk—without downloading it via the web interface (or if you copy the entire storage_dir to another drive and try to play video on another host)—you won't be able to open it. VLC and other media players can't read the mdat format, and ffmpeg doesn't recognize it either, making it impossible to decode the recordings for normal playback. Would it be possible to add an option to save videos in a more standard format, such as MKV or MP4, directly on disk?

Curid commented 2025年03月10日 20:24:41 +01:00

The raw video is stored in .data and the frame metadata is stored in .mdat.

mp4 can store the frame metadata in either: the start of the file, the end of the file, or interleaved between the raw frames.
Storing the metadata in the start would require the whole video to be copied when the recording is finalized. Storing the metadata at the end would mean that the metadata have to be stored somewhere else until the recording is finalized, and it'd be a lot of extra code to restore unsaved recordings from crashes. Storing the metadata interleaved would mean that the player wouldn't be able to seek to the middle of the video without first parsing half the file.

There is a CLI option for converting recordings to mp4 #25

The raw video is stored in `.data` and the frame metadata is stored in `.mdat`. mp4 can store the frame metadata in either: the start of the file, the end of the file, or interleaved between the raw frames. Storing the metadata in the start would require the whole video to be copied when the recording is finalized. Storing the metadata at the end would mean that the metadata have to be stored somewhere else until the recording is finalized, and it'd be a lot of extra code to restore unsaved recordings from crashes. Storing the metadata interleaved would mean that the player wouldn't be able to seek to the middle of the video without first parsing half the file. There is a CLI option for converting recordings to mp4 #25

Green-cattow commented 2025年03月11日 12:59:17 +01:00

I understand that if the camera fails, the last recorded video might be damaged, and the player wouldn't be able to seek directly to the middle of the video. However, most media players allow increasing the playback speed (e.g., 8x), which makes it easy to quickly reach the last part of the video before the failure. That's why I believe storing videos in a standard format like MKV would be more convenient for users.

I understand that if the camera fails, the last recorded video might be damaged, and the player wouldn't be able to seek directly to the middle of the video. However, most media players allow increasing the playback speed (e.g., 8x), which makes it easy to quickly reach the last part of the video before the failure. That's why I believe storing videos in a standard format like MKV would be more convenient for users.

Curid commented 2025年03月11日 18:58:09 +01:00

However, most media players allow increasing the playback speed (e.g., 8x), which makes it easy to quickly reach the last part of the video before the failure.

Players are still able to seek no matter where the frame metadata is stored, it's just a matter of if they have to waste a lot of bandwidth downloading all preceding frames first.

That's why I believe storing videos in a standard format like MKV would be more convenient for users.

I don't really see the use case, do you just want to avoid the recording page because doesn't have a way to change the playback speed? that's easy to add. Or has it more to do with vendor lock-in?

> However, most media players allow increasing the playback speed (e.g., 8x), which makes it easy to quickly reach the last part of the video before the failure. Players are still able to seek no matter where the frame metadata is stored, it's just a matter of if they have to waste a lot of bandwidth downloading all preceding frames first. > That's why I believe storing videos in a standard format like MKV would be more convenient for users. I don't really see the use case, do you just want to avoid the recording page because doesn't have a way to change the playback speed? that's easy to add. Or has it more to do with vendor lock-in?

Green-cattow commented 2025年03月11日 19:50:55 +01:00

I see your point, but my concern is more about handling large amounts of video efficiently.

Downloading video through the web interface is not always practical when I need to review long periods (e.g., two weeks or more). While having playback speed control on the web would help for quick incident reviews when I know the approximate time (and will be soo cool), the main issue is that large amounts of footage really difficult to watching on web interface and take a long time to download over the network.

In other surveillance systems, I can simply connect a drive, copy all the recordings, and watch them locally at high speeds (e.g., 16x in VLC). With this system, I have to copy raw .mdata files, convert them to MP4, and this process requires additional storage because the raw files are not deleted after conversion. That’s why I was asking about saving in a standard format like MKV or MP4 from the start – it would reduce the need for extra steps and storage overhead.

I see your point, but my concern is more about handling large amounts of video efficiently. Downloading video through the web interface is not always practical when I need to review long periods (e.g., two weeks or more). While having playback speed control on the web would help for quick incident reviews when I know the approximate time (and will be soo cool), the main issue is that large amounts of footage really difficult to watching on web interface and take a long time to download over the network. In other surveillance systems, I can simply connect a drive, copy all the recordings, and watch them locally at high speeds (e.g., 16x in VLC). With this system, I have to copy raw .mdata files, convert them to MP4, and this process requires additional storage because the raw files are not deleted after conversion. That’s why I was asking about saving in a standard format like MKV or MP4 from the start – it would reduce the need for extra steps and storage overhead.

Curid commented 2025年03月12日 19:06:48 +01:00

What if we mount the recordings as mp4 files in a virtual FUSE file system? You'd get the monitor name rather than ID and it'd be in the right timezone.

 recordings_vfs
 └── <YYYY-MM-DD>
 └── <MONITOR_NAME>
 ├── YYYY-MM-DD_hh-mm-ss_<MONITOR_NAME>.mp4
 └── YYYY-MM-DD_hh-mm-ss_<MONITOR_NAME>.mp4 

What if we mount the recordings as mp4 files in a virtual [FUSE](https://en.wikipedia.org/wiki/Filesystem_in_Userspace) file system? You'd get the monitor name rather than ID and it'd be in the right timezone. ``` recordings_vfs └── <YYYY-MM-DD> └── <MONITOR_NAME> ├── YYYY-MM-DD_hh-mm-ss_<MONITOR_NAME>.mp4 └── YYYY-MM-DD_hh-mm-ss_<MONITOR_NAME>.mp4 ```

Green-cattow commented 2025年03月13日 13:51:07 +01:00

i do not understand, how it can help 😅

i do not understand, how it can help 😅