High frame rate camera data rate: plan 2000 fps recording

At 2000 fps the camera decision stops being about resolution and starts being about plumbing. Five minutes of 2000 fps video is a continuous stream of hundreds of megabytes per second. The interface, the recorder and the drive decide whether the run survives long before pixel count matters. This guide works the numbers for a 2000 fps, 300 s run: the rate formula, a 640 × 480 Mono8 example with the arithmetic shown, the ceiling of every machine-vision interface, and the parts decision for each case.

The data rate formula

Two limits set the frame rate you actually record. One is the sensor's readout speed at your region of interest. The other is the bandwidth your link can carry, and that limit is arithmetic:

Bytes per pixel follows the pixel format: Mono8 is 1, packed Mono10 is 1.25, packed Mono12 is 1.5, Mono16 is 2 and RGB8 is 3. The recorded frame rate is the smaller of the two limits: fps = min(readout limit at your ROI, usable bandwidth ÷ bytes per frame).

A sensor that digitizes 12 bits can still output 8-bit frames — the bit depth and pixel format distinction explains why the settings are separate. Work in decimal units, 1 MB = 1,000,000 bytes, so the stream numbers line up with interface line rates.

A worked example: 640 × 480 Mono8 at 2000 fps

Resolution is not the goal in this kind of study, so start from a small frame and see what it costs:

• 640 × 480 = 307,200 pixels, one byte each in Mono8 → 307,200 bytes per frame
• 307,200 bytes × 2,000 frames/s = 614,400,000 bytes/s → 614 MB/s
• 614.4 MB/s × 300 s = 184,320 MB → 184 GB per run
• 2,000 fps × 300 s = 600,000 frames

Two consequences follow immediately. One 10GbE port moves 1,250 MB/s of line rate, so the example stream rides a single port at 49% utilization, or 52% of its usable 1,180 MB/s. And 184 GB is decimal: a recorder that reports binary units will call the same run 172 GiB. Keep about 370 GB spare on the recorder volume so two runs fit with margin.

What each interface can carry

Interface line rates come from the standard; the usable share is what survives protocol overhead. Tune the host before you measure. Enable jumbo frames (9,000-byte MTU) end to end and raise the NIC's receive buffers, or a default-tuned 1 GbE link delivers closer to 90 MB/s than its 125 MB/s line rate. The ceilings below assume the 307,200-byte frame of the worked example:

Read the GigE row backwards and it sizes the largest frame 2000 fps allows on 1 GbE: 110 MB/s ÷ 2,000 fps = 55,000 bytes per frame, about 256 × 214 pixels. Multi-link interfaces sum their links: two 10GbE ports carry about 2,360 MB/s usable, and four CXP-12 links about 5,000 MB/s. The GigE Vision frame rate math gets its own page, as does the USB hub bandwidth trap if your camera hangs off a hub.

The frame grabber range starts at the accessories finder. For the example stream the decision is a 10GbE camera into a dual-port 10GigE card — one port runs the stream, the second stays open for a second camera or the control network:

A stream under about 110 MB/s runs on ordinary GigE hardware with a port to spare — the small-ROI case later in this page lands exactly there:

Rated fps versus sustained fps

The data sheet maximum is a full-frame, free-run number under generous settings. Three things pull the sustained rate down.

Exposure: the frame period at 2000 fps is 1 ÷ 2,000 = 500 µs, so plan 400–450 µs exposures and light the scene for them. Halving exposure time costs one stop, so f/2.8 becomes f/2.0 or the illumination doubles. Prefer a global shutter; a rolling shutter at this rate smears row timing across fast motion.

Triggering: externally triggered capture often records below the free-run rating, and this triggered frame rate walkthrough works through the common causes. Pixel format: RGB or 16-bit output multiplies the stream, as the pixel format rate limits page shows. And if the rate starts high then collapses mid-run, exposure creep and link saturation are the usual suspects — the fps collapse walkthrough names them in order.

A camera with on-board memory can also burst faster than the link for short windows, which the burst capture guide covers — but a 300 s continuous run has no buffer large enough. The link must carry the average for the whole run.

Storage for a 300 s run

A stream of 614 MB/s arriving for 300 s needs a drive that writes 614 MB/s for 300 s. A SATA SSD sustains about 500 MB/s sequential, which is under the stream — it cannot take this job alone. Use NVMe rated for at least 1.2 × your stream rate, about 740 MB/s for the example. Gen3 and Gen4 drives typically sustain 1,500–2,000 MB/s sequential, so the margin is easy to meet. An 8 GB RAM ring buffer covers 8,000 MB ÷ 614 MB/s ≈ 13 s of stream while the drive recovers from a pause, which absorbs every normal filesystem hiccup.

Recording software drops frames in its own ways; if your acquisition runs under LabVIEW, this LabVIEW IMAQ recording walkthrough covers the usual software-side causes. For the recorder design end to end — buffer sizing, file formats, drop-free capture — the high speed recording guide is the companion page.

Cut the stream, not the experiment

Rate scales linearly with width, height and bytes per pixel, so every cut is a direct saving. A 256 × 200 ROI in Mono8 costs 51,200 bytes × 2,000 fps = 102.4 MB/s — just under the 110 MB/s a tuned 1 GbE link carries, which turns the whole problem into standard GigE hardware. Dropping packed 12-bit output to 8-bit cuts the stream by a third, 1.5 to 1.0 bytes per pixel, whenever the extra bits carry no measurement.

Size the ROI from the feature instead of from habit — the field of view and the smallest detail you must resolve set the pixel count:

Choosing the parts: the decision per case

Compute your stream once and the hardware picks itself:

• Under 110 MB/s (about 55,000 pixels at 2000 fps Mono8): a standard GigE camera from the area scan cameras range on a PoE NIC. The 256 × 200 case above lands here.
• 110–1,150 MB/s (the 640 × 480 example at 614 MB/s): a 10GbE camera, one port per stream.
• 1,150–4,500 MB/s (dense ROI, deep pixel formats): multi-port 10GbE or multi-link CoaXPress. The two parts below cover that band — the quad-port copper NIC for spread streams, the octo CXP-6 frame grabber where the camera speaks CoaXPress.

On the camera itself, shortlist the high-speed series in the camera finder, require a global shutter, and read the two limits against each other. The camera's frame-rate table at your ROI is the readout half of the minimum, and the bandwidth formula is the other half. The system configurator walks camera, interface and recorder in one pass.

Checks before you order

1. Fix the pixel format (packed or unpacked) and compute bytes per frame: width × height × bytes per pixel.
2. Take the camera's frame-rate figure at your ROI and compare it with usable bandwidth ÷ bytes per frame; record the smaller number as your fps.
3. Multiply fps by bytes per frame by run length for the gigabyte figure, and add 20% for a second run.
4. Pick an NVMe drive whose sustained sequential write rating clears 1.2 × the stream rate.
5. Tune the host: jumbo frames end to end, larger receive buffers, and no other traffic on the capture NIC.
6. Dry-run 60 s and count frames — 120,000 expected at 2000 fps — so any shortfall names the bottleneck before the real experiment does.

Send the frame size, pixel format and run length through the extras step of the configurator or the contact page, and the sized parts list comes back with the numbers attached. More rate, trigger and interface guides sit under the cameras topic.