{"id":76614,"date":"2026-07-03T14:00:46","date_gmt":"2026-07-03T06:00:46","guid":{"rendered":"https:\/\/www.kiloview.com\/en\/?p=76614"},"modified":"2026-07-03T14:00:49","modified_gmt":"2026-07-03T06:00:49","slug":"usb-audio-video-whats-actually-streaming-through-your-usb-webcam","status":"publish","type":"post","link":"https:\/\/www.kiloview.com\/en\/usb-audio-video-whats-actually-streaming-through-your-usb-webcam\/","title":{"rendered":"USB Audio &amp; Video 02: What&#8217;s Actually Streaming Through Your USB Webcam?"},"content":{"rendered":"\n<style data-wp-block-html=\"css\">\n.article-toc {\n  margin: 32px 0;\n  padding: 24px 28px;\n  background: #f7f8fa;\n  border-left: 4px solid #222;\n  border-radius: 4px;\n}\n\n.article-toc__title {\n  margin-bottom: 14px;\n  font-size: 20px;\n  font-weight: 700;\n}\n\n.article-toc ol {\n  margin: 0;\n  padding-left: 22px;\n}\n\n.article-toc li {\n  margin: 8px 0;\n  line-height: 1.5;\n}\n\n.article-toc a {\n  color: inherit;\n  text-decoration: none;\n}\n\n.article-toc a:hover {\n  text-decoration: underline;\n}\n\nhtml {\n  scroll-behavior: smooth;\n}\n\nh2[id] {\n  scroll-margin-top: 100px;\n}\n<\/style>\n\n<nav class=\"article-toc\" aria-label=\"Table of Contents\">\n  <div class=\"article-toc__title\">Table of Contents<\/div>\n  <ol>\n    <li>\n      <a href=\"#counter-intuitive-question\">A Counter-Intuitive Question<\/a>\n    <\/li>\n    <li>\n      <a href=\"#usb-bandwidth\">USB Bandwidth: The Hard Constraint<\/a>\n    <\/li>\n    <li>\n      <a href=\"#uvc-video-formats\">UVC Video Formats: A Spectrum from Raw to Compressed<\/a>\n    <\/li>\n    <li>\n      <a href=\"#rgb-yuv\">RGB \/ YUV: Uncompressed, Pristine, Massive<\/a>\n    <\/li>\n    <li>\n      <a href=\"#mjpeg\">MJPEG: The Real Workhorse of High-Resolution USB Video Today<\/a>\n    <\/li>\n    <li>\n      <a href=\"#h264-h265\">H.264 \/ H.265: Beautiful in Theory, Awkward in Practice<\/a>\n    <\/li>\n    <li>\n      <a href=\"#uvc-negotiation\">The &#8220;Conversation&#8221; Between Device and Computer: UVC Negotiation<\/a>\n    <\/li>\n    <li>\n      <a href=\"#uac-audio\">UAC: Audio Takes a Similar but Simpler Path<\/a>\n    <\/li>\n    <li>\n      <a href=\"#invisible-engineering\">How Many Layers of Invisible Engineering We Stand On<\/a>\n    <\/li>\n  <\/ol>\n<\/nav>\n\n\n\n<h2 id=\"counter-intuitive-question\">A Counter-Intuitive Question<\/h2>\n\n\n\n<p>Picking up where the last part left off\u2014you 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\u00d71080 frame?<\/p>\n\n\n\n<p>Your first guess might be: &#8220;It&#8217;s just a picture, right?&#8221; But it&#8217;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 \u00d7 1080 \u00d7 24 bit \u00d7 30 frames \u2248 1.49 Gbps.<\/p>\n\n\n\n<p>A typical USB 2.0 cable has a theoretical bandwidth of 480 Mbps\u2014that&#8217;s 0.48 Gbps. Mathematically, raw 1080p 30fps simply doesn&#8217;t fit through USB 2.0. And yet in reality, USB 2.0 webcams from the early 2010s were happily running 1080p. How?<\/p>\n\n\n\n<p>That&#8217;s what this article is about: what formats are actually flowing through USB cameras, the bandwidth game they&#8217;re playing against USB, and what a UVC camera &#8220;negotiates&#8221; with your computer the moment it&#8217;s plugged in.<\/p>\n\n\n\n<h2 id=\"usb-bandwidth\">USB Bandwidth: The Hard Constraint<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<figure class=\"wp-block-table aligncenter\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>USB Version<\/strong><\/td><td><strong>Commercial Name<\/strong><\/td><td><strong>Theoretical Bandwidth<\/strong><\/td><td><strong>Practical Bandwidth<\/strong><\/td><\/tr><tr><td>USB 1.1<\/td><td>Full Speed<\/td><td>12 Mbps<\/td><td>~8 Mbps<\/td><\/tr><tr><td>USB 2.0<\/td><td>High Speed<\/td><td>480 Mbps<\/td><td>~320 Mbps<\/td><\/tr><tr><td>USB 3.0 \/ 3.2 Gen 1<\/td><td>SuperSpeed<\/td><td>5 Gbps<\/td><td>~3.2 Gbps<\/td><\/tr><tr><td>USB 3.2 Gen 2<\/td><td>SuperSpeed+<\/td><td>10 Gbps<\/td><td>~7.2 Gbps<\/td><\/tr><tr><td>USB 3.2 Gen 2\u00d72<\/td><td>SuperSpeed 20Gbps<\/td><td>20 Gbps<\/td><td>~14 Gbps<\/td><\/tr><tr><td>USB 4 \/ Thunderbolt 3, 4<\/td><td>USB4 \/ Thunderbolt<\/td><td>40 Gbps<\/td><td>~30 Gbps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>About &#8220;practical bandwidth&#8221;\u2014USB 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 &#8220;it won&#8217;t transmit.&#8221; They&#8217;ve forgotten the protocol overhead.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4-1024x576.jpg\" alt=\"\" class=\"wp-image-76632\" srcset=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4-300x169.jpg 300w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4-1024x576.jpg 1024w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4-768x432.jpg 768w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4-1536x864.jpg 1536w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog-02-4.jpg 1672w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>Now let&#8217;s go back to that 1.49 Gbps for raw 1080p\u2014<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>USB 2.0 has ~320 Mbps of usable bandwidth. Doesn&#8217;t fit\u2014short by nearly 5x.<\/li>\n\n\n\n<li>USB 3.0 has ~3.2 Gbps. Fits, but already eats more than half the pipe.<\/li>\n\n\n\n<li>4K 60fps raw is roughly 12 Gbps\u2014doesn&#8217;t even fit USB 3.0. You need USB 3.2 Gen 2 or above.<\/li>\n<\/ul>\n\n\n\n<p>This is why USB cameras almost never transmit raw frames. To fit &#8220;looks clear enough&#8221; video into limited USB bandwidth, there&#8217;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\u2014covering different bandwidth-vs-quality trade-offs.<\/p>\n\n\n\n\n\n<h2 id=\"uvc-video-formats\">UVC Video Formats: A Spectrum from Raw to Compressed<\/h2>\n\n\n\n<p>UVC defines several video formats (called &#8220;Payload Formats&#8221; in UVC terminology). Let&#8217;s walk through the most important ones:<\/p>\n\n\n\n<h3 id=\"rgb-yuv\">RGB \/ YUV: Uncompressed, Pristine, Massive<\/h3>\n\n\n\n<p>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\u2014no information loss, the PC receives data ready to display, the CPU barely has to decode anything. But the downside is just as direct\u2014massive 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.<\/p>\n\n\n\n<p>This means RGB \/ YUV in USB cameras is only practical for low resolution or low frame rate:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>USB 2.0 cameras running YUV typically max out at 640\u00d7480 30fps or 1280\u00d7720 15fps<\/li>\n\n\n\n<li>USB 3.0 cameras running YUV can hit 1080p 30fps, but it&#8217;s the ceiling<\/li>\n\n\n\n<li>4K YUV? You need USB 3.2 Gen 2 or above, and it&#8217;s effectively limited to industrial cameras<\/li>\n<\/ul>\n\n\n\n<p>The vast majority of consumer USB cameras do not use RGB \/ YUV at high resolutions.<\/p>\n\n\n\n<h3 id=\"mjpeg\">MJPEG: The Real Workhorse of High-Resolution USB Video Today<\/h3>\n\n\n\n<p>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:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Significant compression\u2014typically 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&#8217;s reach.<\/li>\n\n\n\n<li>Frame-independent\u2014no inter-frame prediction, no B-frames or P-frames. Every frame is complete on its own.<\/li>\n\n\n\n<li>Trivially easy to decode\u2014JPEG is a thirty-year-old mature technology. Every OS, every platform has hardware-accelerated or assembly-optimized decoders. CPU usage is essentially negligible.<\/li>\n\n\n\n<li>Extremely low latency\u2014each 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).<\/li>\n<\/ul>\n\n\n\n<p>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&#8217;s quality, MJPEG needs significantly higher bitrate. But in the USB camera context, this turns out to be an advantage\u2014USB bandwidth is generous (USB 3.0 has 3.2 Gbps available). CPU time is the scarce resource (the conferencing app is already eating CPU).<\/p>\n\n\n\n<p>So &#8220;spend more bandwidth to save CPU&#8221; is exactly the right trade-off. That&#8217;s why virtually every USB camera supporting 1080p or higher today uses MJPEG as the primary format\u2014it&#8217;s the optimal balance between bandwidth, quality, CPU, and latency in this specific environment.<\/p>\n\n\n\n<p>A special note on 4K: nearly every USB camera that claims to support 4K is sending MJPEG. The reasons are exactly what we&#8217;ve covered: 4K YUV is too large, 4K H.264 is too CPU-intensive (we&#8217;ll explain below), and only MJPEG can deliver 4K into a PC at reasonable CPU cost.<\/p>\n\n\n\n\n\n<h3 id=\"h264-h265\">H.264 \/ H.265: Beautiful in Theory, Awkward in Practice<\/h3>\n\n\n\n<p>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\u2014nearly 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\u2014it compresses 5~10x better than MJPEG. At equivalent quality, it needs only one-fifth to one-tenth the bandwidth. <\/p>\n\n\n\n<p>But in practice, H.264 is not the mainstream choice for USB cameras. Several reasons:<\/p>\n\n\n\n<p>First, CPU decoding overhead. H.264 decoding is substantially more complex than JPEG\u2014inter-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\u2014and how efficiently\u2014is not guaranteed, especially on Windows, where different apps have wildly varying hardware acceleration support.<\/p>\n\n\n\n<p>Second, latency. H.264 uses B-frames (bidirectionally predicted frames) to improve compression\u2014but 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 &#8220;low-latency mode&#8221; (I+P frames only, no B-frames), but that sacrifices compression efficiency.<\/p>\n\n\n\n<p>Third, the bitrate-vs-quality sweet spot is different. H.264&#8217;s real &#8220;crushing&#8221; of MJPEG happens at low bitrates (say, 1080p at 2 Mbps). But in USB camera scenarios, bandwidth isn&#8217;t the bottleneck. Since bandwidth is plentiful, &#8220;30 Mbps MJPEG&#8221; and &#8220;5 Mbps H.264&#8221; deliver nearly identical final quality\u2014but the former uses less CPU and has lower latency.<\/p>\n\n\n\n<p>Fourth, OS-side support depth. Windows DirectShow \/ Media Foundation&#8217;s support for UVC H.264 is far less &#8220;just works&#8221; than its MJPEG support. Some conferencing apps run into compatibility issues with H.264 UVC devices.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>The future? There hasn&#8217;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\u2014because &#8220;simple&#8221; is exactly the right virtue in the USB context.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1-1024x576.jpg\" alt=\"\" class=\"wp-image-76633\" srcset=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1-300x169.jpg 300w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1-1024x576.jpg 1024w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1-768x432.jpg 768w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1-1536x864.jpg 1536w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-1.jpg 1672w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 id=\"uvc-negotiation\">The &#8220;Conversation&#8221; Between Device and Computer: UVC Negotiation<\/h2>\n\n\n\n<p>Finally, let&#8217;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:<\/p>\n\n\n\n<p><strong>Step 1: Enumeration<\/strong>\u2014The computer uses the standard USB &#8220;device descriptor&#8221; mechanism to ask: &#8220;Who are you?&#8221; The device replies: &#8220;I&#8217;m a UVC class device (Class Code 0x0E), version 1.5.&#8221; The computer then reads the device&#8217;s &#8220;video stream interface descriptor&#8221;\u2014getting the full list of supported formats, resolutions, and frame rate combinations. Something like:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>MJPEG \u00b7 3840\u00d72160 \u00b7 30fps<\/li>\n\n\n\n<li>MJPEG \u00b7 1920\u00d71080 \u00b7 60fps<\/li>\n\n\n\n<li>YUV422 \u00b7 1280\u00d7720 \u00b7 30fps<\/li>\n\n\n\n<li>\u2026<\/li>\n<\/ul>\n\n\n\n<p>This list is the camera&#8217;s &#8220;capability menu.&#8221;<\/p>\n\n\n\n<p><strong>Step 2: Probe<\/strong>\u2014The conferencing app (say, Zoom) tells the OS: &#8220;Give me 1920\u00d71080 30fps MJPEG.&#8221; The OS translates this into a UVC Probe command and sends it to the camera. The camera replies: &#8220;Confirmed, I can do that combo.&#8221; Or: &#8220;I can&#8217;t do that exactly, but the closest option I support is XXXX.&#8221; <\/p>\n\n\n\n<p>This is a negotiation that both sides can go back and forth a few times until they agree on parameters.<\/p>\n\n\n\n<p><strong>Step 3: Commit<\/strong>\u2014Once parameters are locked, the computer sends a Commit command &#8220;Let&#8217;s go with this configuration.&#8221; The camera prepares the data stream accordingly. <\/p>\n\n\n\n<p><strong>Step 4: Streaming Begins<\/strong>\u2014The computer issues a SET_INTERFACE command to activate the video stream. The camera begins delivering frames via USB Isochronous transfer mode.  <\/p>\n\n\n\n<p>A quick technical aside\u2014USB has four transfer modes: Control, Bulk, Interrupt, and Isochronous. Video streams use Isochronous mode\u2014it reserves a fixed bandwidth slot, doesn&#8217;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.<\/p>\n\n\n\n<p>The entire Probe-Commit process typically completes within tens of milliseconds. So in those few seconds between &#8220;plug in the camera&#8221; and &#8220;Zoom shows the picture,&#8221; a remarkably complex handshake is taking place. None of it requires you to install a driver or change any setting\u2014that&#8217;s the power of the UVC standard.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2-1024x576.jpg\" alt=\"\" class=\"wp-image-76634\" srcset=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2-300x169.jpg 300w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2-1024x576.jpg 1024w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2-768x432.jpg 768w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2-1536x864.jpg 1536w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-2.jpg 1672w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n\n\n<h2 id=\"uac-audio\">UAC: Audio Takes a Similar but Simpler Path<\/h2>\n\n\n\n<p>Audio transmission logic is nearly symmetric to video, but much simpler\u2014because audio data is so much smaller.<\/p>\n\n\n\n<p>Uncompressed CD-quality audio (44.1kHz \/ 16bit \/ stereo) is only about 1.4 Mbps. Even professional 24bit \/ 192kHz stereo is just 9 Mbps. That&#8217;s a rounding error on any generation of USB\u2014so UAC almost always runs uncompressed PCM raw audio, with no need for complex compression formats.<\/p>\n\n\n\n<p>UAC&#8217;s negotiation process mirrors UVC\u2014enumeration, reading the list of supported sample rates \/ bit depths \/ channel counts, confirming configuration, beginning Isochronous transfer.<\/p>\n\n\n\n<p>This is why USB microphones and audio interfaces have even better compatibility than USB cameras\u2014the format is simple, bandwidth is plentiful, the protocol is mature, and &#8220;negotiation failed&#8221; is essentially never a problem.<\/p>\n\n\n\n<h2 id=\"invisible-engineering\">How Many Layers of Invisible Engineering We Stand On<\/h2>\n\n\n\n<p>Looking back at everything in this article\u2014Bandwidth, compression formats, encoding trade-offs, negotiation protocols\u2014every 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:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The camera&#8217;s ISP converted raw sensor signal into YUV<\/li>\n\n\n\n<li>The camera&#8217;s encoding chip compressed YUV into MJPEG<\/li>\n\n\n\n<li>The camera&#8217;s USB controller packetized the MJPEG into UVC-standard Isochronous packets<\/li>\n\n\n\n<li>The USB physical layer transmitted the packets through the USB-C cable to your computer<\/li>\n\n\n\n<li>Your computer&#8217;s USB controller received the data, the OS parsed it per UVC standards<\/li>\n\n\n\n<li>The OS decoded each JPEG frame back to YUV<\/li>\n\n\n\n<li>The conferencing app took the YUV, applied color processing and scaling, and encoded the result as H.264 to send over the network<\/li>\n<\/ul>\n\n\n\n<p>All of this happens within 200 milliseconds of you clicking &#8220;Join Meeting.&#8221;<\/p>\n\n\n\n<p>USB audio and video\u2014from cable plugged in to picture appearing\u2014is the combined work of bandwidth engineering, coding theory, protocol standards, and OS integration, layered together by a civilization of engineering. Every &#8220;just works&#8221; experience you enjoy is standing on layers and layers of invisible labor.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3-1024x576.jpg\" alt=\"\" class=\"wp-image-76635\" srcset=\"https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3-300x169.jpg 300w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3-1024x576.jpg 1024w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3-768x432.jpg 768w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3-1536x864.jpg 1536w, https:\/\/enstatic.kiloview.com\/wp-content\/uploads\/2026\/07\/usb-blog02-3.jpg 1672w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>Next time, we shift from &#8220;capture&#8221; to &#8220;output&#8221;\u2014When your computer needs to send a picture out to an external display or projector, what does USB do? Why do today&#8217;s USB-C monitors and USB-C docks &#8220;just output picture&#8221;? What is DP Alt Mode? And what about that less-known scheme called DisplayLink\u2014how does it work?<\/p>\n\n\n\n<p>USB carries audio and video both in and out. &#8220;In&#8221; is done. Next: &#8220;out.&#8221;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Table of Contents A Counter-Intuitive Question USB Band [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":76632,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[427,1],"tags":[],"class_list":["post-76614","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-all-resolurces","category-blog"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/posts\/76614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/comments?post=76614"}],"version-history":[{"count":15,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/posts\/76614\/revisions"}],"predecessor-version":[{"id":76789,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/posts\/76614\/revisions\/76789"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/media\/76632"}],"wp:attachment":[{"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/media?parent=76614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/categories?post=76614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kiloview.com\/en\/wp-json\/wp\/v2\/tags?post=76614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}