# What MiniMax H3 actually outputs: "1080P" is 1920×1056, durations snap to 24 fps

**Quick answer:** On the hosted MiniMax H3 lanes I tested, a "1080P" request comes back at **1920×1056**, not 1920×1080 — the model converges to a pixel-area cap. Durations are quantised to whole 24 fps frames, so a 5 s request renders **5.167 s** and a 1 s request renders **1.625 s**. The 768P native canvas is **1344×768**, and every output carries a **32 kHz audio track**. All ten samples, with their generation logs, are published under CC BY 4.0.

If you are budgeting storage, frame-accurate editing, or an upload path that assumes standard 1080p, these numbers matter more than the spec sheet.

## How I measured this

Ten text-to-video and image-to-video runs across the 480P, 768P and 1080P tiers. For each sample I recorded the request (prompt, tier, aspect ratio, duration), the returned file's container metadata, and the wall-clock time from submit to a playable file.

The artifacts are in callirra-ai/minimax-h3-video-atlas on GitHub: each sample directory ships the MP4 plus a `generation.json` with the exact request parameters, and the README lists pixel dimensions, fps, duration, audio track and cost per sample.

Nothing here is inferred from documentation. Every number below was read out of a rendered file.

![](https://cdn.hashnode.com/uploads/covers/6aa64247595a42a6f9191714/becb156a-b0ca-4f08-90b9-7cd1736d3330.jpg align="center")

## Finding 1 — "1080P" is 1920×1056

The 1080P lane returns **1920×1056 @ 24 fps**. That is not a rounding artifact in my pipeline; it is the model converging on a pixel-area cap rather than a nominal 1920×1080 raster.

Practical consequences:

- A 1920×1056 frame is **7.8% shorter vertically** than 1920×1080. If you crop or scale assuming 1080, you either letterbox or lose the top and bottom of the framing.
- 1056 is not a multiple of 16. H.264 encoders handle it fine, but some NLE presets and hardware decoders are happier on multiples of 16 — check your pipeline before a long batch.
- The same cap applies to the square path: 1080P **1:1** comes back as **1056×1056**.

## Finding 2 — Durations quantise to 24 fps frames

Requested seconds are converted to whole frame counts at 24 fps, then back to a duration. The measurement:

| Requested | Rendered | Frames at 24 fps |
| --- | --- | --- |
| 1 s | 1.625 s | 39 |
| 5 s | 5.167 s | 124 |

So a "5 second clip" is about **1.006×** the requested length, and a 1 s clip is **1.6×**. Short clips drift proportionally more, which breaks assumptions in:

- **beat- or bar-synced edits** — a 24-frame-per-second grid does not align with 23.976 or 25 fps timelines;
- **batch concatenation** — mixing tiers produces clips with different frame counts, so a simple concat without re-timing shows a visible jump;
- **cost estimates** — if you are billed per output second, 5.167 s is what you pay for, not 5.000 s.

## Finding 3 — 768P's native canvas is 1344×768

Not 1366×768, not 1280×720. **1344×768**, i.e. 16:9 exactly at the model's native short side. Asking for 768P and getting 1344×768 means anyone scripting around generic "720p" presets will mis-size their overlays by a few percent.

This matters for template-driven work: if you have a fixed lower-third SVG authored for 1280×720, it lands at the wrong scale on a 1344×768 frame.

## Finding 4 — Every output ships a 32 kHz audio track

All ten samples had an audio stream at **32 kHz**, including text-to-video runs where I passed no audio input. The model appears to generate an ambient layer by default.

Two things follow:

1. If you **don't** want audio, strip it — but strip it deliberately, because the track exists whether or not you asked for sound.
2. If you **do** want audio, 32 kHz is below the 44.1/48 kHz that most delivery specs assume. Resample before you publish to platforms that enforce 48 kHz, or you will get an unnecessary re-encode.

## Finding 5 — "2K" is a second pass, not a first-class tier

On the lanes I used, 2K is not generated natively. The path is: generate at 768P, then run a regeneration step to 2K. That changes the economics:

- You pay for **both** passes, not one.
- The 2K result inherits the 768P composition, so re-rolling at 2K means re-rolling the first pass too.
- Wall-clock time compounds. In my runs the 1080P first pass alone took **5.7–7.9 minutes** for 5 s of video, versus **1–2.5 minutes** at 768P.

That is the single biggest surprise for anyone coming from an image model, where "higher tier" usually just means a slower call to the same endpoint.

## What this costs per second, and on what terms

Rates below are what I paid on the hosted endpoint I used, at the time of measurement. **They are not universal**: every provider resells these lanes at different margins, video input is billed on input seconds as well as output, and reference-image rules differ per lane.

| Tier | Measured output | Rate on the lane I used |
| --- | --- | --- |
| 480P | 864×480 (480×864 vertical), 24 fps | 1 credit / s |
| 768P | 1344×768 (768×1344 vertical), 24 fps | 2 credits / s |
| 1080P | 1920×1056, 24 fps | 3 credits / s |
| 2K (via regeneration) | 2560×1440-class | 10 credits / s |

At the platform's published rate of $0.01 per credit, that is **$0.01 / $0.02 / $0.03 per output second** for 480P / 768P / 1080P, and **$0.10 per output second** at 2K. Subscription discounts move those numbers, so treat them as list rates, not as what everyone pays.

For the 2K comparison specifically: MiniMax's own pay-as-you-go price for H3 2K was **$0.13/s** when I checked, and a reseller I compared against listed **$0.091/s** for a from-scratch 2K generation — but that reseller's cheaper $0.034/s figure only applies to a *regeneration* on top of a job you already paid for at that reseller. Two-pass economics, same trap as above. Compare like with like or the table lies to you.

Two billing rules that consistently bite people:

- **Video input is billed at the same per-second rate as output**, so a reference-to-video job with 6 s of input and 5 s of output bills 11 seconds, not 5.
- **The first five reference images are free on the 2K/video-to-video lane; the sixth onward is charged per image.** Audio inputs are not charged. An image-to-video job on the cheaper lanes has no per-reference-image fee at all — different lanes, different rules.

Free-tier allowances are small enough that the tiers above are self-limiting: a first-week allowance on the platform I used covered one 480P 5 s run, and nothing at 2K (the 2K minimum is 4 s, which is well past the allowance).

## FAQ

**Is 1920×1056 a bug?**

It is consistent across ten samples and three aspect ratios, so it looks like a deliberate pixel-area cap rather than a defect. Either way, plan for 1056.

**Can I get true 1920×1080?**

Not from the 1080P lane I tested. Upscale to 1920×1080 yourself if a downstream system demands it, but understand you are inventing 24 rows of pixels.

**Why 24 fps and not 30?**

24 is what the outputs carried. It is also why durations land on 1/24 s boundaries — 39 frames is 1.625 s exactly, not a bandwidth artifact.

**Does the audio track cost extra?**

Not on the lanes I measured. It is not separately billed, which is likely why it is always present.

**Is the model open source?**

The weights are downloadable, but the license is a community license, not OSI-approved: the applicable territory excludes the US, EU, UK and Korea, and hosted-service use carries additional conditions. Read it before you build a product on it.

## Data and corrections

If you have measurements that contradict any of the above, I want them — especially if you are on a different lane or a newer workflow. Open an issue there with the request JSON and the file's metadata and I will re-run the comparison.

Fifty prompts, including the ten rendered locally, are in the repo alongside the clips. The method is documented too, so you can reproduce it against any provider — the numbers above came from Callirra's H3 lanes because that is what I had access to.