A 4K frame contains more than eight million pixels. Sending thirty of those frames every second without compression creates a very large data stream. USB camera modules therefore often use MJPEG because JPEG compression reduces the amount of data that must travel across the USB link.
USB2.0 has much less practical bandwidth than USB3.x. Even on USB3.x, uncompressed high-bit-rate modes can compete with other devices and host-controller limits. MJPEG allows the same physical interface to carry a higher resolution or frame rate by reducing the number of bytes per frame.
Unlike long-GOP video codecs such as H.264/H.265, MJPEG compresses individual frames as JPEG images. This makes random frame access relatively simple and avoids inter-frame prediction dependencies. For some vision applications, that simplicity is useful even though compression artifacts remain.
Compression does not make data disappear; it moves work elsewhere. The camera or bridge compresses the image, and the host decodes it. A weak embedded processor may struggle with several 4K MJPEG streams even if the USB bus can carry them.
For multi-camera systems, measure both USB utilization and CPU/GPU decoding load.
The host must still negotiate the mode, receive the stream, decode frames and move them into memory. Software frameworks may copy buffers or convert color formats, adding latency. Cable quality and USB-controller sharing can also affect sustained performance.
A specification should be verified on the final host rather than assumed from a successful test on a desktop PC.
If an algorithm is sensitive to JPEG artifacts, requires consistent pixel values or avoids decoder latency, YUY2 or another uncompressed/raw path may be preferred. In that case, USB3.x, lower resolution, lower frame rate or a different interface may be necessary.
Compare the mode table: resolution, frame rate and format. Then check USB version, host decoding load, latency and whether the application processes every frame. A module advertising ‘4K30’ can behave very differently depending on whether that mode is MJPEG, H.264 or another format.
A single 4K30 MJPEG camera may stream reliably on a host, but four identical cameras can overwhelm USB topology or decoder resources. Compression reduced each link's bandwidth, yet the combined system still has to receive and decode four streams. Multi-camera design therefore needs aggregate measurements, not a per-camera assumption.
The complete statement should include format and interface: for example, 3840×2160 at 30 fps in MJPEG over a specific USB link. Without the format, the number hides the key engineering constraint. This reading habit prevents many selection mistakes.
It is a lossy compression format, so artifacts are possible. Whether they matter depends on compression settings and the application.
H.265 can compress more efficiently but adds codec complexity and often more latency. MJPEG is simple and frame-independent.
It may be possible for some formats and implementations, but the exact data rate, protocol overhead and host pipeline must be checked. Do not assume it from the interface name alone.
