# Bitrate Desk

> A bitrate means nothing on its own. What decides whether a frame survives an encode is
> BITS PER PIXEL — bitrate divided by width times height times frame rate. YouTube's own
> 4K30 figure of 45 Mbps and X's 720p30 figure of 5 Mbps are both 0.1808 bits/px: nine
> times the bitrate, the same instruction to the encoder. YouTube's 1080p60 figure of 12 Mbps
> is 0.0965 bits/px, barely half of either, and it sits near the top of every list
> because the lists are sorted by bitrate.

## The one thing to know

**A BITRATE IS NOT A QUALITY.** Everything on this page follows from that.

```text
bits per pixel = bitrate / (width * height * fps)
```

Every bitrate is quoted per SECOND, and a second holds a different number of pixels in
every row of every recommendation table ever published. So the figures people compare
are not comparable.

YouTube's own figure for 4K30 is 45 Mbps — 0.1808 bits/px. X's figure
for 720p30 is 5 Mbps — 0.1808 bits/px. **The same number**, on 9× the
bitrate, because the 4K frame has 9× as many pixels to cover. And YouTube's own
1080p60 figure of 12 Mbps is 0.0965 bits/px — barely half of either,
and it sits near the top of every list because the lists are sorted by bitrate.

**The three things people do to make a video better all DIVIDE the budget.** A 1080p30
clip at 8 Mbps gets 0.1286 bits/px. At 60 fps, same bitrate: 0.0643 bits/px,
halved. Upscaled to 4K instead: 0.0322 bits/px, quartered.
To hold 0.1286 bits/px at 4K30 you need 32 Mbps.

**Upscaling is the worst of the three**, because it spends the whole budget describing
pixels that carry no information the master did not already have. Nothing downstream
recovers detail that was never recorded.

## The published recommendations, converted

| Recommendation | Frame | fps | Bitrate | Pixels a second | Bits per pixel |
| --- | --- | --- | --- | --- | --- |
| YouTube 4K30 | 3840×2160 | 30 | 45 Mbps | 248.83 Mpx | **0.1808 bits/px** |
| YouTube 4K60 | 3840×2160 | 60 | 68 Mbps | 497.66 Mpx | **0.1366 bits/px** |
| YouTube 1440p30 | 2560×1440 | 30 | 16 Mbps | 110.59 Mpx | **0.1447 bits/px** |
| YouTube 1080p30 | 1920×1080 | 30 | 8 Mbps | 62.21 Mpx | **0.1286 bits/px** |
| YouTube 1080p60 | 1920×1080 | 60 | 12 Mbps | 124.42 Mpx | **0.0965 bits/px** |
| YouTube 720p30 | 1280×720 | 30 | 5 Mbps | 27.65 Mpx | **0.1808 bits/px** |
| TikTok 1080x1920 | 1080×1920 | 30 | 10 Mbps | 62.21 Mpx | **0.1608 bits/px** |
| X 720p30 | 1280×720 | 30 | 5 Mbps | 27.65 Mpx | **0.1808 bits/px** |

**YouTube 4K30 at 45 Mbps and YouTube 720p30 at 5 Mbps are the same instruction to the encoder** — 0.1808 bits/px each, on 9× the bitrate, because the larger frame has 9× as many pixels to cover.

Ranked by bitrate the order is YouTube 4K60, YouTube 4K30, YouTube 1440p30, YouTube 1080p60, TikTok 1080x1920, YouTube 1080p30, YouTube 720p30, X 720p30.

Ranked by what each pixel actually gets it is YouTube 4K30, YouTube 720p30, X 720p30, TikTok 1080x1920, YouTube 1440p30, YouTube 4K60, YouTube 1080p30, YouTube 1080p60.

**These are not the same list.** The best-funded pixel on it is YouTube 4K30 at 0.1808 bits/px and the worst is YouTube 1080p60 at 0.0965 bits/px — 1.88× apart, from one recommendation page.

## What each choice costs

| At the same 8 Mbps | Frame | fps | Bits per pixel | Against leaving it alone | To hold 0.1286 bits/px |
| --- | --- | --- | --- | --- | --- |
| leave it alone | 1920×1080 | 30 | 0.1286 bits/px | 1× | 8 Mbps |
| raise it to 60 fps | 1920×1080 | 60 | 0.0643 bits/px | 0.5× | 16 Mbps |
| raise it to 1440p | 2560×1440 | 30 | 0.0723 bits/px | 0.56× | 14.2 Mbps |
| upscale it to 4K | 3840×2160 | 30 | 0.0322 bits/px | 0.25× | 32 Mbps |
| upscale to 4K AND 60 fps | 3840×2160 | 60 | 0.0161 bits/px | 0.13× | 64 Mbps |
| drop it to 720p | 1280×720 | 30 | 0.2894 bits/px | 2.25× | 3.56 Mbps |
| drop it to 24 fps | 1920×1080 | 24 | 0.1608 bits/px | 1.25× | 6.4 Mbps |

**Every one of the first five is something somebody does to make a video better.** All of them divide the budget the encoder has per pixel, and the two that raise the pixel count add no information at all: the master has what it has. The last column is the honest price of each choice.

## What a shape change throws away

| Target shape | Frame | A centre crop keeps | Pixels it leaves | The target wants | Enough? |
| --- | --- | --- | --- | --- | --- |
| 16:9, the master's own shape | 1920×1080 | **100%** | 8.29 Mpx | 2.07 Mpx | yes |
| 4:5, the feed portrait | 1080×1350 | **45%** | 3.73 Mpx | 1.46 Mpx | yes |
| 1:1, square | 1080×1080 | **56.3%** | 4.67 Mpx | 1.17 Mpx | yes |
| 9:16, full vertical | 1080×1920 | **31.6%** | 2.62 Mpx | 2.07 Mpx | yes |
| 2.39:1, scope | 1920×803 | **74.4%** | 6.17 Mpx | 1.54 Mpx | yes |

From a 3840×2160 master. **How much survives is arithmetic on the two aspect ratios, not a judgement about what is in the frame** — and a 9:16 cut from 16:9 keeps under a third of it whatever the subject is doing. That is why a vertical version is a reframe rather than an export setting. Every target here still fits after the crop, because the master is large enough that a third of it is still more than any of them asks for.

| Target shape | Frame | A centre crop keeps | Pixels it leaves | The target wants | Enough? |
| --- | --- | --- | --- | --- | --- |
| 16:9, the master's own shape | 1920×1080 | **100%** | 2.07 Mpx | 2.07 Mpx | yes |
| 4:5, the feed portrait | 1080×1350 | **45%** | 933,120 px | 1.46 Mpx | **no — 1.56× short** |
| 1:1, square | 1080×1080 | **56.3%** | 1.17 Mpx | 1.17 Mpx | yes |
| 9:16, full vertical | 1080×1920 | **31.6%** | 656,100 px | 2.07 Mpx | **no — 3.16× short** |
| 2.39:1, scope | 1920×803 | **74.4%** | 1.54 Mpx | 1.54 Mpx | yes |

From a 1920×1080 master. **How much survives is arithmetic on the two aspect ratios, not a judgement about what is in the frame** — and a 9:16 cut from 16:9 keeps under a third of it whatever the subject is doing. That is why a vertical version is a reframe rather than an export setting. **And from this master 2 targets come up short: 1080×1350 wants 1.56× what the crop leaves, 1080×1920 wants 3.16× what the crop leaves. The master is big enough overall and it is the wrong shape.**

## What it is

A single-page app at https://bitrate-desk.skillsafe.ai/. The engine is free and runs
entirely in the browser with no account; writing the report costs credits. 5 lanes over
one sheet, each handing its result to the next.

## The free engine

`bitrate.js` makes no network calls at all. Given a sheet it works out every target's
pixels a second and its bits per pixel, bands that against the thresholds below, computes
what a centre crop keeps and whether the crop leaves fewer pixels than the target asks
for, ranks the set twice — by bitrate and by budget — and names the first rank where the
two disagree, finds pairs on the same budget at very different bitrates, and totals the
upload against any stated limit. It emits 31 findings. All of that is
sent with every paid run as `prescan`, so the model is never asked to do arithmetic it
can be given.

Two targets within 2% of each other are treated as one
budget, so a rank that swaps between them is reported as nothing. Without that gate an
evenly funded ladder specified to three figures reports its own rounding as a finding.

## Sheet grammar

```text
UPLOAD
name     | the launch film
source   | 3840x2160
fps      | 30
duration | 90s
budget   | 800 MB

TARGETS
t1 | YouTube 4K      | 3840x2160 | 30 | 45 Mbps | the platform's own figure
t2 | YouTube 1080p60 | 1920x1080 | 60 | 12 Mbps | the platform's own figure
t3 | TikTok          | 1080x1920 | 30 | 10 Mbps | vertical, so the frame is recut
```

A TARGETS row is `id | what it is | resolution | fps | bitrate | why`.

Resolutions are `3840x2160`. **A bare number in the bitrate column is read as Mbps**, so
`12` and `12 Mbps` are the same; `5000k` and `800000` work too. `duration` accepts `90s`,
`1.5 min` or `90`. `budget` is a file size — `800 MB`, `1.2 GB` — and a bare number there
is read as MB.

In UPLOAD, **`source` is the master's real resolution**, which is what decides whether a
target is a downscale or an upscale and how much a crop leaves. If it is left out, the
largest target is assumed — the only size the master could certainly supply — and that
assumption is reported, because if the master is smaller than that, targets marked as
downscales are not.

## Lanes

| task | Lane | Fields | Sections |
| --- | --- | --- | --- |
| `plan` | Decide the ladder before anything is encoded | `brief, known` | Summary, The Sheet, The Ladder, Reasoning, Next Step |
| `check` | What each pixel actually gets | `sheet, worry` | Summary, Verdict, Findings, Corrected Sheet, Next Step |
| `budget` | The bitrates, ranked twice | `sheet` | Summary, Two Orders, What Each Pixel Gets, Same Budget, Next Step |
| `reframe` | What the master can and cannot supply | `sheet` | Summary, What Each Crop Keeps, Asking For More Than There Is, What A Reframe Would Fix, Next Step |
| `deliver` | Decide what changes: a bitrate, a size, or the shoot | `sheet, fixed` | Summary, A Bitrate Fixes, Only A Different Size Fixes, Nothing Fixes, Next Step |

Every run body must carry `task`. The body IS the input object — do not wrap it in an
`{"input": ...}` envelope, which returns 200 while hiding `task` from the model.

## Thresholds

| Number | Value | What it decides |
| --- | --- | --- |
| starved | below 0.05 bits/px | an ordinary codec cannot hold detail through movement, and no setting recovers it |
| lean | 0.05 to 0.1 bits/px | a static shot holds up and a pan does not |
| typical | 0.1 to 0.2 bits/px | where most delivered video sits |
| generous | above 0.2 bits/px | the encoder stops being the limiting factor |
| a hard crop | keeping under 50% | where a shape change stops being a crop and becomes a reframe |
| the same budget | within 2% | two targets this close are one instruction, and a rank swapping between them is noise |
| a wide spread | 2× or more | where the same material will visibly not hold up equally across the set |

## Severity

Severity is fixed by the code. **Errors are reserved for bits that cannot buy anything** —
a target below the point where an ordinary codec holds detail through movement, or one
asking for pixels the master never had. A hard crop, a wide spread and an exceeded budget
are warnings: real costs somebody has to decide about, not things that stop working.

| Code | Severity | Scope | What it means |
| --- | --- | --- | --- |
| `SOURCE-ASSUMED` | warn | upload | The master's resolution was assumed |
| `FPS-ASSUMED` | warn | upload | The master's frame rate was assumed |
| `DURATION-ASSUMED` | note | upload | The running time was assumed |
| `SOURCE-UNUSUAL` | note | upload | The master is not a standard frame size |
| `NO-TARGETS` | warn | upload | No targets given |
| `ONE-TARGET` | note | upload | Only one target |
| `BPP-STARVED` | error | target | There are not enough bits for these pixels |
| `BPP-LEAN` | warn | target | The budget is thin for this many pixels |
| `BPP-TYPICAL` | note | target | An ordinary budget for these pixels |
| `BPP-GENEROUS` | note | target | More bits than these pixels need |
| `UPSCALED` | error | target | It asks for more pixels than the master has |
| `UPSCALED-BY-THE-CROP` | error | target | The crop leaves fewer pixels than it asks for |
| `DOWNSCALED` | note | target | Fewer pixels than the master |
| `NATIVE` | note | target | The same pixel count as the master |
| `FPS-ABOVE-SOURCE` | warn | target | It asks for more frames a second than the master has |
| `FPS-BELOW-SOURCE` | note | target | Fewer frames a second than the master |
| `CROPPED` | warn | target | Its shape differs from the master's, so part of the frame goes |
| `CROPPED-HARD` | warn | target | More than half the frame is thrown away |
| `ASPECT-MATCHES` | note | target | The same shape as the master |
| `ODD-DIMENSION` | warn | target | A dimension is not an even number |
| `TARGET-UNUSUAL` | note | target | Not a standard frame size |
| `BITRATE-MISLEADS` | warn | upload | The biggest bitrate is not the biggest budget |
| `SAME-BUDGET-DIFFERENT-BITRATE` | note | upload | Two targets have the same budget per pixel on very different bitrates |
| `FPS-DOUBLES-THE-COST` | warn | upload | Two targets differ only in frame rate |
| `SPREAD-WIDE` | warn | upload | The targets are not comparable to each other |
| `ALL-ONE-BUDGET` | note | upload | Every target is on the same budget per pixel |
| `BUDGET-EXCEEDED` | warn | upload | The uploads come to more than the stated budget |
| `BUDGET-FITS` | note | upload | The uploads fit the stated budget |
| `TOTAL-UPLOAD` | note | upload | What the whole set comes to |
| `WHAT-IT-WOULD-COST` | note | upload | What the thin one would need |
| `RESOLUTION-IS-NOT-QUALITY` | note | upload | A higher-resolution target here is worse funded than a lower one |

## Which question to ask

**One number decides more than any other, and it is not the bitrate: it is the pixel
count per second.** Two targets with the same bitrate can be a whole quality tier apart,
and two with wildly different bitrates can be identical.

So the useful question is never *what bitrate should I use*. It is:

1. **How many pixels a second is this target actually asking for?**
2. **Does the master have them?** If not, no bitrate helps and the target is the wrong
   size.
3. **Is that budget the same as the other targets'?** If not, the set will not hold up
   evenly and nobody will be able to say why from the bitrates.

An encoding ladder is supposed to be one instruction at several sizes. Most ladders in
the wild are several different instructions that happen to be sorted.

## API

Full documentation at https://bitrate-desk.skillsafe.ai/api.html. The engine is
client-side only and has no endpoint, but everything it computes is above, so you can
reproduce every figure in your own pipeline without this app.

## What this page cannot do

- **It has not seen the video.** Bits per pixel is a budget, not a measurement: a static
  slate survives figures that would destroy a handheld shot of leaves.
- **The thresholds assume an ordinary inter-frame codec on ordinary material.** AV1 and
  H.265 hold up lower than H.264, and grain and fast motion move every number.
- **Constant-quality encoding does not have a bitrate to divide.** If you are encoding to
  a CRF or a VMAF target, this page describes the file you end up with rather than the
  instruction you gave.
- **The platform re-encodes anyway.** Your upload is a source for their encoder, so a
  clean, generously funded upload matters more than matching their published figure.
- **A centre crop is not a reframe.** The page computes what a centre crop keeps because
  that is what tools do by default, not because it is what an editor would do.
- **It says nothing about audio, colour, or codec choice.**

## Source

Lanes derived from the `content-engine` skill in https://github.com/affaan-m/everything-claude-code, which adapts one
source asset across platforms. Every platform it adapts to publishes a recommended
bitrate, and none of those numbers can be compared with any of the others as published.
Not affiliated with or endorsed by the authors of that repository.