Can a scan engine stream video and decode barcodes at the same time?

Your host asks an embedded scan engine for a live preview, the frames arrive, and decoding goes quiet. The SDK logs every command as accepted, yet a barcode held in front of the lens never reads, and the stream dies on its own after roughly half a minute. Nothing in your code is broken: an OEM scan engine runs one imager mode at a time, and a capture session suspends the decoder by design. You will leave with the mode rules, the session lifecycle, the pixels-per-module math that decides whether preview frames can decode anything, and three architectures that deliver both a picture and a read.

One imager, one mode

An OEM scan engine, the module inside a handheld or fixed reader, puts one image sensor behind two firmware pipelines. In decode mode, the default, the engine pulses its illumination and attempts to locate and decode every enabled symbology in its field of view, and it stays there until told otherwise. In image capture mode, the host commands a snapshot or a streaming session and the engine switches its pipeline to picture delivery. The decoder does not slow down during a capture session. It is off.

The exclusivity is physical before it is firmware policy. Decode wants short, high-contrast frames at full resolution; capture wants picture-quality frames and, for video, a compressed stream. One sensor and one image signal pipeline cannot serve both at once, so no host-side setting, callback or thread arrangement changes the rule. That is why the same engine reads reliably all day and then fails the moment a preview window opens. When the session ends, the engine returns to decode mode by itself, with no re-arming command from the host.

The session lifecycle

Host and engine talk in a fixed sequence, and every stuck integration maps onto one step of it:

1. Decode. The engine sits in decode mode and reads every trigger.
2. Request. The host sends a capture request. The engine accepts it and switches to image capture mode. The acknowledgment means the command was received, not that a decode ran or will run.
3. Stream. The engine delivers the snapshot or the video frames. A streaming session runs under a firmware timeout — on this engine class the value engineers hit in practice is 30 seconds — and the stream then stops on its own. The cap moves with firmware, so measure it once for your engine and build.
4. Return. When the session closes, by host command or by timeout, the engine goes back to decode mode automatically.
5. Lost triggers. A trigger press during a session does not decode and is not queued. Decode resumes only after the session ends.

Write the application so step 4 happens deliberately: close the session before the cap fires, and treat a stream that ends by itself as normal operation. If scans turn unreliable after streaming has run, suspect a session that was opened and never closed — the engine is still in capture mode while your logs claim success.

Pixels per module: the number that decides preview decoding

Decode difficulty comes down to one ratio: pixels per module, the width of the smallest bar or dot measured in sensor pixels.

Two pixels per module is the theoretical floor for any decoder. Design for 3 to 5, because print growth, focus error and motion blur consume margins quickly, and 2D symbologies sit at the high end of that range. The same ratio drives the reading-distance math for linear codes such as Code 128, and the mirror case, modules so large that decoder patterns stop matching, is why some oversized codes decode only after downscaling before decoding.

Worked example: a Code 128 label with 10 mil modules (0.254 mm) at an illustrative 200 mm working distance. The LS-CRD-0028 pairs a 2560 × 2048 sensor in 1/1.7" format with an 8 mm lens and is specified at 30 fps and 60 codes/s.

A 1/1.7" sensor is about 7.2 mm wide, so:

• Field of view: 7.2 mm × 200 mm / 8 mm = 180 mm.
• Scale: 180 mm / 2560 pixels = 0.070 mm per pixel.
• Full-resolution frames: 0.254 / 0.070 = 3.6 pixels per module, above the 3-pixel design target, so the reader decodes this label at 200 mm.
• Preview-grade frames, if the capture session delivers 640-pixel-wide frames (a common preview default): 180 / 640 = 0.281 mm per pixel, and the same label is 0.254 / 0.281 = 0.9 pixels per module. That is below the floor, and no decoder setting recovers it.
• The inverse: preview frames at this field of view start working at 3 × 0.281 = 0.84 mm modules, roughly 33 mil.

The optics are not the limit; the frame width is. Full frames resolve the 10 mil code, preview frames cannot, and that is why decode-in-preview needs the engine's full-resolution path or firmware built for it.

Run your own optics through the field of view calculator below, then read the module width off the print drawing and repeat the three lines.

Exposure sets a second limit on shared frames. Blur length equals part speed times exposure time, and blur past half a module starts destroying edge samples, so keep speed × exposure ≤ 0.5 × module width. The 10 mil label above on a 100 mm/s belt allows 0.127 / 100 = 1.3 ms of exposure. A capture pipeline that exposes 10 ms for a well-exposed picture smears that label across 1.0 mm, nearly 4 modules: unreadable, and useless as an archive frame. Decode and well-exposed video want different exposures, which is a second reason one pipeline cannot serve both.

Three designs that work

Sequential capture, decode always

Keep the engine in decode mode for production and open a capture session only on demand: commissioning, teaching a new label, archiving the failed part, showing an operator what was read. The state machine has four states — decode, capture requested, streaming, closed — and your code closes the session before the engine's cap fires. This is the design most kiosks, instruments and test stations actually need, because the picture is for people and the read is for the line. Archiving rides the same path: decode first, snapshot second, upload third, as in the barcode image archiving guide.

Decode-in-preview firmware

A few engine vendors build a project-specific video-decode mode: the imager streams to the host and decodes codes inside the preview field simultaneously. It is real firmware with real limits. Decode rate drops because the processor shares time with streaming, and the decode field is the preview field, not the full imager. Standard firmware on this engine class has no such mode, and no SDK update adds it. If simultaneous video and decoding is a hard requirement, take it to the engine vendor's OEM channel with your project details, and get the feature and its decode rate confirmed for your symbologies in writing.

Split the jobs: reader for decode, camera for video

If the vendor route is closed, stop asking one device to do both. Put a fixed code reader on the decode job and a compact machine-vision camera on the streaming job, or drop the engine and run your own decoder on full-resolution frames from one camera. The split keeps each pipeline at its best exposure and resolution. The single-camera route needs discipline with streamed frames: decoding barcodes from an RTSP or MJPEG stream shows the pipeline end to end, and multi-threaded decode of a live stream has its own failure modes, as in this multi-threaded OpenCV video decode hang write-up.

Mounting hardware, light boards and protective covers for readers sit in the reader accessories category.

When the mode rule does not bite

Three cases look like conflicts and are not.

• Commissioning only. If video exists to align the reader during installation, stream during set-up and decode in production. The two never overlap in time, so a standard engine does both without special firmware.
• Snapshot after decode. If the requirement is to show what was read, no video is needed: decode, then take one snapshot of the part. Snapshot mode is a temporary capture state the engine enters and leaves around a single image.
• Wide modules. If your codes carry modules of 0.84 mm or more, the number from the preview math above, preview-grade frames physically hold enough pixels per module. That makes vendor video-decode firmware viable; without it, the exclusivity still stands.

Continuous video and continuous decode together on standard firmware is the one case with no software answer. Decide early which side of that line the project sits on.

Before you promise both at once

• Write the requirement as one sentence: 'decode every part', 'stream for the operator', or 'both simultaneously'. Most 'both' projects are the first two in sequence, and that is cheaper to build.
• Compute pixels per module for the worst code at the worst distance. Two is the floor; design for three to five.
• Find the engine's session cap once, with your firmware build, and write it into the design. Discovering it in a customer demo is expensive.
• If 'both simultaneously' is a hard requirement, get the vendor's video-decode firmware confirmed for your codes before the schedule commits.
• Judge every decode by its confidence score rather than by the absence of an error, whatever architecture you pick; the barcode read confidence guide explains how to score a decode before trusting it.

The decision

• Need a read plus an occasional picture: any fixed code reader with sequential capture. The MV-ID3013PM-12M-WBN is a 1.3 MP compact reader with a 12 mm lens; the MV-IDS006M-12C-C is a 6 MP logistics reader on GigE.

• Need a read and live video at once: vendor video-decode firmware through the OEM channel, or a reader beside a streaming camera. Send the field of view and worst-code numbers to the applications team through the contact page and we will size the pixel budget with you.
• Manual stations: handheld code readers. The LS-HCR-0001 is a 1.0 MP handheld barcode reader with USB 2.0.

Start from the code reader finder, or go straight to the configurator.

More decode-path guides, including trigger wiring and PLC links, sit on the code reading topic page.