Why does the Picamera not suffer with an interrupt from the CPU and is able to capture video successfully? The Pi doesn't use a real time operating system. So there must be lots of processes running at the same time alongside your video capture program. When you capture images in sequence, it seems natural that you loose data every time the CPU switches its attention to other processes. But the picam doesn't seem to suffer from the issue.

  • You can cast your eyes over the source code here. – goobering Mar 31 '16 at 10:15

Raspberry pi doesn't use real time operating system.

Neither do any of the devices you own with cameras except maybe a dedicated camera itself, if it uses much of an operating system at all. Genuine real time operating systems tend to be I think very minimal and confined to specialized purposes.

Windows, OSX, IOS, and Android use exactly the same (or relatively similar) non-realtime, multi-tasking concepts and strategies as the linux kernel.

"Non realtime" does not mean at random the operating system grabs a piece of hardware, stops it doing whatever it is doing, and asks it to do something else. It might do that sometimes, if the hardware allows for it, which I would guess most cameras do not allow for excluding a hard power reset, which itself may or may not be something the OS could trigger.

Hardware is hardware because it is actual physical stuff including independent microcontrollers, processors, and memory1 that is capable of performing some function on its own (although it may require some assistance/cooperation from other pieces of hardware, including the CPU running OS software), to complete tasks on a given level.

When you take a picture, userland software running on top of the OS passes a request to the OS to ask the camera to take a picture and the OS does so. "Non-realtime" latency may come into affect at that point -- e.g., a number of milliseconds may be introduced by the OS, delaying the request by that amount -- after that the OS keeps on going with something else, the camera takes the picture, and when it is finished, it signals the OS via an interrupt (probably; this is actually not necessary in this case I think but still, probably) and the OS juggles that along with the other things it is doing, meaning more latency may be introduced before the software actually gets the data from the camera. In the case of video streams, the device itself, and the userland software, and probably the kernel driver, will be buffering enough to prevent turning this into an insurmountable problem, although if you tax a pi with enough other stuff you will start to notice quirks in the video stream (which is not to say this is where all such quirks come from).

1. Sometimes hardware also has direct access to system memory without having to go through the CPU (and OS) as well. I believe video memory works this way, and the camera may also.


With the PiCam , the GPU does lots of "heavy lifting" in terms of camera support - including realtime h.264 encoding @ full HD.

This alleviates many problems seen with USB webcams which are solely managed by the Linux running on the ARM processor(s).

Linux and software on top on it run better with the PiCam thanks to the work done by the GPU.

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.