top of page
Camera 6.webp

MJPEG Camera Modules for USB Embedded Integration 

Why MJPEG Is Still the Default for High-Resolution USB Cameras 

​

An MJPEG camera compresses each frame independently as a JPEG image, and that single design choice explains almost everything about where MJPEG is used. There is no prediction between frames, no group-of-pictures structure, and no encoder buffer holding frames back, so latency stays low, and a dropped frame never corrupts the frames that follow it. Every frame in the stream is a complete image that can be pulled out on its own.  

​

The practical reason MJPEG cameras dominate USB is bandwidth. A 20MP sensor sending uncompressed YUV422 at 30fps generates roughly 1.2 GB per second, while USB 3.2 Gen 1 delivers around 400 MB per second in practice. Without compression, that sensor cannot reach the host at all. MJPEG closes that gap while keeping every frame independent, which is why a high-resolution USB camera almost always offers it. Vadzo Imaging supplies MJPEG camera module options across USB 3.2 Gen 1 and USB 2.0, from 2MP to 20MP, on Sony, onsemi, and OmniVision sensors. 

What MJPEG Does Differently

Per-Frame Compression and Why It Matters

​

A Motion JPEG camera treats video as a sequence of still images. Each frame is compressed on its own, with no reference to the previous or next frame. Four consequences follow directly from that. Latency is low because the encoder never waits for a future frame to complete a prediction, making MJPEG a practical low-latency camera format for interactive and control applications. Packet or frame loss is contained, since a corrupted frame does not propagate. Any single frame can be extracted from the stream as a usable image without decoding a sequence, which matters in inspection and record keeping. And it produces no temporal artefacts from inter-frame prediction on fast motion.

​

Bandwidth, Bitrate and Frame Rate

​

The cost of frame independence is data volume. MJPEG compression does not exploit similarity between consecutive frames, so its video bitrate is several times higher than H.264 at comparable image quality. What it does gain is predictability: MJPEG bitrate scales with detail inside each frame rather than with motion between frames, so a busy moving scene costs roughly what a static detailed scene costs. H.264 behaves the opposite way, and its bitrate can spike sharply when a scene starts moving. For a system with a fixed camera bandwidth budget, a stable bitrate is often worth more than a low average one. Resolution and frame rate then set the ceiling: a frame rate camera module running full resolution consumes proportionally more of the link than the same part running 1080p.

​

MJPEG vs H.264 vs Uncompressed

​

MJPEG compresses each frame as an independent JPEG. H.264 compresses by predicting each frame from those around it. Uncompressed YUV does not compress at all. That single difference drives everything else, because every MJPEG and uncompressed frame is a complete image on its own, while an H.264 frame depends on its reference frames.

  

Bitrate follows from the method. H.264 produces the lowest, uncompressed the highest, and MJPEG sits between them. Stability differs as much as the average: uncompressed is fixed, MJPEG varies with scene detail, and H.264 varies sharply with motion, so a busy scene can push its bitrate well above its own average.

 

 Latency and robustness move together. Uncompressed has the lowest latency because nothing is encoded; MJPEG is close behind since each frame is compressed as it arrives; and H.264 is highest because its prediction structure holds frames in an encoder buffer. A lost MJPEG or uncompressed frame affects only itself, while a lost H.264 frame can corrupt the frames that reference it.

  

The host side differs too. Uncompressed needs no decoding at all. MJPEG needs a JPEG decode per frame, which every operating system already provides. H.264 needs codec decoding and carries patent licensing obligations that neither of the other two does.

​

A YUV output camera is the right choice when the host needs original pixel data and the link can carry it. H.264 is the right choice when video must be recorded or streamed for long periods, and bandwidth is the dominant constraint. MJPEG sits between them and wins wherever compressed video output is needed but frame Independence, low latency, and universal host support matter more than the smallest possible file. That combination is why an MJPEG streaming camera remains the default on USB even where newer codecs are available.

MJPEG Over USB: UVC and Host Compatibility

UVC Compliance and Driverless Operation

​

MJPEG is one of the formats defined in the USB Video Class specification, which is why it is widely available. A UVC-compliant camera is listed as a standard video device on Windows, Linux, and Android with no vendor driver, and MJPEG decoding is already included in the operating system, browsers, and all common capture frameworks. A UVC camera module that uses MJPEG requires no codec installation, licensing agreement, or vendor SDK to provide a functioning video stream. Every module on this page is a USB camera module that meets the specification, allowing an MJPEG camera to be verified on a laptop before any embedded integration work begins. 

​

USB 3.2 Gen 1 and USB 2.0 Bandwidth Limits

​

The two interfaces here impose very different ceilings, and MJPEG is what makes the lower one usable. A USB 3.2 Gen 1 camera has roughly 400 MB per second available in practice against a 5 Gbps link, enough for MJPEG at 20MP. USB 2.0 delivers around 40 MB per second for isochronous video. An 8MP frame in uncompressed YUV422 is about 16.6 MB, so 30fps would require close to 500 MB per second, more than ten times what USB 2.0 can carry. The Merlin-415CRS delivers 8MP over USB 2.0 only because MJPEG compression reduces that frame to a fraction of its raw size. This is the clearest case for the format: it is not a compromise on those links; it is the enabling condition. 

Falcon MJPEG Camera Modules, USB 3.2 Gen 1

The Falcon range covers MJPEG USB camera options over USB 3.2 Gen 1 Type-C, from 2MP to 20MP, with fixed focus, VCM autofocus, and optical image stabilization variants. Every Falcon module is a UVC-compliant camera. Autofocus parts carry a VCM actuator with a focus ranging from 100 mm to infinity. 

Camera Module
Sensor
Shutter
Resolution
Focus
Buy Now
Falcon-2020CRS
onsemi AR2020
Rolling
20MP
Fixed
Falcon-1335CRA
onsemi AR1335
Rolling
13MP
VCM autofocus
Falcon-1335CRO
onsemi AR1335
Rolling
13MP
Autofocus with OIS
Falcon-1335CRS
onsemi AR1335
Rolling
13MP
Fixed
Falcon-258CRA
Sony IMX258
Rolling
13MP
VCM autofocus
Falcon-830CRS
onsemi AR0830
Rolling
8MP
Fixed
Falcon-823CRS
onsemi AR0823
Rolling
8MP
Fixed
Falcon-822CRS
onsemi AR0822
Rolling
8MP
Fixed
Falcon-821CRS
onsemi AR0821
Rolling
8MP
Fixed
Falcon-821CRH
onsemi AR0821
Rolling
8MP
VCM autofocus, M12
Falcon-415CRS
Sony IMX415
Rolling
8MP
Fixed
Falcon-544CRA
onsemi AR0544
Rolling
5MP
VCM autofocus
Falcon-544CRH
onsemi AR0544
Rolling
5MP
VCM autofocus, M12
Falcon-544CRS
onsemi AR0544
Rolling
5MP
Fixed
Falcon-522CRS
onsemi AR0522
Rolling
5MP
Fixed
Falcon-521CRS
onsemi AR0521
Rolling
5MP
Fixed
Falcon-521CRH
onsemi AR0521
Rolling
5MP
VCM autofocus, M12
Falcon-5640CRA
OmniVision OV5640
Rolling
5MP
VCM autofocus
Falcon-3C10CRS
OmniVision OX03C10
Rolling
2.5MP
Fixed
Falcon-246CRS
onsemi AR0246
Rolling
2MP
Fixed
Falcon-235CGS
onsemi AR0235
Global
2.3MP
Fixed
Falcon-234CGS
onsemi AR0234
Global
2MP
Fixed
Falcon-234CGH
onsemi AR0234
Global
2MP
VCM autofocus, M12
Falcon-233CRS
onsemi AR0233
Rolling
2MP
Fixed

Merlin MJPEG Camera Modules, USB 2.0

The Merlin range covers MJPEG output over USB 2.0 Micro-B for cost-sensitive designs. These are also the Sony low-light parts in the portfolio. Every Merlin module is a UVC-compliant camera, and on this interface, MJPEG is what allows resolutions above 1080p to reach the host at all. 

Camera Module
Sensor
Resolution
Shutter
Focus
Buy Now
Merlin-415CRS
Sony IMX415
8MP
Rolling
Fixed
Merlin-521CRS
onsemi AR0521
5MP
Rolling
Fixed
Merlin-662CRS
Sony IMX662
2MP
Rolling
Fixed
Merlin-291CRS
Sony IMX291
2MP
Rolling
Fixed
Merlin-290CRS
Sony IMX290
2MP
Rolling
Fixed
Merlin-234CGS
onsemi AR0234
2MP
Global
Fixed

Form Factor Options Across the MJPEG Range

38 x 38 mm Square Modules

​

Most modules in both ranges use a 38 x 38 mm square board, and most of those can be reduced to 32 x 32 mm as a customization, which takes the board to roughly 71 percent of its area without changing the sensor or the interface. Three parts are supplied at 38 x 38 mm without the reduction option: the Falcon-234CGH, Merlin-662CRS and Merlin-234CGS. Because the outline is otherwise constant, a design can move between sensors and resolutions inside the same mechanical envelope. 

​

Strip Form Factor Modules

​

Three autofocus parts use an elongated board instead of a square one. The Falcon-1335CRA measures 78 x 15.8 x 9.8 mm, the Falcon-5640CRA 75 x 16 x 9.8 mm, and the Falcon-258CRA 70 x 15 x 9.8 mm. Under 16 mm wide and under 10 mm deep, this shape fits places a 38 mm square board cannot: a display bezel, a conferencing bar, a scanner head, or the top edge of a panel. All three are autofocus parts, which suit a video conferencing camera holding a subject sharp at changing distance, or a document scanning camera working across varying page thickness. 

Sensor Options Across the MJPEG Range

MJPEG determines how the image leaves the camera. The sensor determines what there is to send. 

​

Global Shutter and Rolling Shutter

​

Inference latency, not frame rate, is usually the figure that decides whether an edge AI camera can meet a control loop's requirement. Comparative benchmarks across edge platforms show wide separation: some roughly double the object-detection frame rate of others while drawing proportionally more power, so platform choice is a thermal and power decision as much as a performance one. Model quantization has made object detection viable on microcontroller-class hardware with well under a megabyte of flash, at single-digit milliseconds per frame and energy per inference measured in microjoules to millijoules. 

​

Autofocus and Fixed Focus

​

Nine modules provide active focus. The Falcon-1335CRA, Falcon-258CRA, Falcon-544CRA and Falcon-5640CRA use VCM-based autofocus with a focus range from 100 mm to infinity. The Falcon-821CRH, Falcon-544CRH, Falcon-521CRH and Falcon-234CGH combine that VCM autofocus with an S-mount M12 holder, so the optic remains interchangeable. The Falcon-1335CRO adds optical image stabilization alongside autofocus for platforms that move while capturing. An autofocus camera module is specified where working distance varies during operation; everywhere else, fixed focus is simpler, more robust to vibration, and lower in cost.

 

HDR and Dynamic Range

An HDR camera module holds bright and dark regions in a single frame, and the implementations across this onsemi camera module selection differ enough to compare rather than treat as equivalent. The Falcon-821CRS and Falcon-821CRH provide embedded HDR above 140 dB, the widest dynamic range in the range. The Falcon-246CRS provides on-sensor eHDR at 120 dB with Adaptive Local Tone Mapping, plus line interleaved HDR and enhanced dynamic range modes. The Falcon-822CRS provides line-interleaved HDR and enhanced dynamic range with intelligent linearization that limits motion artefacts and LED flicker. The Falcon-3C10CRS on the OmniVision OX03C10 adds LED flicker mitigation for scenes lit by pulsed LED sources, and the Falcon-233CRS covers HDR at 1080p.

​

Low Light Sensors 

​

A low-light camera module in this portfolio is normally a Sony sensor camera module. The Merlin-290CRS and Merlin-291CRS use the IMX290 and IMX291; the Merlin-662CRS uses the IMX662; and the IMX415 appears as both the Falcon-415CRS and Merlin-415CRS, all backside-illuminated designs that recover usable detail under limited illumination. On the onsemi side, the AR0544 in the Falcon-544CRS, Falcon-544CRA, and Falcon-544CRH delivers strong low-light color sensitivity at very low power, and the AR0522 in the Falcon-522CRS is also specified for low-light work. 

Choosing Between MJPEG, H.264 and Uncompressed Output

The decision follows from what the host does with the video rather than from the codec itself.

  

  • Choose MJPEG when resolution exceeds what the link can carry uncompressed, when every frame has to stand alone, when latency matters, or when the host must decode without installed codecs or licensing.

​

  • Choose H.264 when video is recorded or streamed continuously for long periods and total data volume is the binding constraint, accepting the decode stage and the bitrate variation under motion.

​

  • Choose uncompressed YUV when the host runs its own image processing on original pixel values and the interface has bandwidth to spare at the required resolution and frame rate.

​

Many applications use more than one. A UVC device can offer MJPEG for full-resolution capture and a lower-resolution uncompressed mode for real-time processing on the same camera, selected by the host at runtime.

MJPEG Camera Applications

Video Conferencing and Collaboration

​

A video conferencing camera needs high-resolution over USB, autofocus that holds a subject sharp as they move, and a stream every operating system and browser can decode without a plugin. MJPEG satisfies all three, and the strip form factor of the Falcon-1335CRA, Falcon-258CRA, and Falcon-5640CRA fits the bezel of a display or the body of a conferencing bar where a square board will not. 

​

Document and Barcode Scanning

​

A document scanning camera benefits from MJPEG for a specific reason: each frame is a complete image, so a single capture can be pulled from a live stream as a usable file without decoding a sequence. Autofocus handles varying page thickness and document placement, and higher resolution parts such as the Falcon-2020CRS or Falcon-1335CRS resolve small print and dense barcodes across a full page.

​

Embedded Vision and Inspection

​

An embedded vision camera using MJPEG trades some image fidelity for the ability to move high-resolution frames across a standard USB link. Where measurement demands original pixel values, an uncompressed mode on the same module is the better choice, and many inspection deployments run MJPEG for recording alongside a lower-resolution uncompressed stream for analysis. Global shutter parts matter here whenever the part or the camera moves. 

​

Kiosk and Access Control

​

Kiosks, access control readers, and self-service terminals need a camera that works on whatever host the product ships with, often over a long product life and without driver maintenance. A UVC MJPEG stream is the most portable option available. HDR parts earn their cost in these installations, since the camera usually faces a doorway or a bright background it cannot control. 

Customizing an MJPEG Camera Module

An OEM camera module is normally the same sensor in a form the product can accept. Board reduction from 38 x 38 mm to 32 x 32 mm, lens selection and field of view, IR cut or IR pass filter choice, connector type, cable length and orientation, lens holder height, and ISP tuning for the target scene are all specified per project. A VCM holder can be added to a fixed-focus part where working distance turns out to vary, and MJPEG quality settings, resolution modes, and frame rate modes can be tuned to fit a defined bandwidth budget rather than left at defaults. Because Vadzo Imaging designs the boards and firmware rather than reselling finished modules, both the mechanical outline and the imaging behavior can be changed with the sensor core unchanged. 

Quick Samples Dispatch

Find the Right Camera for Your Project Today.

Samples procured typically ship within 5-7 business days of order confirmation, with tracked international shipping. Compressed development timeline? You can be capturing frames from a Vadzo camera the same week you shortlist it.  

RoHS 3  ·  REACH  ·  NDAA (Selected Models)

No MOQ (Minimum Order Quantity)

Ships Worldwide

Frequently Asked Questions

1.What is an MJPEG camera? 

An MJPEG camera is a camera that compresses each video frame independently as a JPEG image and sends the result as a stream of complete frames. Because the MJPEG video format uses no prediction between frames, every frame stands alone: it can be extracted as a usable image on its own, a lost frame does not corrupt the frames after it, and there is no encoder buffering to add delay. A Motion JPEG camera is the same thing under its full name

2.What is the difference between MJPEG and H.264?

MJPEG compresses each frame separately, while H.264 compresses by predicting each frame from those around it. The MJPEG vs H.264 trade is therefore data volume against independence: H.264 achieves a much lower video bitrate, but its frames depend on reference frames; its bitrate rises sharply under motion, and it adds encoder and decoder delay. MJPEG uses more bandwidth for the same quality but holds a stable bitrate, keeps latency low, contains frame loss, and requires no codec licensing.

3.Why do High-resolution USB cameras use MJPEG?

Because without MJPEG compression, the sensor cannot reach the host. A 20 MP uncompressed frame at 30 fps is roughly 1.2 GB per second, against about 400 MB per second usable on USB 3.2 Gen 1. On USB 2.0, the gap is far wider: an 8MP uncompressed stream at 30 fps needs close to 500 MB per second against roughly 40 MB per second available. MJPEG is what allows MPEG cameras such as the Merlin-415CRS to deliver 8MP over USB 2.0, so on a bandwidth-limited link it is the enabling condition rather than a compromise. 

4.Is MJPEG lower latency than H.264?

Yes, in general. An MJPEG encoder compresses each frame as soon as it is captured, with no need to reference a future frame, so no frames are held in an encoder buffer. H.264 introduces delay on both the encode and decode sides because of its prediction structure. For interactive video, remote operation, and closed-loop control, a low-latency camera path favors MJPEG, though uncompressed output remains lower still where the link can carry it.

5.Do MJPEG cameras need a driver or a codec on the host? 

No. Every module here is a UVC camera module, so it enumerates a standard USB video device on Windows, Linux, and Android without a vendor driver, and MJPEG decoding is already present in operating systems, browsers, and common capture frameworks. That makes a UVC-compliant camera using MJPEG the most portable option available for a product that must work across several host platforms or stay serviceable over a long product life.

6.Which MJPEG camera modules have global shutter or autofocus? 

Global shutter is available on the Falcon-235CGS, Falcon-234CGS, Falcon-234CGH, and Merlin-234CGS. Autofocus is available on nine modules: the Falcon-1335CRA, Falcon-258CRA, Falcon-544CRA, and Falcon-5640CRA use VCM autofocus with a 100 mm to infinity focus range; the Falcon-821CRH, Falcon-544CRH, Falcon-521CRH, and Falcon-234CGH add an interchangeable S-mount M12 optic; and the Falcon-1335CRO adds optical image stabilization. The Falcon-234CGH is the only part combining a global shutter camera module with autofocus. 

7.How do I choose an MJPEG camera module for OEM integration? 

Begin with resolution and interface, as they determine whether MJPEG is required at all: calculate the uncompressed data rate at your goal resolution and frame rate, and compare it to the usable bandwidth of USB 3.2 Gen 1 or USB 2. Then choose the sensor for the scene: global shutter if anything moves during exposure, HDR if lighting cannot be controlled, low-light sensor when illumination is limited, and autofocus only where working distance fluctuates. Next, confirm the mechanical envelope, such as whether a 38 x 38 mm square board would fit or a strip form factor is required. Check to see if an uncompressed mode is necessary in addition to MJPEG for an embedded vision camera measurement. 

bottom of page