It gets a bit messy. In order to capture an image, most image sensors are triggered. Some sensors will operate in "free-run" mode, but in reality something is

It gets a bit messy. In order to capture an image, most image sensors are triggered. Some sensors will operate in "free-run" mode, but in reality something is sending a capture signal to the camera. In sensors where you have very low level control over things, usually what that does is clear the pixels (dump the accumulated charge) and start exposing. Then, when the exposure is complete, the camera makes the data available for read-out (for a phone sensor analogue-digital conversion is likely done in circuitry on the sensor, not in the phone). That trigger is the important bit. Using triggering you can synchronise multiple cameras (e.g. the sensors in multi-camera phones are almost certainly co-triggered to avoid ghosting), illumination units, etc. In fact many camera chips can also be set to output flash signals when they're exposing, this eliminates latency in sending separate "capture" and "flash" signals. When I've deployed machine vision systems, often we would use an external system to trigger everything (e.g. a microcontroller). Interfacing hardware and software triggering is a nightmare. Then you've got whatever low level interface is actually communicating to the camera. On a phone, that's probably MIPI/CSI-2. Modern SoCs have dedicated (hardware) camera interfaces (the ISP) that are designed specifically to load images from camera sensors and do some minimal processing. You need kernel-level drivers for whatever your SoC is. These drivers will (in theory) let you set up arbitrary image sensors with whatever resolution/timing they require. But the key is you need two drivers: one to control the ISP and another to send commands to the camera sensor. A lot of the time (cough Broadcom) you only get a blob for the ISP and you almost never get full datasheets for image sensors without being a big customer. Rockchip have an open source driver for their ISP: http://opensource.rock-chips.com/wiki_Rockchip-isp1 http://opensource.rock-chips.com/wiki_Rockchip-isp1 See Rockchip again for an open-source example of an actual sensor driver. https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/i2c/imx219.c https://github.com/rockchip-linux/kernel/blob/release-4.4/dr... Want to make an educated guess why libcamera supports the [Rockchip] RK3399? They make it comparatively easy. In the end V4L acts as a mediator between this low level interface and other things which want to talk to the camera. Rockchip have provided what amounts to a plugin for V4L. Then on top of V4L you have libraries like OpenCV which give you nice interfaces like `imread` to capture images and do stuff with them. To answer your question you probably need to be more specific. The performance of what V4L does for a specific ISP/sensor combination very much depends on those underlying drivers. If you can afford it, a safe strategy is to leave the sensor in free-running mode in a separate thread that's dedicated to capturing images. Then in your application you pick off the most recent frame and do stuff with it in parallel. For a 30fps camera you therefore have 30ms or so to do your stuff before the next frame comes in.