3

I'm recording video with python picamera module (See above code).

import picamera
video_length=180
with picamera.PiCamera() as camera:
    camera.start_recording("video.h264")
    camera.wait_recording(video_length)
    camera.stop_recording()

This script (named make_video.py) results in multiple PIDs being executed with the same name. (As shown in htop output):

 PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command          
 1412 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.03 python make_video.py
 1413 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1414 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1415 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1417 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1418 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1419 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.00 python make_video.py
 1420 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.31 python make_video.py
 1411 pi        20   0 84224 11744  6060 S  0.0  1.3  0:00.87 python make_video.py

Is this a normal behavior? Should I attempt to avoid it?

2

Yes, this is perfectly normal. The camera's operation involves a whole pile of background threads which are what those other PIDs represent (if you tweak htop's configuration to "Hide userland threads" you'll see them disappear). In fact, those threads spawn as soon as you initialize the camera. Try the following:

  1. open a couple of console windows side by side
  2. in one of the windows start htop (with "Hide userland threads" disabled, the default)
  3. in the other start an interactive python session, "import picamera", then initialize the camera with "camera = picamera.PiCamera()"

As soon as the camera's initialized you should see those threads appear. In fact they're not spawned by the picamera library itself; they're spawned by the MMAL layer and are used for things like control callbacks. Why so many threads? Well, the camera actually has quite a lot of components that spawn by default (the camera itself, a camera info component, a splitter for the video port, a null-sink for the preview port), and each component has at least one thread for its control callbacks.

If you start recording a video you'll see another thread appear. That's the thread that gets passed output callbacks from the firmware (when you stop recording, that thread will disappear and the rest will remain).

As to why they're all marked "S" (interruptible sleep), that's because most of the threads are just sat there waiting to be woken with a message from the camera firmware. Most of the time (hopefully all the time!) there's no errors so the threads just stay asleep. If you're recording video, the output thread will probably blink into "R" (running) occasionally as it transfers data to the specified output, but otherwise most'll remain in S.

Anyway, yes it's perfectly normal for the camera. If you run "raspivid -t 0 -op 128" (which simply brings up the preview transparently until you hit Ctrl+C) you'll see the same thing for raspivid: a whole bunch of PIDs under it with the same name which represent the background threads for the camera.

2

No, this is not normal. That S column suggests that your script fails to terminate properly and instead hangs up in "interruptible sleep" forever (or at least for a long time).

You should debug your code to figure out which method ends up sleeping. Most probably it's either stop_recording or close (which is implicitly called at the end of with block). I would begin by adding a print("exiting") statement at the end of your script.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.