MIPI CSI-2 Bandwidth Calculation for Dual-Camera Designs

Start with the active image payload for each stream: width × height × frames per second × bits per pixel. Add the streams that share a link, then check the configured link and the host's capture and processing limits. The payload estimate alone cannot prove that a camera configuration will work.

This guide uses hypothetical, uncompressed image modes to explain the calculation. The frame rates, formats, and link configurations below are not specifications or measured results for a Camera Module Hub product.

Write down one mode for each stream

Before calculating, record the active width and height, frame rate, output format, and whether the streams must run simultaneously. For two different modes, calculate each separately.

“Dual 1080p” leaves several questions unanswered. Two 1920 × 1080 streams at 30 fps have a different data budget from one at 30 fps and another at 60 fps. RAW10 and YUV 4:2:2 also carry different amounts of image data.

Ask for the exact module revision and the mode table supported by the intended driver and host. Keep sensor output, transport format, and application output separate: an application receiving YUV does not establish that YUV was the format sent over the camera link.

Calculate active image payload

For a fixed, uncompressed mode, multiply:

Active payload in bit/s = width × height × fps × bits per pixel.

Divide by 1,000,000,000 to express the result in decimal Gbit/s. Divide bit/s by eight for byte/s; Gbit/s and GB/s are different units.

For a hypothetical 1920 × 1080 RAW10 stream at 30 fps:

• 1920 × 1080 = 2,073,600 active pixels per frame.
• 2,073,600 × 30 × 10 = 622,080,000 bit/s.
• One stream therefore carries 0.622080 Gbit/s of active image payload.
• Two identical streams carry 1.244160 Gbit/s in total.

The table compares three assumed formats at the same resolution and frame rate. It excludes transport overhead, additional metadata, and implementation-specific padding.

For 8-bit YUV 4:2:2, two pixels share chroma samples: two luma samples plus one sample of each chroma component make four bytes per pixel pair. That is an average of 16 bits per pixel. See the Linux packed YUV format documentation.

Compressed modes need a different estimate based on their documented output behavior. Do not apply this uncompressed table to a compressed stream without accounting for its actual data rate and variation.

Check which streams share a link

Draw the path from each sensor to the host before comparing capacities. Two sensors might use separate physical links, or their data might be combined by another device. A dual-lens label does not identify that topology.

For independent links, check each link against its own stream and then check the host's combined workload. For a shared link, include every stream carried over that connection. Confirm the receiver's support for the proposed stream routing and identifiers; a combined payload calculation does not establish that the host can separate and capture the images.

If both streams in the RAW10 example share a link, their combined active payload is 1.244160 Gbit/s. Dividing that by two lanes gives 0.622080 Gbit/s per lane as an idealized payload share. It does not establish that a two-lane implementation is sufficient.

Compare with the configured physical link

Confirm the physical layer, active lane count, configured rate, and the rates supported by both endpoints. The MIPI CSI-2 overview describes multiple physical-layer options; a D-PHY calculation must not be applied unchanged to C-PHY.

For the D-PHY relationship described in the Linux transmitter and receiver documentation, the nominal aggregate bit rate is twice the link frequency multiplied by the data-lane count. Thus, a hypothetical link frequency of 400 MHz across two data lanes corresponds to 1.6 Gbit/s before transport overhead and other implementation constraints.

That number is a nominal comparison point, not a demonstrated capture rate. Check packet and metadata overhead, transfer timing, supported operating rates, and any bridge or receiver limitations. An average payload below a nominal link rate does not prove that each line can be transferred within its required time window.

Request the mode's documented link configuration and timing. Do not assume that every blanking interval is transmitted as additional image pixels, or that a universal percentage covers every implementation. Confirm the actual packet behavior and leave margin based on the system being evaluated.

Budget memory and processing separately

The host may store a pixel differently from the camera's transport representation. Linux documents both packed RAW10, with four samples in five bytes, and RAW10 stored in 16-bit words. These are examples of memory formats, not evidence of a particular module's wire format.

For memory planning, use the negotiated buffer layout, including row stride, plane sizes, and padding. Then account for the reads, writes, and conversions in the actual pipeline. Multiplying the transport payload by a guessed factor is not a complete memory-bandwidth budget.

Receiver, capture engine, ISP, and application processing can impose separate limits. NVIDIA's DRIVE OS bandwidth guide illustrates platform-specific capture and processing checks. Its hardware figures and margins apply to that documented platform, not to every embedded host.

Validate the complete operating mode

After the estimates, verify the proposed configuration on the intended hardware and software. Record:

• Module, host-board, driver, and operating-system versions.
• Per-stream resolution, frame rate, format, and link settings.
• Whether all required streams remain active together.
• Delivered frames, drops or errors, and sustained operation under the intended processing load.

Define the test duration and acceptance criteria for your project. A short preview or a successful single-stream capture does not establish sustained dual-stream performance. Matching frame rates also do not prove synchronized exposure; see synchronization, calibration, and depth output explained when those requirements matter.

Prepare a useful product inquiry

Include your host and software versions, required modes for each stream, simultaneous-stream requirement, known port or lane constraints, and the output your application needs. Mark unknown fields as questions rather than assumptions.

Use the MIPI integration checklist to cover the remaining electrical, software, and mechanical checks. For our MIPI dual-lens module, use the confirmed specifications on its product page and ask about requirements not listed there. You can send a project inquiry with your proposed modes and host details before relying on a configuration in your design.