# Cable Desk

> The sensor does not decide the format — the link does. Uncompressed video is
> `width x height x bitsPerPixel / 8 x fps` and nothing else, so 1920x1080 at 30 fps in
> yuy2 is 995.3 Mbps (124.4 MB/s) whether the picture is a test card or a wedding. **And the
> number on the link is not the number a camera gets**: USB 2.0 signals at 480 Mbps, but a camera reserves an ISOCHRONOUS endpoint and the
> specification caps one at 1024 bytes x 3 transactions per 125 µs microframe — 3,072 x 8,000 = **196.6 Mbps (24.6 MB/s)**, or 41% of the number
> on the box. So 1080p30 uncompressed is 5.06x what a USB 2.0 camera
> can ever have, and every 1080p webcam that works on one is compressing. THE THREE WAYS
> OUT ARE ALL DIVISIONS: half the frame rate is 2x, 4:2:2 to 4:2:0 is 1.33x and half each side is 4x because area goes as the SQUARE.
> **A hub is not a multiplier** and **a memory format is not a wire format**.

## The one thing to know

**THE SENSOR DOES NOT DECIDE THE FORMAT. THE LINK DOES.**

```text
rate      = width * height * bitsPerPixel / 8 * fps      bytes per second
frame     = width * height * bitsPerPixel / 8            bytes
budget    = the link's USABLE rate, less anything already reserved
fits      = sum of the feeds' rates <= budget
fps fits  = budget / frame                               <- the frame-rate cut
scale fits= sqrt(budget / rate)                          <- BOTH axes, so a square root
ratio     = rate / budget                                <- the compression cut
```

There is no quality term anywhere in those seven lines. What a mode costs is decided by
its four numbers and by nothing else.

**THE NUMBER ON THE LINK IS NOT THE NUMBER A CAMERA GETS.** USB 2.0 is marked 480 Mbps and a camera can reserve 196.6 Mbps (24.6 MB/s) — 41%. The cap is 3,072 bytes per 125 µs microframe, written into
the specification, and no cable, driver or controller changes it. 1080p30 in yuy2 is 995.3 Mbps (124.4 MB/s) against that budget — 5.06x over — and uncompressed
the link carries that picture at 5.93 fps.

**THREE FACTORS, THREE DIVISIONS, AND ONLY THE PRODUCT MATTERS.** A shortfall can be
paid in pixels, in frames or in bits per pixel. Halving the frame rate divides by 2x; 4:2:2 to 4:2:0 divides by 1.33x and changes neither the size nor the motion;
halving each side divides by 4x, because area goes as the SQUARE of the
scale. Resolution is what people reach for first and it is the largest cut available.

**A HUB IS NOT A MULTIPLIER.** Everything downstream of one competes for the same
upstream reservation, so a second camera on the same controller does not get its own 196.6 Mbps (24.6 MB/s) — the two of them split it. That is the commonest reason a rig that worked
with one camera renegotiates both of them down when the second is plugged in.

**AND A MEMORY FORMAT IS NOT A WIRE FORMAT.** `v210` writes six ten-bit pixels into
sixteen bytes so they align on 32-bit words: 21.33 bits a pixel where the picture needs 20 bits a pixel. That 6.67% of padding carries nothing,
and on a 3G-SDI link carrying 1080p59.94 it is exactly the difference between fitting —
by 2.49 Mbps — and not.

## What each link can actually reserve

| Link | Marked | A feed can reserve | Share | Why the gap |
| --- | --- | --- | --- | --- |
| USB 2.0 high speed | 480 Mbps | **196.6 Mbps** | 41% | A camera reserves an ISOCHRONOUS endpoint, and the spec caps a high-speed isochronous endpoint at 1024 bytes x 3 transactions per 125 us microframe. |
| USB 3.0 / 3.1 Gen 1 (5 Gbps) | 5000 Mbps | **3600 Mbps** | 72% | 5 Gbps of 8b/10b line coding is 4 Gbps of payload before any protocol, and a real isochronous or bulk stream lands near 90% of that. |
| USB 3.1 Gen 2 / 3.2 (10 Gbps) | 10000 Mbps | **8727 Mbps** | 87.3% | 10 Gbps with 128b/132b coding is 9.70 Gbps of payload, and about 90% of that survives protocol overhead. |
| HDMI 1.4 (TMDS) | 10200 Mbps | **8160 Mbps** | 80% | TMDS is 8b/10b, so 10.2 Gbps of signalling carries 8.16 Gbps of video - and that has to cover blanking as well as active picture. |
| HDMI 2.0 (TMDS) | 18000 Mbps | **14400 Mbps** | 80% | 18 Gbps of TMDS signalling, 8b/10b coded, is 14.4 Gbps of video. |
| HDMI 2.1 (FRL) | 48000 Mbps | **42667 Mbps** | 88.9% | FRL replaces TMDS with 16b/18b coding across four lanes, so 48 Gbps of signalling carries 42.67 Gbps of video. |
| HD-SDI (1.5G) | 1485 Mbps | **1244 Mbps** | 83.8% | SDI carries the WHOLE RASTER, blanking included. |
| 3G-SDI | 2970 Mbps | **2488 Mbps** | 83.8% | Twice HD-SDI, with the same 83.8% active fraction on an HD raster. |
| 6G-SDI | 5940 Mbps | **4977 Mbps** | 83.8% | Four times HD-SDI. |
| 12G-SDI | 11880 Mbps | **9953 Mbps** | 83.8% | Eight times HD-SDI, and the usual single-link 2160p59.94 carrier. |
| Gigabit Ethernet | 1000 Mbps | **940 Mbps** | 94% | Frame headers, preamble and interframe gap cost about 6% at a 1500 byte MTU, so a gigabit link carries roughly 940 Mbps of payload. |
| 10 Gigabit Ethernet | 10000 Mbps | **9400 Mbps** | 94% | The same 6% framing overhead, ten times over. |

**USB 2.0 is the one worth staring at.** 480 Mbps on the box, 196.6 Mbps (24.6 MB/s) to a camera: 41%. The cap is 3,072 bytes per 125 µs microframe, written into the specification, and no cable, driver or controller changes it.

## What each pixel format costs

| Format | Chroma | Depth | Bits a pixel | Against 4:2:2 | 1080p30 |
| --- | --- | --- | --- | --- | --- |
| `y8` | mono | 8-bit | 8 bits a pixel | 0.5x | 497.7 Mbps |
| `nv12` | 4:2:0 | 8-bit | 12 bits a pixel | 0.75x | 746.5 Mbps |
| `raw12` | bayer | 12-bit | 12 bits a pixel | 0.75x | 746.5 Mbps |
| `yuy2` | 4:2:2 | 8-bit | 16 bits a pixel | 1x | 995.3 Mbps |
| `sdi10` | 4:2:2 | 10-bit | 20 bits a pixel | 1.25x | 1244 Mbps |
| `v210` | 4:2:2 | 10-bit | 21.33 bits a pixel | 1.33x | 1327 Mbps |
| `rgb24` | 4:4:4 | 8-bit | 24 bits a pixel | 1.5x | 1493 Mbps |
| `rgb32` | 4:4:4 | 8-bit | 32 bits a pixel | 2x | 1991 Mbps |

The whole range is a factor of 4x and none of it is a quality setting: these are packing facts. Between the two formats a webcam most often offers — `yuy2` and `nv12` — there is a factor of 1.33x, bought by halving the chroma vertically as well as horizontally.

## The common modes, priced

| Mode, in `yuy2` | Rate | On USB 2.0 | On USB 3.0 |
| --- | --- | --- | --- |
| 640 x 480 at 30 fps | 147.5 Mbps | fits, 75% | fits, 4.1% |
| 1,280 x 720 at 30 fps | 442.4 Mbps | **2.25x over** | fits, 12.3% |
| 1,280 x 720 at 60 fps | 884.7 Mbps | **4.5x over** | fits, 24.6% |
| 1,920 x 1,080 at 30 fps | 995.3 Mbps | **5.06x over** | fits, 27.6% |
| 1,920 x 1,080 at 60 fps | 1991 Mbps | **10.1x over** | fits, 55.3% |
| 3,840 x 2,160 at 30 fps | 3981 Mbps | **20.3x over** | **1.11x over** |

**Only the smallest mode on that list fits USB 2.0 uncompressed.** 1080p30 in 4:2:2 is 995.3 Mbps (124.4 MB/s) against a budget of 196.6 Mbps (24.6 MB/s) — over by a factor of 5.06x. Every 1080p webcam that works on a USB 2.0 port is compressing, whatever its box says.

## The three cuts, priced against each other

| Cut | Rate | Divides by | What it costs |
| --- | --- | --- | --- |
| nothing | 995.3 Mbps | — | the mode as asked for |
| half the frame rate | 497.7 Mbps | **2x** | 30 fps to 15 fps, same picture |
| 4:2:2 to 4:2:0 | 746.5 Mbps | **1.33x** | 16 bits a pixel to 12 bits a pixel, same size and rate |
| 1080p to 720p | 442.4 Mbps | **2.25x** | 1,920 x 1,080 to 1,280 x 720 |
| half each side | 248.8 Mbps | **4x** | both axes, so area goes as the square |
| colour to mono | 497.7 Mbps | **2x** | 16 bits a pixel to 8 bits a pixel |

**Halving each side of the picture costs a factor of 4x and halving the frame rate costs 2x.** Area goes as the square of the scale, which is why the cut people reach for first is the largest one available and rarely the one they meant to make. Dropping 4:2:2 to 4:2:0 buys 1.33x and changes nothing about the picture's size or its motion.

## What a USB 2.0 reservation carries

| Size | In `yuy2` | In `nv12` | In `y8` |
| --- | --- | --- | --- |
| 1,920 x 1,080 | 5.93 fps | 7.9 fps | 11.9 fps |
| 1,280 x 720 | 13.3 fps | 17.8 fps | 26.7 fps |
| 960 x 540 | 23.7 fps | 31.6 fps | 47.4 fps |
| 640 x 480 | 40 fps | 53.3 fps | 80 fps |
| 320 x 240 | 160 fps | 213.3 fps | 320 fps |

The frame rate a 196.6 Mbps (24.6 MB/s) reservation carries, uncompressed. **1080p does not reach 15 fps in any format here**, and 640 x 480 in `yuy2` — the mode every webcam has offered since 2005 — lands at 40 fps, which is why that mode is the one that always works.

## A memory format is not a wire format

| | On the wire (`sdi10`) | In memory (`v210`) |
| --- | --- | --- |
| bits a pixel | 20 bits a pixel | 21.33 bits a pixel |
| 1,920 x 1,080 at 59.9 fps | 2486 Mbps | 2652 Mbps |
| against 3G-SDI's 2488 Mbps | **fits, by 2.49 Mbps** | **over by 163.2 Mbps** |

**The same picture, and only one of them fits.** `v210` writes six pixels into sixteen bytes so ten-bit samples land on 32-bit word boundaries; the padding is 6.67% of the rate and it carries nothing. 3G-SDI was specified for this exact signal and it fits by 2.49 Mbps — about 0.1% of the link — so there is no room anywhere for a memory layout's convenience.

## Thresholds

| Constant | Value | What it decides |
| --- | --- | --- |
| USB 2.0 isochronous cap | 3,072 bytes per microframe | the whole USB 2.0 budget: x 8,000 microframes a second = 196.6 Mbps (24.6 MB/s) |
| tight | 85% of the budget | above this a link that fits is reported as having no room |
| roomy | 50% of the budget | below this there is room for another feed of the same size |
| credible motion JPEG | 20:1 | a required ratio past this is reported as not a setting to hunt for |
| assumed motion JPEG | 10:1 | used when a compressed feed states no ratio, and always reported |
| assumed frame rate | 30 fps | used when a FEEDS row leaves it out, and always reported |
| assumed format | `yuy2` (16 bits a pixel) | used when a FEEDS row leaves it out, and always reported |

**Every one of these is load-bearing and the harness proves it** by moving each one and requiring the report to move with it. The USB 2.0 figure is not a tuning parameter — it is a number written into the specification, and it is in this table so that a reader can check it rather than take it on trust.

## Sheet grammar

Two blocks. `LINK` is `key | value`, one per line. `FEEDS` is a table.

```
LINK
name      | the two-camera interview rig
bus       | usb2       usb2, usb3, usb3.2, hdmi2.0, sdi-3g, gige, 10gige...
reserved  | 20 mbps    optional: a rate already spoken for by something else

FEEDS
f1 | the presenter camera | 1920x1080 | 30 | yuy2     |
f2 | the wide             | 1280x720  | 30 | mjpeg@10 | why this one is here
```

A FEEDS row is `id | what it is | resolution | fps | format | why`. The frame rate, the format and the why are optional; the id, the description and the resolution are not.

**EVERY FEED ON THE SHEET SHARES ONE RESERVATION.** The feeds are the devices. A hub does not add capacity, so two cameras on one controller are two rows against one budget — which is the arithmetic this page exists to make visible.

**A resolution is `1920x1080`**, or a shorthand naming a height — `720p`, `1080p`, `4k`. The shorthand assumes 16:9 and says so, because being wrong about the width is being wrong about the rate by the same factor.

**A format is a fourcc** — `yuy2`, `nv12`, `rgb24`, `rgb32`, `sdi10`, `v210`, `y8`, `raw12` — **or a compressed name with an optional ratio**: `mjpeg`, `mjpeg@10`, `h264@40`. A ratio on an uncompressed format is ignored and reported rather than quietly divided in.

**A bus is a name from the table, or a rate outright** — `2.5 gbps`, `400 mbps`. A rate given outright is taken at face value: this page has no idea what coding or protocol overhead it already includes, so it assumes none and says so.

**`reserved` is a rate, not a device count.** It is whatever already has a claim on this link and is not a row on the sheet: a drive, an audio interface, a capture device somebody forgot. It comes off the top.

## Lanes

- **`plan`** — Choose the mode from the link, not the sensor. A rig gets specified by picking the best mode each camera offers and discovering afterwards that the bus cannot carry them. This works the other way: start from the link, work out what it can actually reserve, and spend that budget across the feeds on purpose — in frames, in pixels and in bits per pixel, whichever of the three costs least.
  Sections: Summary, The Sheet, The Setting, Reasoning, Next Step.
- **`check`** (primary) — Whether these feeds fit the link they are on. The paid read of what the free panel computes. Every feed's rate from the four numbers that make it, the link's real reservation as against the number on its box, the sum against the budget, and — when it does not fit — which of the three cuts is cheapest for this particular rig.
  Sections: Summary, Verdict, Findings, Corrected Sheet, Next Step.
- **`budget`** — The budget question: what the link can actually reserve. The number on the box is a signalling rate and the number a camera gets is a reservation, and on USB 2.0 they differ by more than half. This reads the link on its own: what it is marked, what it loses and to what, what is left, and how much of that these feeds are asking for.
  Sections: Summary, What The Link Reserves, Where The Bytes Go, What Is Left, Next Step.
- **`cuts`** — The cut question: three ways to divide the same number. Pixels, frames and bits per pixel are independent factors of one product, so a shortfall can be paid in any of them and only the product matters. This prices all three on your own feeds — including the ones nobody offers to make, like dropping 4:2:2 to 4:2:0 for a factor of a third at no visible cost on most material.
  Sections: Summary, Feed By Feed, What Each Cut Buys, What Fits, Next Step.
- **`deliver`** — Decide what changes: a mode, a link, or nothing. Sorts every finding into what a mode change fixes, what only a different link fixes, and what nothing fixes. The third bucket is the honest one: a compression ratio nobody achieves and a bus that is already full are not problems to solve, and saying so is the point.
  Sections: Summary, A Mode Change Fixes, Only A Different Link Fixes, Nothing Fixes, Next Step.

## Findings

All 31 are computed in the browser and cost nothing.

| Code | Severity | Scope | What it says |
| --- | --- | --- | --- |
| `NO-FEEDS` | error | link | No feeds, so there is nothing to weigh against the link |
| `RESOLUTION-NOT-POSITIVE` | error | feed | A picture with no width or no height |
| `FRAME-RATE-NOT-POSITIVE` | error | feed | A frame rate of zero or less |
| `USB2-RESERVES-A-FRACTION` | warn | link | USB 2.0 is marked 480 Mbps and a camera can reserve 196.6 |
| `LINK-IS-OVERSUBSCRIBED` | warn | link | The feeds want more than the link can give |
| `FEED-ALONE-EXCEEDS-THE-LINK` | warn | feed | This feed does not fit even with the link to itself |
| `LINK-IS-TIGHT` | warn | link | It fits, with very little left |
| `BUS-ASSUMED` | warn | link | No bus was given, so the budget is a guess |
| `FORMAT-ASSUMED` | warn | feed | No pixel format, so the bits per pixel were assumed |
| `FRAME-RATE-ASSUMED` | warn | feed | No frame rate, so one was assumed |
| `ASPECT-ASSUMED` | warn | feed | A shorthand resolution assumed 16:9 |
| `COMPRESSION-RATIO-ASSUMED` | warn | feed | A compressed feed's ratio was assumed rather than stated |
| `RATIO-IS-NOT-CREDIBLE` | warn | feed | Fitting would need a compression ratio nobody gets |
| `STRAY-RATIO-IGNORED` | warn | feed | A compression ratio was given for an uncompressed format |
| `THE-LINK-RESERVES` | note | link | What the link is marked, and what a feed can actually have |
| `SOMETHING-ELSE-IS-ALREADY-ON-IT` | note | link | Part of the link is already spoken for |
| `FEEDS-SHARE-ONE-BUDGET` | note | link | The feeds on this link share one reservation |
| `TOTAL-DEMAND` | note | link | What the feeds add up to |
| `HEADROOM-LEFT` | note | link | What is left after these feeds |
| `ROOM-FOR-ANOTHER` | note | link | How many more feeds like the largest one would fit |
| `FEED-RATE` | note | feed | The rate, and the four numbers it comes from |
| `A-FRAME-IS-THIS-BIG` | note | feed | One frame, in bytes |
| `FORMAT-COSTS` | note | feed | What this pixel format costs, and why |
| `FULL-CHROMA-COSTS-HALF-AGAIN` | note | feed | Full chroma is half again what 4:2:2 costs |
| `TEN-BIT-IS-A-THIRD-MORE` | note | feed | Ten-bit 4:2:2 is a quarter more than eight-bit |
| `PADDING-IS-NOT-PICTURE` | note | feed | This packing pads, and the padding travels |
| `THE-THREE-CUTS` | note | feed | Three ways to divide the same number |
| `FRAME-RATE-THAT-FITS` | note | feed | The frame rate this size and format would fit at |
| `SCALE-THAT-FITS` | note | feed | How much smaller the picture would have to be |
| `RATIO-NEEDED` | note | feed | The compression ratio that would make this fit |
| `COMPRESSION-IS-NOT-ARITHMETIC` | note | feed | A compressed feed's rate is the encoder's choice, not this page's |

## What this page cannot do

This page computes from the numbers on the sheet. It has not measured anything and it has not talked to a device.

- **The bus figures are ceilings, not throughput.** They are what the specifications allow a video stream to reserve. A real controller, a real driver, a long cable or a busy host can all deliver less; none of them will deliver more.
- **Only isochronous transfer is modelled on USB.** A camera can also use bulk transfer, which is not rate-guaranteed but is not capped at 196.6 Mbps (24.6 MB/s) either — it takes what is spare. Some capture devices do exactly that, and this page's USB figures are the wrong ones for them.
- **A compressed rate is the encoder's choice, not arithmetic.** Motion JPEG's ratio depends on the quality setting and on the picture itself. Every figure derived from a stated or assumed ratio is as good as that ratio and is marked as such.
- **The SDI active fraction is the HD one** — (1920/2200) x (1080/1125) — applied to every SDI rate here including the UHD carriers, whose rasters differ slightly. It is an approximation and it is stated rather than hidden behind a raster table this page cannot check.
- **Audio, metadata, ancillary data and control traffic are not counted.** Embedded audio on SDI, HDMI's data islands and a camera's own control endpoint all take a small share that is not on this sheet.
- **Nothing here knows about a controller's own limits.** A host may have fewer endpoints, less buffer or a shared root hub than the bus standard allows, and those failures look exactly like the arithmetic ones.
- **A link that fits is not a link that works.** Cable quality, connector wear, power delivery and driver bugs are all outside this model and all produce dropped frames that look like bandwidth.
- Nothing here reaches the network, reads a file, or opens a device.

## API

`POST https://api.skillsafe.ai/v1/app-api/run` with a bearer token from
https://cable-desk.skillsafe.ai/tokens.html. The body IS the input object — there is no
`input` wrapper and no `X-App-Slug` header. `task` is required and must be one of plan, check, budget, cuts, deliver. `POST /estimate` is free and validates the same body.
Full documentation at https://cable-desk.skillsafe.ai/api.html.

## Provenance

Lanes derived from the `camsnap` skill in https://github.com/steipete/clawdis.
The arithmetic, thresholds, sheet grammar and findings are this app's own.
Not affiliated with or endorsed by the authors of that repository.