Why your camera's link bandwidth sets a hard latency floor

A camera link moves a fixed number of bits per second. A full-resolution raw frame is tens of millions of them. When the frames you request need more bandwidth than the link provides, they queue up between camera and host, and measured latency climbs into the hundreds of milliseconds even though every component works. This page gives you the arithmetic that predicts it: frame size from pixel format, wire time from link rate, a realistic frame-rate ceiling, and the fixes ranked by cost. If you stream large color frames and latency sits at five or ten times your frame period, work through the numbers here before you touch any code.

Why does a link set a latency floor at all?

Every frame must cross the wire before your code can use it. At 4000 × 3000 pixels and 3 bytes per pixel, one frame is 36,000,000 bytes, which is 288,000,000 bits. Even a flawless 2.5 Gbps link spends about 115 ms moving it.

That wire time sits underneath exposure, sensor readout and processing, and nothing in your host code removes it. The levers are the three factors in the formula:

Two consequences matter in practice. Wire time adds to the rest of the pipeline, so total latency is transfer plus readout plus processing, not the largest of the three. It also scales with pixel count: doubling each image axis at the same pixel format quadruples the floor. The same math covers every raw-streaming interface — GigE, USB3, 10GigE, CoaXPress — because only the link rate changes between them.

How many bytes does one camera frame put on the wire?

Multiply width by height by bytes per pixel. The pixel format decides more than anything else: at 4000 × 3000, packed RGB888 ships 36 MB per frame, NV12 ships 18 MB, and 8-bit mono or raw Bayer ships 12 MB.

NV12 stores 8-bit luma at full resolution and chroma at half resolution in width and height, so 4 pixels cost 6 bytes; the 8-bit YUV format reference used by Windows video components lists it as the preferred 4:2:0 form. Use it for display, recording and most classifier inputs. For color-critical metrology, remember that chroma detail is quartered. Raw Bayer keeps every pixel's single sample and debayers on the host GPU instead: 1.0 bytes per pixel with full luma resolution.

Changing the format is rarely a single switch. Linked camera attributes move with it — packet size, bandwidth reserve, fps caps — as changing pixel format halves your frame rate: check linked attributes shows, and RGB camera frame rate limits: pixel format and exposure traces the same coupling through exposure.

What happens when you ask for more frames per second than the link can carry?

The camera produces frames at the requested rate while the link drains them at its own. The queue between them grows until a buffer cap stops it: at 20 fps requested against 8.7 fps carried, latency builds about 1.3 seconds for every second of running.

Worked through for 4000 × 3000 RGB888 on 2.5 Gbps at a requested 20 fps:

• Carried rate: 2,500,000,000 ÷ 288,000,000 = 8.7 fps, so one frame drains every 115 ms.
• Excess production: 20 − 8.7 = 11.3 frames per second pile up.
• The oldest frame's age grows by 11.3 × 115 ms ≈ 1.3 s per second until the queue hits its cap.
• A six-deep queue pins the delay near 6 × 115 ms ≈ 690 ms, which is exactly the stuck-around-700-ms symptom on an over-driven full-resolution color stream.

Pull-style pipelines help as well: each stage waits for work rather than pushing frames downstream, so nothing buffers that does not have to. When the slow stage is host processing rather than the link, the same arithmetic applies — see acquisition faster than processing: fix the frame rate gap. Buffers do buy short bursts, and camera burst capture faster than link bandwidth: use the buffer covers when that trade is worth it, but the sustained rate stays bounded.

How many frames per second can your link really carry?

Budget 80 percent of the nominal link rate for image payload: a 2.5 Gbps link then sustains about 14 fps of 4000 × 3000 NV12 or about 7 fps of RGB888, so set the requested rate below those numbers, not at the theoretical ceiling.

The derivation: 2.5 Gbps × 0.8 gives 2.0 Gbps of payload; NV12 at 144 Mbit per frame gives 2,000,000,000 ÷ 144,000,000 = 13.9 fps; RGB888 at 288 Mbit gives 6.9 fps. The missing 20 percent absorbs packet headers, inter-packet gaps and on-device formatting. Real links land between 75 and 85 percent payload; plan at 80 and confirm with a measurement.

Ceilings at 4000 × 3000 with the payload budget at 80 percent of nominal:

USB3 delivers about 3.2 Gbps of payload in practice, which places it between the 2.5GBASE-T and 5GBASE-T rows: roughly 22 fps of NV12 or 11 of RGB888 at this resolution. The same method works at any resolution and interface — USB2 bandwidth and 5MP frame rate: size the data rate first runs the identical calculation for a smaller camera.

How much latency is left once the link is no longer the bottleneck?

Below the ceiling you still pay wire time, sensor readout and ISP time. In one measured full-resolution streaming set-up, transfer ran about 63 ms against a theoretical 57.6 ms, with roughly 27 ms of on-camera processing, for near 100 ms end to end at 2 fps.

Each term for 4000 × 3000 NV12 on a 2.5 Gbps link at 2 fps:

• Wire: 18,000,000 × 8 ÷ 2,500,000,000 = 57.6 ms theoretical. Achieved throughput sits a few percent under nominal, so plan for 60-65 ms.
• Readout: a rolling-shutter sensor of this size reads out over roughly one frame period at its top rate, near 30 ms on a 30 fps part.
• ISP: debayering, white balance and distortion correction on the camera add a similar tens of milliseconds at 12 MP.

A perfectly provisioned link therefore still carries a floor of two to three frame periods at full resolution. In trigger mode the frame rate is bounded by exposure plus readout before bandwidth even enters — maximum frame rate on a hardware trigger: exposure plus readout time. Measure rather than model: measuring camera latency glass to glass the right way and camera frame rate measurement from timestamped frames give the methods.

Which link speed clears your frame rate?

Multiply it out and buy the link whose payload budget exceeds frame bits × fps: 4000 × 3000 RGB888 at 20 fps needs 288 Mbit × 20 = 5.76 Gbps, so 10GigE is the honest choice, while NV12 needs 2.88 Gbps and clears 5GBASE-T.

Start from the area scan cameras range and filter by interface; the catalog spans GigE, USB3, 10GigE and CoaXPress.

For full-rate color at high resolution, 10GigE is the match. The MV-CH250-25TC-F-NF is a 25 MP 10GigE area scan camera with an APS-H sensor, F-mount and global shutter.

A 25 MP frame in NV12 is 300 Mbit, so a 10GigE payload budget of 8 Gbps carries about 27 fps of full-resolution color before any margin.

USB3 covers the middle ground. The LS-CMR-0166 is a 12 MP USB3 area scan camera with 4000 × 3000 resolution, 30 fps and a 1/1.7" rolling-shutter sensor.

On USB3's practical 3.2 Gbps, this resolution streams at about 22 fps in NV12 and about 11 in RGB888 — the fps on a spec sheet assumes the sensor, not the wire.

GigE rewards small frames. The MV-CU020-90GC is a 2.5 MP GigE color camera with a 1/1.7" sensor, global shutter and C-mount.

A 2.5 MP frame at 8-bit raw Bayer is 20 Mbit, so a 0.8 Gbps payload carries about 40 fps of full frames; the same pixels in packed RGB888 fall to about 13 fps.

Check the physical layer too: a link that negotiates down hides inside otherwise sane math, and GigE camera packet size error when your link drops below gigabit is what that looks like. For longer runs at multi-gigabit rates, 5GBASE-T camera interface: bandwidth, cables and distance covers the cable and distance limits, and certified camera data cables beat office patch leads.

How do you stop several cameras from sharing one bottleneck?

Give each camera its own network path: a controller with 5+ LAN ports lets you pin one camera per port, so one stream never queues behind another on a shared hop.

A single stream will not split across aggregated ports. Bonding two 1 Gbps links does not rescue a saturated hop; it just moves the queue into a switch. Budget per interface instead: the sum of frame bits × fps behind each port stays under that port's payload budget. PoE camera ports remove separate power runs at the bench and in the cell.

The MV-VC5525-256G70-NN vision controller pairs a 12th-generation Intel Core i5 and 32 GB of memory with 5+ LAN ports, PoE camera ports and 8 built-in light channels.

Plan the cell around port counts: the vision controllers range filters by LAN ports and PoE, so pick the port count before you pick the processor.

When is a faster link the wrong fix?

Shrink the payload before buying bandwidth: cropping 4000 × 3000 RGB888 to a 2000 × 1500 ROI cuts the frame to 9 MB and the wire time from 115 ms to 28.8 ms, and 20 fps then fits the same 2.5 Gbps link.

The check: 72 Mbit per cropped frame × 20 fps = 1.44 Gbps of payload against a 2.0 Gbps budget, so the original link now runs the job at 72 percent of its payload budget.

Ordered by cost, the levers are:

1. Crop to the region of interest — the example above buys a 4× cut for nothing.
2. Go mono: mono8 at 1.0 bytes per pixel is a third of packed RGB.
3. Bin or downscale on the camera: 2 × 2 binning quarters the payload.
4. Process on the camera: detection or tracking on-device ships decisions, which are bytes, not frames.
5. Encode for human review: an order of magnitude less bandwidth, but read encoded image pipeline latency: find hidden frame buffering first — encoder delay and hidden queues can eat the savings.

For a latency-critical loop that feeds a large offboard model, the best payload is raw Bayer at 1.0 bytes per pixel, debayered on the host GPU: full spatial resolution, a third of the RGB888 wire cost, and no on-camera ISP stage in the path.

Decision by case:

• Full-resolution color at 20 fps or more on the wire: 10GigE; 5GBASE-T only if NV12's quartered chroma is acceptable.
• Full-resolution color up to about 14 fps: 2.5GBASE-T or USB3 with NV12, camera set below the 80 percent planning rate.
• Mono or ROI inspection: GigE with mono8 or a cropped region.
• Several cameras: one LAN port per camera, budgeted per interface.
• Latency-critical sorting or robot guidance with a heavy offboard model: raw Bayer on the wire, GPU debayer, one-deep drop queue, glass-to-glass measurement on record.

What do you check before ordering the camera and the link?

Run three numbers before you order: frame bits from width × height × bytes per pixel × 8, payload from frame bits × fps × cameras on that link, and keep link rate × 0.8 at least 20 percent above payload on a latency-critical line.

Worked check for the running example: 4000 × 3000 NV12 at 11 fps is 144 Mbit × 11 = 1.58 Gbps of payload against a 2.0 Gbps budget, a 26 percent margin, so it holds; the same link at 14 fps sits at 2.02 Gbps and is already over budget.

Before the order goes in:

• Budget with the delivered pixel format, not the sensor's nominal bit depth: 12-bit data unpacked to 16-bit words costs 2.0 bytes per pixel on the wire.
• Requested fps at or below the 80 percent planning rate for that link and format.
• Sum of every camera's payload per shared interface.
• Negotiated link speed on both ends: a 100 Mbit fallback is 25× slower than a 2.5 Gbps link and reads as a mysterious latency bug.
• Host queue capped at one frame with drop behavior.
• Timestamped latency measured across a full shift, watching the tail, not the best frame.

Size the camera and the link together in the camera finder or at the camera step of the configurator. More timing fixes from the bench sit on the cameras topic page, and if you want the numbers checked against a specific resolution, format and frame rate, contact the applications team.