USB Audio & Video 02: What’s Actually Streaming Through Your USB Webcam?

A Counter-Intuitive Question

Picking up where the last part left off—you open a meeting app. The picture appears. Looks routine. But pause for a moment and ask: what kind of data is actually being sent from the camera to the computer when it delivers that single 1920×1080 frame?

Your first guess might be: “It’s just a picture, right?” But it’s not that simple. A 1080p, 30fps video stream, expressed in the most straightforward way (24 bits of RGB color per pixel), works out to 1920 × 1080 × 24 bit × 30 frames ≈ 1.49 Gbps.

A typical USB 2.0 cable has a theoretical bandwidth of 480 Mbps—that’s 0.48 Gbps. Mathematically, raw 1080p 30fps simply doesn’t fit through USB 2.0. And yet in reality, USB 2.0 webcams from the early 2010s were happily running 1080p. How?

That’s what this article is about: what formats are actually flowing through USB cameras, the bandwidth game they’re playing against USB, and what a UVC camera “negotiates” with your computer the moment it’s plugged in.

USB Bandwidth: The Hard Constraint

To understand USB video, you have to internalize one foundational fact: USB is not an infinite pipe. Every generation of USB has a fixed bandwidth ceiling, and that ceiling directly determines what kind of video a camera can deliver.

USB Version	Commercial Name	Theoretical Bandwidth	Practical Bandwidth
USB 1.1	Full Speed	12 Mbps	~8 Mbps
USB 2.0	High Speed	480 Mbps	~320 Mbps
USB 3.0 / 3.2 Gen 1	SuperSpeed	5 Gbps	~3.2 Gbps
USB 3.2 Gen 2	SuperSpeed+	10 Gbps	~7.2 Gbps
USB 3.2 Gen 2×2	SuperSpeed 20Gbps	20 Gbps	~14 Gbps
USB 4 / Thunderbolt 3, 4	USB4 / Thunderbolt	40 Gbps	~30 Gbps

About “practical bandwidth”—USB is a time-multiplexed bus, and the protocol itself reserves a portion of bandwidth for handshaking, error correction, and device management. Real-world available bandwidth typically lands at 65~75% of theoretical. This detail matters. Many people calculate video bitrates against theoretical bandwidth, then wonder why “it won’t transmit.” They’ve forgotten the protocol overhead.

Now let’s go back to that 1.49 Gbps for raw 1080p—

• USB 2.0 has ~320 Mbps of usable bandwidth. Doesn’t fit—short by nearly 5x.
• USB 3.0 has ~3.2 Gbps. Fits, but already eats more than half the pipe.
• 4K 60fps raw is roughly 12 Gbps—doesn’t even fit USB 3.0. You need USB 3.2 Gen 2 or above.

This is why USB cameras almost never transmit raw frames. To fit “looks clear enough” video into limited USB bandwidth, there’s only one tool: compression. The UVC standard anticipated this. It supports multiple video formats, ranging from completely uncompressed raw data to heavily compressed streams—covering different bandwidth-vs-quality trade-offs.

UVC Video Formats: A Spectrum from Raw to Compressed

UVC defines several video formats (called “Payload Formats” in UVC terminology). Let’s walk through the most important ones:

RGB / YUV: Uncompressed, Pristine, Massive

RGB (direct red-green-blue encoding) and YUV (luma-plus-chroma encoding, in sub-formats like YUV422 / YUV420) are uncompressed raw pixel formats. Their advantages are direct—no information loss, the PC receives data ready to display, the CPU barely has to decode anything. But the downside is just as direct—massive data volume. As computed above, raw 1080p 30fps RGB is 1.49 Gbps. YUV422 (16 bits per pixel) is a bit less but still in the 1 Gbps range.

This means RGB / YUV in USB cameras is only practical for low resolution or low frame rate:

• USB 2.0 cameras running YUV typically max out at 640×480 30fps or 1280×720 15fps
• USB 3.0 cameras running YUV can hit 1080p 30fps, but it’s the ceiling
• 4K YUV? You need USB 3.2 Gen 2 or above, and it’s effectively limited to industrial cameras

The vast majority of consumer USB cameras do not use RGB / YUV at high resolutions.

MJPEG: The Real Workhorse of High-Resolution USB Video Today

MJPEG (Motion JPEG) can be described in a single sentence: compress each frame independently as a JPEG image, then transmit those JPEGs one after another. Its characteristics are:

• Significant compression—typically squeezes data to 1/10~1/20 of raw. A typical 1080p 30fps MJPEG bitrate sits at 30~50 Mbps, well within USB 2.0’s reach.
• Frame-independent—no inter-frame prediction, no B-frames or P-frames. Every frame is complete on its own.
• Trivially easy to decode—JPEG is a thirty-year-old mature technology. Every OS, every platform has hardware-accelerated or assembly-optimized decoders. CPU usage is essentially negligible.
• Extremely low latency—each frame is independently encoded, transmitted, and decoded. End-to-end latency from camera capture to screen display is theoretically just one frame (about 33ms at 30fps).

The cost of MJPEG is that compression efficiency is worse than modern video codecs. At the same bitrate, MJPEG quality is one notch below H.264; to match H.264’s quality, MJPEG needs significantly higher bitrate. But in the USB camera context, this turns out to be an advantage—USB bandwidth is generous (USB 3.0 has 3.2 Gbps available). CPU time is the scarce resource (the conferencing app is already eating CPU).

So “spend more bandwidth to save CPU” is exactly the right trade-off. That’s why virtually every USB camera supporting 1080p or higher today uses MJPEG as the primary format—it’s the optimal balance between bandwidth, quality, CPU, and latency in this specific environment.

A special note on 4K: nearly every USB camera that claims to support 4K is sending MJPEG. The reasons are exactly what we’ve covered: 4K YUV is too large, 4K H.264 is too CPU-intensive (we’ll explain below), and only MJPEG can deliver 4K into a PC at reasonable CPU cost.

H.264 / H.265: Beautiful in Theory, Awkward in Practice

H.264 has been the most successful video codec of the past twenty years. The videos you watch, the shorts you scroll, the meetings you attend—nearly all of them are encoded in H.264 under the hood. UVC 1.5 (released in 2012) formally added H.264 support. On paper, H.264 should be the optimal choice for USB cameras—it compresses 5~10x better than MJPEG. At equivalent quality, it needs only one-fifth to one-tenth the bandwidth.

But in practice, H.264 is not the mainstream choice for USB cameras. Several reasons:

First, CPU decoding overhead. H.264 decoding is substantially more complex than JPEG—inter-frame prediction, motion compensation, entropy coding, deblocking filters, etc. Conferencing apps already consume large amounts of CPU (image scaling, noise reduction, echo cancellation, network encoding for transmission). If the input video also requires H.264 decoding on the CPU, performance gets tight. Modern PCs have hardware H.264 decoders, but whether the conferencing app actually invokes hardware decode—and how efficiently—is not guaranteed, especially on Windows, where different apps have wildly varying hardware acceleration support.

Second, latency. H.264 uses B-frames (bidirectionally predicted frames) to improve compression—but B-frames have to wait for the next frame before they can be decoded. This is fatal for real-time video conferencing. You can configure H.264 in “low-latency mode” (I+P frames only, no B-frames), but that sacrifices compression efficiency.

Third, the bitrate-vs-quality sweet spot is different. H.264’s real “crushing” of MJPEG happens at low bitrates (say, 1080p at 2 Mbps). But in USB camera scenarios, bandwidth isn’t the bottleneck. Since bandwidth is plentiful, “30 Mbps MJPEG” and “5 Mbps H.264” deliver nearly identical final quality—but the former uses less CPU and has lower latency.

Fourth, OS-side support depth. Windows DirectShow / Media Foundation’s support for UVC H.264 is far less “just works” than its MJPEG support. Some conferencing apps run into compatibility issues with H.264 UVC devices.

So the reality is: even though UVC 1.5 supports H.264, very few USB cameras on the market actually output H.264. MJPEG remains the de facto standard.

The future? There hasn’t been a major new UVC version after 1.5. But the industry is exploring directions like AV1 (a more efficient open-source codec) and HEVC / H.265 (the successor to H.264). These may enter UVC specifications at some point. For the foreseeable future, though, MJPEG will remain the practical mainstay of USB cameras—because “simple” is exactly the right virtue in the USB context.

The “Conversation” Between Device and Computer: UVC Negotiation

Finally, let’s cover something most people have never noticed but is actually critical: the moment a UVC camera is plugged into a computer, what exactly are they negotiating? In UVC terminology, this process is called Probe and Commit. The workflow looks like this:

Step 1: Enumeration—The computer uses the standard USB “device descriptor” mechanism to ask: “Who are you?” The device replies: “I’m a UVC class device (Class Code 0x0E), version 1.5.” The computer then reads the device’s “video stream interface descriptor”—getting the full list of supported formats, resolutions, and frame rate combinations. Something like:

• MJPEG · 3840×2160 · 30fps
• MJPEG · 1920×1080 · 60fps
• YUV422 · 1280×720 · 30fps
• …

This list is the camera’s “capability menu.”

Step 2: Probe—The conferencing app (say, Zoom) tells the OS: “Give me 1920×1080 30fps MJPEG.” The OS translates this into a UVC Probe command and sends it to the camera. The camera replies: “Confirmed, I can do that combo.” Or: “I can’t do that exactly, but the closest option I support is XXXX.”

This is a negotiation that both sides can go back and forth a few times until they agree on parameters.

Step 3: Commit—Once parameters are locked, the computer sends a Commit command “Let’s go with this configuration.” The camera prepares the data stream accordingly.

Step 4: Streaming Begins—The computer issues a SET_INTERFACE command to activate the video stream. The camera begins delivering frames via USB Isochronous transfer mode.

A quick technical aside—USB has four transfer modes: Control, Bulk, Interrupt, and Isochronous. Video streams use Isochronous mode—it reserves a fixed bandwidth slot, doesn’t guarantee 100% data delivery (lost packets stay lost), but guarantees temporal continuity. This is perfect for video and audio: real-time data where dropping a frame or two is acceptable, but stuttering absolutely is not.

The entire Probe-Commit process typically completes within tens of milliseconds. So in those few seconds between “plug in the camera” and “Zoom shows the picture,” a remarkably complex handshake is taking place. None of it requires you to install a driver or change any setting—that’s the power of the UVC standard.

UAC: Audio Takes a Similar but Simpler Path

Audio transmission logic is nearly symmetric to video, but much simpler—because audio data is so much smaller.

Uncompressed CD-quality audio (44.1kHz / 16bit / stereo) is only about 1.4 Mbps. Even professional 24bit / 192kHz stereo is just 9 Mbps. That’s a rounding error on any generation of USB—so UAC almost always runs uncompressed PCM raw audio, with no need for complex compression formats.

UAC’s negotiation process mirrors UVC—enumeration, reading the list of supported sample rates / bit depths / channel counts, confirming configuration, beginning Isochronous transfer.

This is why USB microphones and audio interfaces have even better compatibility than USB cameras—the format is simple, bandwidth is plentiful, the protocol is mature, and “negotiation failed” is essentially never a problem.

How Many Layers of Invisible Engineering We Stand On

Looking back at everything in this article—Bandwidth, compression formats, encoding trade-offs, negotiation protocols—every detail represents engineers in some conference room arguing for years, sometimes decades. When you open Zoom today and the picture pops up, what actually happened is:

• The camera’s ISP converted raw sensor signal into YUV
• The camera’s encoding chip compressed YUV into MJPEG
• The camera’s USB controller packetized the MJPEG into UVC-standard Isochronous packets
• The USB physical layer transmitted the packets through the USB-C cable to your computer
• Your computer’s USB controller received the data, the OS parsed it per UVC standards
• The OS decoded each JPEG frame back to YUV
• The conferencing app took the YUV, applied color processing and scaling, and encoded the result as H.264 to send over the network

All of this happens within 200 milliseconds of you clicking “Join Meeting.”

USB audio and video—from cable plugged in to picture appearing—is the combined work of bandwidth engineering, coding theory, protocol standards, and OS integration, layered together by a civilization of engineering. Every “just works” experience you enjoy is standing on layers and layers of invisible labor.

Next time, we shift from “capture” to “output”—When your computer needs to send a picture out to an external display or projector, what does USB do? Why do today’s USB-C monitors and USB-C docks “just output picture”? What is DP Alt Mode? And what about that less-known scheme called DisplayLink—how does it work?

USB carries audio and video both in and out. “In” is done. Next: “out.”