Overview Of Threads In Motion

Motion is a complex program with many features. One of the difficult things to understand are the many threads that runs when you start Motion. Here is a short overview.

• Main Thread. When you start Motion the main thread reads the config file and starts all the child threads. Once this is done the main thread sleeps waiting for the children to stop.

• Control Thread. This thread runs the http control interface. When you connect to the Motion control port this is the thread you communicate with. When you read and set option value the control thread simply reads and writes to the data structures that the camera threads use.

• Camera Threads. For each camera a camera thread is started. The camera threads take care of all the capturing from cameras, motion detection, saving pictures, making and saving movies, accepting connections to the webcam and sending pictures to the mjpeg clients etc etc. If the camera is a netcam the camera thread has a helper thread. See next. The camera thread asks the netcam thread for the next available picture frame.

• Netcam Threads. If a camera is a Netcam this special thread gets created. The normal mode of operation for Motion is that the camera thread captures a picture frame from the video4linux driver when it decides that it is time to do so. This does not work with Netcams that supplies an mjpeg stream. Mjpeg is a server push type connection. It is the network camera that sets the pace. The Motion Netcam Thread continuously picks up the pictures in the mjpeg stream and stores the latest picture in a buffer. Two things can now happen.
  1. Motion camera thread is faster than the Netcam: The camera thread will ask the netcam thread for a picture. If a new picture has not arrived since last time the camera thread asked the camera thread will wait until the netcam thread has received the next picture from the camera.
  2. Network camera is faster than what Motion needs: The network camera thread keeps on receiving picture frames at the pace set by the network camera. When a new picture is received the old picture is thrown away. When the camera thread asks for a picture, it gets the last picture that arrived.
  • With jpeg type netcams the netcam thread will fetch a new image right after the camera has picked up the previously fetched picture frame and then waits for the camera loop to pick up the new image. So here the camera thread sets the pace.
  • For both mjpeg and jpeg type network cameras the camera loop will wait for a delayed network camera for 0.5 second. Then it gives up and uses the previous image instead. After 30 seconds in this mode it shows a grey image with an error message.

When Motion executes an external program it is the camera thread that forks into an additional child process. This fork inherits all open files and data structures. The first thing the fork does is close all possible file descriptors and detach itself completely from Motion replacing itself with a shell that executes the external program.

Example

Motion is started. It has a motion.conf and 3 thread config files for one USB camera, one capture card and one network camera. These are the threads that are started.

• Main thread
• Camera 1 thread (USB cam)
• Camera 2 thread (bttv driver cam)
• Camera 3 thread (netcam)
• Camera 3 network helper thread (netcam)
• Control thread (http control)

-- KennethLavrsen - 17 May 2005