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.

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:

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.

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.

Checks 1–3: is this even one shot?

1. One shot per generation. If your prompt contains "then", "and after that", or "cuts to", you are describing an edit, not a clip. Split it. Models that try to satisfy two beats tend to compromise both, usually by making the first beat too short or freezing the second.

2. Separate the subject, the action, and the camera. Three clauses, in that order. "A woman in a red coat walks toward the camera, slow push-in" is three decisions. Merge them into one sentence and the model has to guess which one is the subject of the shot. When a generation comes back wrong, it is usually wrong in exactly one of these three, and you cannot tell which if they were fused.

3. State the end state, not the process. "The cup is on the table, steam rising" describes a frame. "The cup is being placed on the table" describes a process, and a short clip cannot show it. Ask for a state you can screenshot; the motion inside it is the model's job.

Checks 4–6: did you pin the format?

4. Aspect ratio is an input, not a post-processing step. Decide the delivery ratio first — 16:9, 9:16, 1:1 — and request it, rather than generating 16:9 and cropping. Cropping a 16:9 clip to 9:16 throws away about 68% of the pixels and, worse, throws away the framing you asked for. Vertical also changes what the model emphasises; it fills a tall frame differently.

5. Check whether your duration will survive contact with the frame rate. Many pipelines convert requested seconds into a whole frame count and then report the real length. A request for 1 s can come back longer than a request for 5 s, proportionally. Before you build an edit around exact durations, verify one short clip at your lowest tier and measure it — not by trusting the number in the UI.

6. Pick the resolution tier by what the edit needs, not by the highest number. If the clip appears in a 640 px wide insert, a higher tier buys nothing but time and money. Higher tiers are also usually much slower per second of video, and the difference is not linear.

Checks 7–9: are the inputs compatible?

7. Count your reference images and know their roles. There is a difference between "this is the character" and "this is the style". Most models take several references but apply them positionally or with different weights. Passing six images and hoping is how you get a character wearing the reference image's background.

8. Frame-based modes need both ends if you want both ends. First-frame and last-frame conditioning are different inputs. If you only provide the first frame, asking for a specific ending is asking the model to improvise the part you cared about.

9. Decide who supplies the audio. Some models generate a soundtrack by default; some only accept audio you provide. This changes your workflow, not just the output: if the model generates audio, you may need to strip it; if you supply it, the clip length may follow the audio rather than your requested duration.

Checks 10–12: cost and exit plan

10. Know whether input seconds are billed. Video-to-video and reference-to-video jobs often bill input duration at the same rate as output. A "5 second" job with 6 seconds of input video can bill 11 seconds. Budget the input, not just the output.

11. Know the reference-image free tier. Several lanes include a handful of reference images and start charging per image after that. A prompt with nine references can cost meaningfully more than the same prompt with four — and usually four is enough.

12. Decide the crop and the delivery format before rendering. Every rescale after the fact costs quality and time. If you know the clip ends up in a 1080×1350 slot, generate for that slot.

The order that matters

If you only do three of these, do them in this order:

1. Check 1 — split multi-shot prompts. This is the single biggest source of full re-rolls.
2. Check 4 — request the delivery ratio. This is the most common post-processing regret.
3. Check 10 — read the billing rule for input seconds. This is the only one that silently changes your budget.

What this checklist does not fix

It will not save a prompt whose subject is genuinely ambiguous to a human reader, and it will not compensate for a model whose native canvas differs from your target. Those are content and capability problems, not checklist problems.

FAQ

How long should a first test clip be?

The shortest duration the tier allows. You are testing composition and motion, not rendering an edit; a shorter clip surfaces the same failures for a fraction of the cost.

Should I write prompts in English?

If the model's documentation is in English, yes — but keep proper nouns and any on-screen text in the language it needs to appear in. Mixing instructions in two languages inside one clause is a reliable way to get neither.

Do I need a storyboard for a five-second clip?

No, but you do need to know which single moment the clip is about. A storyboard is how you discover that moment when it is not obvious; for a one-shot clip, one sentence naming the moment is enough.

Does any of this depend on the model I use?

The framing (checks 1–6, 10–12) is model-agnostic. The numbers (checks 5, 7, 11) are not — verify them per model, per lane, and write down what you measured, because the documentation and the rendered file do not always agree.