Possible Reasons

  • Encoding Frames
  • Overloading the number of camera streams possible on your hardware
  • Camera is disconnecting and reconnecting

Encoding Frames

By default Shinobi's Monitor Settings window is set to not encode for H.264/H.265 based streams. However by changing the Video Codec from copy to anything else will result in encoding. Here are a few other features, when turned on, result in encoding.

  • JPEG API
  • Timelapse
  • Motion Detection
  • Object Detection

Just the act of FFmpeg creating frames for these outputs asks the CPU to rebuild frames. Depending on the Quality, Resolution, and Frame Rate (FPS or Frames Per Second) it can consume more or less CPU.

  • JPEG API is a last resort Stream Type and should only be used when your client machine (device used to view Shinobi) is not capable of opening any of the H.264 based Stream Types. JPEG API was created for the purpose of providing streams to iOS devices that could not support any of the offered stream methods, aside from Base64. However, in recent versions of iOS now support the HLS output from Shinobi.
  • Timelapse follows the same premise as JPEG API. The only real difference is that it saves the images to disk and creates frames on a lower interval.
  • Motion Detection should not have the Feed-In dimensions higher than 640 by 480. Motion Detection doesn't need very many frames per second to operate. Consider setting the FPS to 3 at Maximum. 2 is recommended and generally works well.
  • Object Detection should not have the Feed-In dimensions higher than 1280 by 720. Some detection plugins provided, such as the OpenALPR plugin, will rescale to this size before detection. However some, like TensorFlow, can take higher dimensions.

Solution : Please consider the recommendations above. If you don't need any one of these features then turn it off. If you do need them then there is no real way to stop the CPU consumption (yet with Shinobi, as of June 22, 2020).

Overloading the number of camera streams possible on your hardware

Generally overload occurs when encoding multiple cameras at once. Although Decoding is always still a factor. Even with being able to run 43 4MP Cameras on a Jetson Nano, no encoding, the CPU use rose to 45%. The cap is mostly in the kind of streams you are asking Shinobi to consume, as well as the configuration set for that consumption.

  • H.264 Streams, No Encoding : More Cameras
  • H.264 Streams, Some Encoding : Less Cameras
  • MJPEG Streams : Less Cameras, Is Always Encoding
  • H.265 Streams : Regardless of Encoding on Not Encoding, the real issue is whether or not your hardware support decoding it. If not, it will use the CPU to do it and that will consume a lot of CPU power.

Solution : Use H.264 Streams and don't encode frames. This will allow the most number of cameras to run at the same time. You can consider H.265 if your server can decode it with hardware acceleration. To view the stream in dashboard use the sub-stream from your camera.

Another Solution : Lower the bitrate coming from your camera. This option is usually only available to H.264 and H.265 streams and must be changed inside the camera's internal settings, Not in Shinobi.

Camera is disconnecting and reconnecting

This can be caused by the following

  • Incompatible camera configuration - Settings chosen in Shinobi do not work with the stream provided by your camera.
  • Inconsistent network connection between camera and server - Varying from wires needing replacement to interfering software installed.
  • Broken build of Shinobi - Builds are tested before pushing to public repositories but it may occur that a bug is present. Try updating to the latest, if the issue is not resolved please mention it in the forum or community chat.

Solution : There is no one solution for this problem. Unfortunately you will need to single what the problem is on your own or with the help of the Shinobi Community.