Embedded vision box: why sustained recording FPS drops and the fix

Your grab benchmark holds a clean 60 FPS from both GMSL cameras, and the same two streams sink to 18-19 FPS the moment recording starts. That pattern points away from the cameras and the capture link, and straight at the compute budget of the embedded box. This guide gives you the sequence that separates a throttled board from a genuine capacity limit: read the power profile with nvpmodel, rule out storage and single-stream faults with four short tests, set the MAXN profile, pin the clocks with jetson_clocks, and re-run the sustained test. The worked example computes the pixel budget for two 1920 × 1200 streams at 60 FPS, so you know what the encoder must sustain before you blame anything.

The pattern: grab tests pass, sustained recording sinks

Write down the signature before changing anything:

• Grab-only: both cameras deliver essentially 60 FPS, with even timestamps and no dropped frames.
• Sustained recording with H.264 GPU encoding: both streams start near 60 FPS, then settle at 18-19 FPS per camera and stay there.
• Depth, live preview and preview saving are disabled, so no optional consumer is hiding in the numbers.

A grab test exercises only the delivery path: sensor, GMSL link, capture driver and memory. Recording adds the stages that consume compute — image processing, H.264 encoding and the disk write. That is why the two numbers disagree. A grab benchmark can also run partly out of buffer, as camera burst capture faster than link bandwidth explains, so it measures delivery rather than steady-state processing. When acquisition outruns processing anywhere in a vision system, frames queue and then drop; the host-side version of that imbalance is covered in acquisition faster than processing: fix the frame rate gap.

Read the power profile first

On the box in this failure mode, nvpmodel -q reports the 25 W profile as mode 3, and that one line explains the collapse. A power profile caps total board power, and under sustained load the clock governor pulls CPU, GPU and encoder clocks down until consumption fits the cap. Short grab bursts fit under it; a continuous two-stream encode does not, so the encode rate settles at whatever the capped clocks sustain.

MAXN is the opposite setting: the unconstrained profile on this module class, which enables every core at its maximum clock frequency with no fixed cap. The module vendor's guidance for exactly this symptom is to enable MAXN and run jetson_clocks, and it confirms that 18-19 FPS sustained is the expected behavior under the 25 W profile.

Run nvpmodel -q now and write the mode number next to every benchmark result. A frame rate quoted without the power profile it was measured under is not a repeatable number.

Rule out storage, streams and links in four short tests

Power throttling is the likely cause when the pattern matches, but other faults look similar, and each has a fast test. Run them in this order:

1. Storage write rate. Record a 30-second clip to a RAM-backed path and the same clip to the normal disk. A 30-second clip at 8 bit per pixel produces about 8.3 GB (2 × 2,304,000 px × 8 bit × 60 FPS × 30 s = 66.4 Gbit), well inside the 15 GiB of RAM this box exposes. If the frame rate recovers in RAM, the storage chain was the cap.
2. One stream alone. Record a single camera with encoding on. If one stream holds 60 FPS and two streams collapse, every per-stage pipeline is sound and the aggregate budget is the limit — the power-mode signature again.
3. Exposure-driven caps. On some cameras a long exposure lowers the achievable frame rate by itself, as depth camera frame rate drops: exposure settings cap the FPS explains. That fault caps grab tests too, so it cannot explain a 60 FPS grab beside an 18 FPS recording.
4. Link faults. A failing GMSL link or capture card produces torn frames, sporadic dropouts or a camera that disappears — the signatures covered in GMSL camera not detected: capture card power and cabling. A clean, steady 18-19 FPS on both streams is not a link fault.

Four tests, ten minutes, and the cause is either the power profile or a genuine capacity limit.

The fix: set MAXN and pin the clocks

1. Read the current profile with nvpmodel -q and note the mode number.
2. Switch the profile to MAXN through nvpmodel, which lists the module's profiles by number; select the MAXN entry and confirm with nvpmodel -q.
3. Pin the clocks by running jetson_clocks. Locked clocks stop the governor scaling down mid-run, and they make consecutive benchmark runs comparable.
4. Re-run the same sustained recording: same resolution, same clip length, same disk.
5. Watch clock and temperature readouts with the board's system monitor while it runs, and record both numbers with the result.

When encoder throughput was the cap, sustained recording returns to roughly the grab rate: 60 FPS on both streams instead of 18-19.

Worked example: two 1920 × 1200 streams at 60 FPS on a 25 W profile

Inputs. Two cameras recording at once; 1920 × 1200 px per frame as set in the capture application; 60 FPS per camera as the target; 18-19 FPS per camera measured during sustained recording; grab-only at 60 FPS per camera; nvpmodel -q reporting the 25 W profile, mode 3. Every input comes from the failing rig itself, none from a datasheet.

Rule in words. Sustained pixel throughput in pixels per second equals streams × width × height × frame rate. Raw ingest in bits per second equals pixel throughput × bits per pixel.

Result. The rig asks the encoder for about 276 Mpx/s — 2.21 Gbit/s of raw pixels at 8 bit per pixel, twice that at 16 bit — and sustained about 85 Mpx/s (using 18.5 FPS, the midpoint of the measured 18-19), 31% of the target, while the grab test passed at 100%.

Decision. Grab at full rate with sustained recording below about half of target is the compute-budget signature: set MAXN, pin the clocks, and re-run. If sustained recording then holds 60 FPS on both streams, the profile was the whole fault. If it still sits near a third, the module's H.264 encoder lacks headroom for 276 Mpx/s and no setting will create it — record at 30 FPS, which halves the budget to about 138 Mpx/s, reduce the resolution, or move the job to a controller built for the load.

Multi-stream budgets compound per camera; multi-camera 3D processing performance: plan throughput plans that math on the host side, and the guide on sizing embedded vision hardware for 60 fps RGB analysis runs the same budget for a 60 FPS analysis load.

When MAXN is not enough

If the profile was already unconstrained, or MAXN with pinned clocks still misses the target, work down this list:

• Encoder headroom. Hardware H.264 throughput is fixed per module generation; no software setting adds more. Test 30 FPS first — it halves the pixel budget and is usually enough for review and training footage.
• Depth on top of recording. Depth computation shares the GPU with the encoder. With depth enabled alongside two encoded streams, the recording budget shrinks again, so record with depth off unless the application needs both at once.
• Sustained storage rate. The disk must write the encoded stream for the whole clip with margin. The RAM-backed test above separates a storage cap from a compute cap in minutes.
• A PC-based stack instead. Desktop recording software hits the same below-20-FPS wall for pipeline reasons of its own; the checklist for troubleshooting LabVIEW IMAQ recording below 20 fps is the matching reference there.

If all four check out and the rate still collapses, the conclusion is capacity, not configuration.

Controller hardware that takes over the recording job

When capacity is the conclusion, the fix is a recorder with multi-camera throughput designed in. Vision controllers combine several GigE ports, PoE camera ports and industrial storage in fanless housings, so sustained streams stop competing for a capped power budget. Pick the unit by port count and memory from the spec table:

All 2 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

A single-stream recorder needs less machine:

If the camera side needs work instead, the camera finder filters the shop's stereo 3D sensors by type and series, including GMSL models. For frame-rate limits on the capture side, 3D camera frame rate low on software trigger walks through the mode and data-stream causes to check before blaming the host.

Checks before the next benchmark run

• Run nvpmodel -q before every benchmark and put the mode number next to the result.
• Quote recording FPS only from runs of the full pipeline: capture, encode and write together.
• Pin clocks with jetson_clocks before comparing two runs, so clock scaling cannot skew either one.
• Measure one stream, then two, before concluding anything about aggregate capacity.
• Watch clock and temperature readouts through a multi-minute run, not just the first seconds.
• After a reflash, an OS update or a board swap, re-check the profile and re-apply the clock pinning in the recorder's start-up script.

More host-side failure patterns live on the systems topic page. The closing decision, stated plainly: a grab test at 60 FPS never proves a recording rig works — only a sustained, clock-pinned, full-pipeline run does. If your numbers say the module cannot hold two 60 FPS streams, send the bench results through the contact page and we will size the recorder with you.