Save Storage Space with Compression after Videos are Recorded
Shinobi can automatically compress videos once they are finished recording.
How to enable Automatic Compression
- Open the Monitor Settings for the Monitor that will compress each recording it creates.
- Enable Compress Completed Videos in your Identity section.
- Press Save.
How to manually Compress
- Open the Videos tab, Select a Monitor with Videos
- Open the option dropdown at the very right side of each video row. Select Compress.
- Confirm the Compression.
Warning : Don't use with Continuous Recording
Your server may not be able to process compressions faster than it creates the video. This is depending on the power of your hardware.
Doing this requires a powerful CPU, you must allow a large amount of time to allow compression. The rate in which videos are added to the database can't be faster than the rate for compression.
Contiunous Recording is when the Mode of the Monitor is set to Record.
What happens to the original recorded video?
The original is placed in your FileBin. You will have a shorter period of time before these files are cycled, assuming files are frequently placed in it.
FileBinis a miscellaneous file listing where a variety of processes output files to, including the Time-lapse Frames video builder.
What is this?
Compression is making a file smaller and, in this case, expecting comparable quality to the original.
Shinobi performs best with H.264 streams at present time. However it uses a lot of storage space. One workaround for this is to use Automatic Compression. Making the file smaller after its already been made.
This compression uses VP9, so our resulted files are webm format.
Why not use H.265 or VP9 from the live feed?
H.265 requires specific hardware to do this effectively with reasonable performance. Due to complication with early adoption of H.265 in the industry we don't see many devices supporting it, that includes machines that can be used as Shinobi servers.
When attempting H.265 encoding on hardware that doesn't have the feature set to encode and/or decode. The task is given to the CPU, which is less effective and uses a lot more resources and could even result in poor performance. This is the same problem with VP9.
Our remedy is to run a process after the video has settled in the database at a lighter pace. This works well for machines that do the transcoding on CPU.