Low resolution preview stream: cut decoder CPU load on small displays

A 1080p preview on a panel that shows 800 × 480 pixels decodes more than five times the data the screen can draw. On a small embedded CPU that waste is the whole problem: the load pins near 100%, the picture crawls, and the delay grows until the view is unusable. The fix is arithmetic, not new hardware. Match the preview stream to the panel's pixel count, cap the preview frame rate, and hand the compressed JPEG to the display stack instead of decoding it inside the acquisition loop. Every number below comes from exactly that situation: a small panel whose two available MJPEG preview modes, 720p and 1080p, both saturated its processor.

Why a 1080p preview saturates a small CPU

JPEG decode cost scales with the pixel count of the compressed frame, not with the size of the window that shows it. A 1920 × 1080 MJPEG frame carries 2,073,600 pixels; an 800 × 480 panel draws 384,000. The processor runs the inverse transform and color conversion over all 2.07 million pixels, then the GUI scales the result down to fit, so the CPU pays a full-size decode plus a resize to show under a fifth of the pixels it touched.

The reported case shows how little margin small cores carry. Both preview modes drove the device to nearly 100% CPU with a slow, delayed picture. Healthy MJPEG streaming on a comparable single-board setup sits near 50% CPU in one reported measurement, so doubling the per-frame work leaves the core nothing for the application itself. The compressed frame is not the burden — one reported JPEG example packs 46 MB of raw frame data into 4.07 MB, about 11× less. The burden is expanding it back into pixels.

What you need

• The panel's exact pixel budget: width × height. For the case below, 800 × 480 = 384,000 pixels.
• A camera whose driver offers more than one preview size. Industrial GigE and USB3 area scan cameras commonly provide resolution modes, binning or sub-sampling; some drivers name preview modes after their output, so look for entries in the pattern of MJPEG_1080P or MJPEG_720P.
• A baseline CPU reading with the current preview running — task manager on Windows, top on Linux.
• A display path that can take a compressed image. Most GUI toolkits render a JPEG directly; if yours cannot, the pass-through still removes a duplicate decode, and the one remaining decode runs in the display thread.

The budget logic is identical whether the panel hangs off an embedded board or off one of the industrial panel PCs used as machine HMIs.

Cut the preview load in six steps

1. Write down the panel budget. Multiply the screen's width by its height: 800 × 480 = 384,000 pixels. Preview pixels above that number are decode work the screen never uses.

2. Request the largest mode that fits under the budget. In the stream or preview settings, choose a 480p-class mode — 640 × 480 at 307,200 pixels is the common landing. If the driver only exposes binning or sub-sampling, that is the same lever: the camera shrinks the image before it becomes a JPEG, which also shrinks the payload the panel must receive.

3. Cap the preview frame rate. A person watching part arrival or alignment reads 10-15 fps comfortably, so set the preview there as a rule of thumb. Decode load scales with frames per second exactly as it scales with pixels per frame: halve one and you halve the load.

4. Decode once, in the display stack. Where the acquisition library hands your code a decoded image and the GUI then decodes or scales it again, forward the compressed JPEG bytes untouched and let the display widget decode at draw time. Carry the compressed frame length into the image buffer size, because JPEG length varies with scene content. This swap — a raw copy instead of a decode inside the stream converter — is the change that produced the reported improvement on that device.

5. Draw only the newest frame. Set the transport layer's buffer handling to newest-only so a slow panel always renders the latest image instead of working through a stale queue. Queue delay survives every resolution change; the newest-only buffer handling setting shows where it lives.

6. Re-measure against the baseline. Same scene, same preview rate, same CPU reading as before any change. Compare the result with the ratio math in the worked example below.

Worked example: 1080p MJPEG preview on an 800 × 480 panel

The inputs, all from the reported case: a display of 800 × 480 pixels; two available preview modes, MJPEG 720p and MJPEG 1080p, both measured at nearly 100% CPU with a slow, delayed picture; and the proposed replacement, a 480p-class stream at 640 × 480.

The rule: JPEG decode work per frame scales with the stream's pixel count. The decode ratio — stream pixels divided by panel pixels — says how much decode effort the screen actually uses. A ratio at or below 1 fits the panel; well above 1, the decoder saturates, which is what the measurements show.

The arithmetic:

• MJPEG 1080p: 1920 × 1080 = 2,073,600 pixels → 2,073,600 ÷ 384,000 = 5.4× the panel
• MJPEG 720p: 1280 × 720 = 921,600 pixels → 921,600 ÷ 384,000 = 2.4×
• 640 × 480: 307,200 pixels → 307,200 ÷ 384,000 = 0.8×, upscaled to fill the panel by 800 ÷ 640 = 1.25
• 1080p down to 640 × 480: 2,073,600 ÷ 307,200 = 6.75× less decode work per frame

The result: at the same preview rate, a decoder that sat near 100% lands near 100 ÷ 6.75 ≈ 15%. Call it a 15-25% band, because per-frame costs such as entropy scanning and color conversion do not shrink with the pixel count.

The decision: request the 480p-class preview and keep the decode ratio at or below 1. On this panel class, 2.4× — the 720p mode — already pinned the CPU near 100%, so 720p is out as firmly as 1080p. When the driver offers no smaller mode, the raw-JPEG pass-through from step 4 is the fallback, and it is the change that fixed the reported device.

Which mode to request

Cameras step through standard sizes rather than matching a panel exactly, which is why 640 × 480 is the practical target for an 800 × 480 screen.

Keep the inspection stream at full resolution

Shrink the preview path, never the capture path. The measurement still needs the sensor's full pixel count; the panel's budget is display-only. Two patterns work. Run one acquisition at full resolution, decode once, and hand the algorithm the full frame while the GUI shows a downscaled copy of it. Or run the small preview stream while you set the station up, then switch to full capture for the measurements. The full resolution capture with a low res preview guide covers the first pattern.

Size the capture camera from the part, not from the panel — the calculator below converts field of view and smallest feature into the pixel count the capture stream needs.

When acquisition runs faster than processing, the same budget reappears as a growing queue and rising delay; closing that frame rate gap is a separate fix from the preview one.

If the camera is also yours to choose, the preview starts at the sensor. The GigE LS-CMR-0053 outputs 12 MP at 9 fps, a rate a small CPU schedules easily, while the USB3 LS-CMR-0166 runs the same IMX226 sensor at 30 fps and 4000 × 3000 when the preview has to follow fast motion.

For a status-only panel, a 2.5 MP GigE camera such as the MV-CU020-90GC sits at the low end of the decode budget, and its global shutter keeps moving parts free of rolling distortion in the views you do show.

Verify the fix

Three readings decide whether the change landed:

• CPU with the preview running: the worked example's panel should move from near 100% into the 15-25% band at the same preview rate. If it barely moved, decode was not the bottleneck.
• Delay: wave a part through the field and watch. With newest-only buffering and a 10-15 fps preview, the picture should trail the motion by well under a second. Lag that persists in fullscreen points at the rendering path, which the fullscreen preview lag fix addresses.
• Dropped frames: the driver's frame-drop counter should stay flat. If the panel also records video, a compressed AVI adds a per-frame encode on the same processor — check the codec notes for compressed AVI recording before budgeting the CPU.

When the usual answer is wrong

If 640 × 480 still saturates the core, the load was never only decode. The classic companion is a busy-wait acquisition loop spinning between frames; replacing it with a blocking wait drops CPU even at full resolution. The high CPU usage from camera acquisition fix walks through it.

If the stream arrives over RTSP and the decode sits on the CPU, move decode and color conversion to the GPU where the platform has one. The RTSP decode overload GPU offload guide maps that pipeline.

If the preview must show fast motion at 30 fps with full detail, no stream size rescues a too-small processor. Run the acquisition and decode on a vision controller instead, and send the panel only the finished view. A low-tier unit carries this role: the MV-VC2140-128G40-1T pairs an Intel N-series processor with 8 GB of memory, a 128 GB SSD and a 1 TB HDD in a fanless housing.

Checks before you commit

• Stream pixels at or below panel pixels (384,000 in the example): every pixel above the budget is decode work with no display purpose.
• Preview rate capped at 10-15 fps for a status view: decode load scales with frame rate as much as with resolution.
• Newest-only buffer handling on: a stale queue creates delay that no resolution change removes.
• Image buffer sized from the compressed frame length: JPEG size varies with scene content.
• Baseline CPU readings taken before and after: the decode ratio predicts the result, the measurement confirms it.
• Capture path untouched at full resolution: preview changes must never feed the measurement.

Where to go next

Filter cameras by interface and resolution in the camera finder, or pair camera, lens, light and controller step by step in the system configurator. More system-side fixes on buffering, CPU load and preview behavior sit on the systems topic page, and the contact page reaches the applications team when a station layout is still open.