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 .
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.
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.
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.